Pourquoi n'y a-t-il pas de prise en charge de type WSDL pour Web Api?
Je viens donc de commencer avec .Net WebApi et une chose que je remarque tout de suite est qu'il n'y a pas de contrat définissant à quoi ressemble l'API et doit être consommée (demande/réponses de chaque action), ceci est généralement sous la forme de un WSDL pour WCF/Soap.
Il me semble que c'est quelque chose qui serait très précieux et rendrait la vie beaucoup plus facile aux consommateurs de votre API.
Y a-t-il une raison pour laquelle il n'y en a pas? Y a-t-il un paradigme ou un principe de programmation que je ne connais pas? Existe-t-il un moyen de créer un?
SAVON, REST ET CRÉATIVITÉ DES PERSONNES
SOAP a besoin d'un document de description comme WSDL car chaque ressource peut être consommée avec des messages différents, il n'y a pas de définition sur le protocole concernant les contraintes aux noms/messages possibles que vous pouvez manipuler une ressource.
Par exemple, dans SOAP votre service Web qui permet aux clients de manipuler un utilisateur peut exposer l'opération qui crée un utilisateur dans de nombreux messages différents, comme:
addUser
createUser
insertUser
Bien sûr, ce ne sont que quelques exemples de messages, car j'ai vu beaucoup de noms de méthodes de services Web amusants. Il y a des gens vraiment créatifs.
En revanche, si vous exposez votre système sous-jacent à l'aide d'une API web qui respecte vraiment les principes REST, le client a juste besoin de savoir que vous avez une ressource nommée Users, car il y a 99% de chance que vous puissiez créer un utilisateur de cette façon
POST /Users
Et cela se produit pour chaque opération que vous souhaitez exposer en utilisant SOAP ou une API Web REST.
En dépit d'être SOAP un protocole, qui restreint ce que vous pouvez ou ne pouvez pas faire, et être REST une architecture de style, qui laisse de nombreux points ouverts sur la façon de faire Il y a des efforts pour définir des conventions sur la façon d'exposer et de consommer REST web apis.
DÉCRIRE UN RESTE D'API WEB
Dans le domaine de la description d'une API Web REST je peux citer Swagger . Ce n'est pas une tentative de créer un WSDL comme pour l'API Web REST, mais c'est une bonne tentative de créer un standard ouvert pour décrire les API Web REST.
Swagger est une spécification et une implémentation complète du framework pour décrire, produire, consommer et visualiser les services Web RESTful.
J'utilise beaucoup Swagger et j'adore ça, principalement parce que Swagger UI qui vous permet de générer une belle console live et de la documentation pour votre API web.
Il existe de nombreuses implémentations de Swagger pour la plupart des langages: C #, Java, Python, Ruby, etc.
Si vous utilisez ASP .NET Web API, il existe des projets pour générer automatiquement la spécification Swagger, comme Swagger.NET
GÉNÉRATION DE CLIENTS À UN RESTE D'API WEB
Parce que les contraintes de REST, comme l'ensemble limité de verbes (GET, POST, PUT, DELETE, etc.) n'est pas si difficile de générer une bibliothèque cliente vers une API web REST.
Des projets comme WebApiProxy peuvent facilement générer des clients en C # et Javascript.
CONVENTIONS POUR LE REPOS API WEB
Pour garder notre vie de développeur plus facile, il est bon de définir certaines conventions sur le comportement de notre API Web REST se comportera, le meilleur effort que je connaisse dans ce domaine est le très bon Apigee - Web Api Design ebook . L'e-book n'est pas une tentative de créer une bible ou un mantra sur la façon de concevoir votre api, mais plutôt un ensemble de conventions observées sur un grand site web REST apis, comme Twitter, Facebook, Linkedin, Google, etc.
En un mot, parce que SOAP a été conçu pour être auto-descriptif: Un point de terminaison SOAP inclut généralement un wsdl qui décrit les opérations qu'il fournit et l'apparence des données (au moyen de XSD) que chaque opération prend et/ou renvoie.
En raison de cette auto-description, il est possible pour une application telle que Visual Studio de générer un proxy de service Web pour elle.
De plus, il existe plusieurs extensions de SOAP (les spécifications WS- *) qui permettent au chiffrement ou au comportement transactionnel d'être utilisé avec SOAP. L'idée est que vous pouvez utiliser SOAP comme guichet unique pour créer des services Web d'entreprise.
D'autre part...
WebAPI est conçu pour fournir des services REST. Le format de communication pour REST est généralement JSON ou XML brut - même si cela n'a pas vraiment d'importance, il peut même s'agir de texte brut. REST les services suivent une philosophie complètement différente: ils sont conçus pour être légers afin de pouvoir être facilement consommés par les scripts côté client dans le cadre d'une solution AJAX ou par les appareils mobiles.
En tant que tel, il est nécessaire de maintenir le niveau de la cérémonie au minimum, y compris l'auto-description. De plus, même si vous le souhaitez, la plupart des formats de communication utilisés dans les services REST (tels que JSON) n'ont de toute façon pas de manière formelle de décrire leur contenu.
En résumé, on pourrait dire que les services Web SOAP sont généralement utilisés pour intégrer des solutions (éventuellement disparates), tandis que les services REST sont mieux adaptés pour assurer la communication entre les parties de la même solution.
Les API SOAP/WS- * et RESTful ne sont pas les mêmes. Si vous souhaitez créer des API de prise en charge SOAP/WS- * WSDL, l'outil de choix dans la pile Microsoft est WCF, monté avec une option de liaison HTTP (il existe des options de liaison XML et JSON, XML étant l'option de prise en charge WSDL).
En pratique, la consommation d'un WSDL à partir d'un langage ou d'une plate-forme d'implémentation différent a été problématique. Les couches de sécurité WS- * par-dessus le sont encore plus.
Ma propre expérience a été principalement avec .Net, Node, Java et PHP à cet égard, et je peux dire que lorsque vous avez des plates-formes qui ne le font pas doivent définir les détails d'un type enfant, ou utiliseront "Object" comme définition, cela devient pour le moins problématique. Au-delà de cela, pour la plupart, personne ne comprend vraiment tout SOAP/WS- * en s'appuyant fortement sur l'outillage pour Cet outil a beaucoup de frais généraux et différents systèmes fonctionnent différemment.
Ce sont quelques-unes des raisons pour lesquelles les gens ont cherché à essayer des implémentations plus simples. REST (ala Web API) proposent des points de terminaison autour des objets/états. L'idée étant qu'il est plus facile de définir un ensemble de structures d'objets plus simples représentées au format JSON, et les points de terminaison à utiliser par rapport à ces structures que c'est d'essayer d'utiliser WSDL à partir d'un environnement étranger qui ne fonctionne pas, puis d'essayer de creuser et de contourner le problème.
Ironiquement, c'est l'un des domaines que j'ai utilisés Node dans un lot en tant que service de traduction, simplement parce qu'il était suffisamment flexible pour accepter des implémentations sales en tant que client , et je pouvais écrire des clients simples contre ma charge utile adaptée qui fonctionnait mieux. EX: C # obtient du texte JSON, que j'utilise JSON.Net pour convertir en une représentation d'objet que j'ai définie fonctionnait réellement lorsque je ne pouvais pas utiliser une importation WSDL.
En pratique, cela se produit souvent.