Cliquez si vous aimez le projet. Les Pull Requests sont très appréciées. Suivez-moi @kansiris87 pour les mises à jour techniques.
| Non. | Questions |
|---|---|
| 1 | [Qu'est-ce que REST ?](#Qu'est-ce que REST ?) |
| 2 | [Expliquez le principe REST ?](#Expliquez le principe REST ?) |
| 3 | [Quelle est la différence entre REST et SOAP ?](#Quelle est la différence entre REST et SOAP ?) |
| 4 | [Qu'est-ce que l'API WEB ASP.NET ?](#Qu'est-ce que l'API WEB ASP.NET ?) |
| 5 | [Pourquoi choisir l'API WEB ASP.NET ?](#Pourquoi choisir l'API WEB ASP.NET ?) |
| 6 | [Quelle est la différence entre WCF et ASP.NET WEB API et WCF REST et Web Service ?](#Quelle est la différence entre WCF et ASP.NET WEB API et WCF REST et Web Service ?) |
| 7 | [Lequel choisir entre WCF et API WEB ?](#Lequel choisir entre WCF et API WEB ?) |
| 8 | [Quelle est la différence entre ASP.NET MVC et l'API WEB ASP.NET ?](#HQuelle est la différence entre ASP.NET MVC et l'API WEB ASP.NET ?) |
| 9 | [Pouvez-vous renvoyer la vue en utilisant la méthode API WEB ?](#Pouvez-vous renvoyer la vue en utilisant la méthode API WEB ?) |
| 10 | [Pouvez-vous changer le nom de l'action de l'API WEB comme ASP.NET MVC ?](#Pouvez-vous changer le nom de l'action de l'API WEB comme ASP.NET MVC ?) |
|1 | [Pouvez-vous restreindre l'invocation d'une méthode d'action de l'API WEB uniquement par HTTP GET, POST, PUT ou DELETE ?](#Pouvez-vous restreindre l'invocation d'une méthode d'action de l'API WEB uniquement par HTTP GET, POST, PUT ou DELETE ?)| |2 | [Comment appeler l'API WEB dans ASP.NET MVC ?](#Comment appeler l'API WEB dans ASP.NET MVC ?)| |3 | [En quoi le routage API ASP.NET est différent du routage ASP.NET MVC ?](#En quoi le routage API ASP.NET est différent du routage ASP.NET MVC ?)| |4 | [Comment activer le routage d'attributs dans ASP.NET WEB API2 ?](#Comment activer le routage d'attributs dans ASP.NET WEB API2 ?)| |5 | [Comment définir le routage d'attributs dans ASP.NET WEB API2 ?](#Comment définir le routage d'attributs dans ASP.NET WEB API2 ?)|
REST signifie Representational State Transfer. Il s'agit d'un protocole d'échange de données dans un environnement distribué. REST est un style architectural qui traite chaque service comme une ressource et accède aux données via des méthodes de protocole HTTP telles que GET, POST, PUT et DELETE.
Les architectures de style REST se composent de clients et de serveurs. Les clients lancent des requêtes vers des serveurs qui traitent ces requêtes et renvoient des réponses basées sur ces requêtes. Ces demandes et réponses se construisent autour du transfert de représentations de ces ressources.
REST est un ensemble de principes qui définissent la manière dont les standards Web, tels que HTTP et les URI, sont censés être utilisés. Il existe cinq principes REST importants indiqués ci-dessous :
Ressources adressables - Chaque ressource doit être identifiée par un URI (identifiant unique)
Interfaces simples et uniformes - REST est basé sur le protocole HTTP, utilisez donc les méthodes HTTP GET, POST, PUT et DELETE pour effectuer des actions. Cela rend REST simple et uniforme.
Orienté vers la représentation : la représentation des ressources est échangée. GET est utilisé pour renvoyer une représentation et PUT, POST transmet la représentation au serveur afin que les ressources sous-jacentes puissent changer. La représentation peut être dans de nombreux formats comme XML, JSON, etc.
Communiquer sans état : une application peut avoir un état mais aucune donnée de session client n'est stockée sur le serveur. Toutes les données spécifiques à la session doivent être conservées et conservées par le client et transférées au serveur à chaque demande, selon les besoins.
Mise en cache : les clients doivent pouvoir mettre en cache les réponses pour une utilisation ultérieure.
La différence entre REST et SOAP est indiquée ci-dessous : SOAP REST SOAP signifie Simple Object Access Protocol. REST signifie REpresentational State Transfer. Il s'agit d'un protocole basé sur XML construit sur HTTP ou parfois TCP/IP, SMTP. REST n'est pas un protocole mais c'est une architecture de style architectural basée sur les ressources. SOAP a des spécifications pour la mise en œuvre avec et sans état. REST est complètement apatride. SOAP applique le format de message au format XML. REST n'applique pas le format de message XML ou JSON. SOAP a une spécification standard définie. Par exemple, WS-Security est la spécification pour la mise en œuvre de la sécurité. Il n’a pas de spécifications standards définies. Le message SOAP consiste en une enveloppe qui comprend des en-têtes et un corps SOAP pour stocker les informations réelles que vous souhaitez envoyer. REST utilise les en-têtes HTTP intégrés (avec une variété de types de médias) pour transporter des méta-informations et utilise les verbes GET, POST, PUT et DELETE pour effectuer des opérations CRUD. SOAP utilise des interfaces et des opérations nommées pour exposer votre service. REST utilise l'URI et des méthodes telles que (GET, PUT, POST, DELETE) pour exposer les ressources. Les performances sont lentes par rapport à REST. REST est rapide par rapport à SOAP.
L'API WEB ASP.NET est un framework permettant de créer des services HTTP pouvant être utilisés par un large éventail de clients, notamment les navigateurs, les mobiles, les iPhone et les tablettes. Il est très similaire à ASP.NET MVC puisqu'il contient les fonctionnalités MVC telles que le routage, les contrôleurs, les résultats d'action, le filtre, les classeurs de modèles, le conteneur IOC ou l'injection de dépendances. Mais cela ne fait pas partie du framework MVC. Il fait partie de la plate-forme principale ASP.NET et peut être utilisé avec MVC et d'autres types d'applications Web telles que ASP.NET WebForms. Il peut également être utilisé comme application de services Web autonome. Caractéristiques de l'API WEB ASP.NET 1. Elle prend en charge les actions CRUD basées sur des conventions car elle fonctionne avec les verbes HTTP GET, POST, PUT et DELETE. 2. Les réponses ont un en-tête Accept et un code d'état HTTP. 3. Les réponses sont formatées par MediaTypeFormatter de l'API WEB en JSON, XML ou tout autre format que vous souhaitez ajouter en tant que MediaTypeFormatter. 4. Il peut accepter et générer du contenu qui ne peut pas être orienté objet comme des images, des fichiers PDF, etc. 5. Il prend automatiquement en charge OData. Par conséquent, en plaçant le nouvel attribut [Queryable] sur une méthode de contrôleur qui renvoie IQueryable, les clients peuvent utiliser la méthode pour la composition des requêtes OData. 6. Il peut être hébergé dans l'application ou sur IIS. 7. Il prend également en charge les fonctionnalités MVC telles que le routage, les contrôleurs, les résultats d'action, le filtre, les classeurs de modèles, le conteneur IOC ou l'injection de dépendances, ce qui le rend plus simple et plus robuste.
Aujourd'hui, une application Web ne suffit pas pour toucher ses clients. Les gens sont très intelligents, ils utilisent des appareils iPhone, mobiles, tablettes, etc. dans leur vie quotidienne. Ces appareils disposent également de nombreuses applications pour vous faciliter la vie. En fait, nous passons du monde du Web au monde des applications.
Ainsi, si vous souhaitez exposer vos données de service aux navigateurs et à toutes ces applications d'appareils modernes de manière simple et rapide, vous devez disposer d'une API compatible avec les navigateurs et tous ces appareils.
Par exemple les API Twitter, Facebook et Google pour l'application Web et les applications téléphoniques.
L'API WEB est le cadre idéal pour exposer vos données et vos services à différents appareils. De plus, l'API WEB est open source et constitue une plate-forme idéale pour créer des services REST-ful sur le .NET Framework. Contrairement au service WCF Rest, il utilise toutes les fonctionnalités de HTTP (comme les URI, les en-têtes de requête/réponse, la mise en cache, la gestion des versions, divers formats de contenu) et vous n'avez pas besoin de définir de paramètres de configuration supplémentaires pour différents appareils contrairement au service WCF Rest.
Si nous avons besoin d'un service Web et n'avons pas besoin de SOAP, alors l'API WEB ASP.NET est le meilleur choix.
Il est utilisé pour créer des services HTTP simples et non basés sur SOAP au-dessus du pipeline de messages WCF existant.
Il n'a pas de configuration fastidieuse et étendue comme le service WCF REST.
Création de service simple avec API WEB. Avec les services WCF REST, la création de services est difficile.
Il est uniquement basé sur HTTP et facile à définir, exposer et consommer de manière REST.
Il s'agit d'une architecture légère et idéale pour les appareils dont la bande passante est limitée, comme les téléphones intelligents.
C'est open source.
Le framework .NET dispose d'un certain nombre de technologies qui vous permettent de créer des services HTTP tels que Web Service, WCF et maintenant WEB API. Il existe les différences suivantes entre ces quatre :
Service Web
Il est basé sur SOAP et renvoie les données sous forme XML.
Il ne prend en charge que le protocole HTTP.
Il n'est pas open source mais peut être utilisé par n'importe quel client comprenant XML.
Il ne peut être hébergé que sur IIS.
WCF
Il est également basé sur SOAP et renvoie les données sous forme XML.
C'est l'évolution du service Web (ASMX) et prend en charge divers protocoles comme TCP, HTTP, HTTPS, Named Pipes, MSMQ.
Le principal problème avec WCF est sa configuration fastidieuse et étendue.
Il n'est pas open source mais peut être utilisé par n'importe quel client comprenant XML.
Il peut être hébergé dans l'application ou sur IIS ou en utilisant le service Windows.
WCF Reste
Pour utiliser WCF comme service WCF Rest, vous devez activer webHttpBindings.
Il prend en charge les verbes HTTP GET et POST respectivement par les attributs [WebGet] et [WebInvoke].
Pour activer d'autres verbes HTTP, vous devez effectuer une configuration dans IIS pour accepter la demande de ce verbe particulier sur les fichiers .svc
La transmission de données via des paramètres à l'aide d'un WebGet nécessite une configuration. L'UriTemplate doit être spécifié
Il prend en charge les formats de données XML, JSON et ATOM.
API WEB
Il s'agit du nouveau cadre permettant de créer des services HTTP de manière simple et simple.
L'API WEB est open source, une plate-forme idéale pour créer des services REST-ful sur le .NET Framework.
Contrairement au service WCF Rest, il utilise toutes les fonctionnalités de HTTP (comme les URI, les en-têtes de requête/réponse, la mise en cache, la gestion des versions, divers formats de contenu)
Il prend également en charge les fonctionnalités MVC telles que le routage, les contrôleurs, les résultats d'action, le filtre, les classeurs de modèles, le conteneur IOC ou l'injection de dépendances, les tests unitaires qui le rendent plus simple et plus robuste.
Il peut être hébergé dans l'application ou sur IIS.
Il s'agit d'une architecture légère et idéale pour les appareils dont la bande passante est limitée, comme les téléphones intelligents.
Les réponses sont formatées par MediaTypeFormatter de l'API WEB en JSON, XML ou tout autre format que vous souhaitez ajouter en tant que MediaTypeFormatter.
Les points suivants vous aident à choisir entre WCF et WEB API :
Choisissez WCF lorsque vous souhaitez créer un service devant prendre en charge des scénarios spéciaux tels que la messagerie unidirectionnelle, les files d'attente de messages, la communication duplex, etc.
Choisissez WCF lorsque vous souhaitez créer un service pouvant utiliser des canaux de transport rapides lorsqu'ils sont disponibles, tels que TCP, Named Pipes ou peut-être même UDP (dans WCF 4.5), et que vous souhaitez également prendre en charge HTTP lorsque tous les autres canaux de transport ne sont pas disponibles.
Choisissez l'API WEB lorsque vous souhaitez créer des services orientés ressources sur HTTP qui peuvent utiliser toutes les fonctionnalités de HTTP (telles que les URI, les en-têtes de requête/réponse, la mise en cache, la gestion des versions, divers formats de contenu).
Choisissez WEB API lorsque vous souhaitez exposer votre service à un large éventail de clients, notamment les navigateurs, les mobiles, les iPhone et les tablettes.
Il existe les différences suivantes entre ASP.NET MVC et l'API WEB :
ASP.NET MVC est utilisé pour créer des applications Web qui renvoient à la fois des vues et des données, mais l'API WEB ASP.NET est utilisée pour créer des services HTTP complets d'une manière simple et simple qui renvoie uniquement les données et non les vues.
L'API WEB aide à créer des services REST sur le .NET Framework et prend également en charge la négociation de contenu (il s'agit de décider du meilleur format de données de réponse qui pourrait être acceptable par le client. Il peut s'agir de JSON, XML, ATOM ou d'autres données formatées. ), auto-hébergement qui ne sont pas dans MVC.
L'API WEB se charge également de renvoyer les données dans un format particulier comme JSON, XML ou tout autre basé sur l'en-tête Accept dans la requête et vous ne vous en souciez pas. MVC renvoie uniquement les données au format JSON à l'aide de JsonResult.
Dans l'API WEB, les requêtes sont mappées aux actions basées sur des verbes HTTP, mais dans MVC, elles sont mappées au nom des actions.
L'API WEB ASP.NET est un nouveau framework et fait partie du framework ASP.NET de base. La liaison de modèle, les filtres, le routage et les autres fonctionnalités MVC existent dans l'API WEB sont différentes de MVC et existent dans le nouvel assembly System.Web.Http. Dans MVC, ces fonctionnalités existent dans System.Web.Mvc. Par conséquent, l'API WEB peut également être utilisée avec ASP.NET et en tant que couche de service autonome.
Vous pouvez mélanger l'API WEB et le contrôleur MVC dans un seul projet pour gérer les requêtes AJAX avancées qui peuvent renvoyer des données au format JSON, XML ou tout autre format et créer un service HTTP complet. Typiquement, cela sera appelé auto-hébergement de l’API WEB.
Lorsque vous avez mélangé le contrôleur MVC et WEB API et que vous souhaitez implémenter l'autorisation, vous devez alors créer deux filtres, un pour MVC et un autre pour l'API WEB, car les deux sont différents.
De plus, l'API WEB est une architecture légère et, à l'exception de l'application Web, elle peut également être utilisée avec des applications pour téléphones intelligents.
Contrairement à ASP.NET MVC, l'API WEB est utilisée pour renvoyer uniquement des données. Les données peuvent être une chaîne, JSON, XML, texte, etc. Elles ne peuvent pas renvoyer une vue comme ASP.NET MVC.
Comme ASP.NET MVC, vous pouvez également modifier le nom de l'action de l'API WEB en utilisant l'attribut ActionName comme indiqué ci-dessous :
[HttpGet] [ActionName("GetProducts")] public IEnumerable ProductList() { return db.Products.AsEnumerable(); }
Comme ASP.NET MVC, vous pouvez également restreindre l'appel de la méthode d'action de l'API WEB uniquement par une requête HTTP spécifique en appliquant l'attribut HttpGet ou HttpPost ou HttpPut ou HttpDelete.
Si vous souhaitez restreindre une méthode d'action pour la requête HTTP Get uniquement, décorez-la avec l'attribut de sélection de méthode d'action HttpGet comme indiqué ci-dessous :
[HttpGet] public IEnumerable ProductList() { return db.Products.AsEnumerable(); }
L'API WEB ASP.NET peut être appelée en utilisant HttpClient et l'adresse de l'API WEB comme indiqué ci-dessous :
classe publique ProductController : Contrôleur { HttpClient Client = new HttpClient(); Uri BaseAddress = new Uri("http://localhost:131/"); public ActionResult Index() { Client.BaseAddress = BaseAddress; Réponse HttpResponseMessage = Client.GetAsync("productservice/GetProducts").Result; if (response.IsSuccessStatusCode) { var data = réponse.Content.ReadAsAsync<IEnumerable>().Result; return View (données); } return Vue(); } }
ASP.NET MVC et ASP.NET WEB API utilisent tous deux le routage pour surveiller les requêtes entrantes et au moins une route est définie pour fonctionner. La différence entre ces deux routages est donnée ci-dessous :
Dans le modèle de routage de l'API WEB, le paramètre {action} est facultatif mais vous pouvez inclure un paramètre {action}. Dans ASP.NET MVC, le paramètre {action} est obligatoire.
Les méthodes d'action définies dans le contrôleur API doivent soit avoir l'attribut des verbes d'action HTTP (GET, POST, PUT, DELETE), soit avoir l'un des verbes d'action HTTP comme préfixe pour le nom des méthodes d'actions. Dans ASP.NET MVC, par défaut, une méthode d'action peut être appelée par des verbes HTTP GET ou POST et pour utiliser d'autres verbes HTTP que vous devez définir en tant qu'attribut.
Contrairement à ASP.NET MVC, l'API Web ne peut recevoir qu'un seul type complexe en tant que paramètre.
L'activation du routage d'attributs dans votre API WEB ASP.NET2 est simple, il suffit d'ajouter un appel à la méthode MapHttpAttributeRoutes() avec la méthode Register() du fichier WebApiConfig.cs.
public static class WebApiConfig { public static void Register(HttpConfiguration config) { //activation du routage d'attributs config.MapHttpAttributeRoutes(); } }
Vous pouvez également combiner le routage par attributs avec le routage basé sur des conventions.
classe statique publique WebApiConfig { registre public static void (configuration HttpConfiguration) {
//activation du routage d'attributs config.MapHttpAttributeRoutes(); // Routage basé sur les conventions. config.Routes.MapHttpRoute( nom : "DefaultApi",
routeTemplate : "api/{controller}/{id}", valeurs par défaut : new { id = RouteParameter.Optional });
} }
Comme ASP.NET MVC5, vous pouvez également définir le routage des attributs dans WEB API2 au niveau du contrôleur et au niveau de l'action, comme indiqué ci-dessous :
[RoutePrefix("Service/User")] public class UserController : ApiController { //GET route : api/User public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("{id}")] //GET route : Service/Utilisateur/1 public string Get(int id) { return "value"; }
[Route("")] //Route POST : Service/Utilisateur/public void Post([FromBody]string value) { } }
• Routage au niveau de l'action – Vous pouvez définir des itinéraires au niveau de l'action qui s'appliquent à une action spécifique dans le contrôleur.
classe publique UserController : ApiController { //GET route : api/User
public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("Service/User/{id}")] //GET route : Service/User/1 public string Get(int id) { return "value"; } [Route("Service/Utilisateur/")] //Route POST : Service/Utilisateur/public void Post([FromBody]string value) { } }