Pourquoi n'y a-t-il pas de support de type WSDL pour Web Api?

Donc, je commence tout juste à utiliser .Net WebApi et une chose que je remarque tout de suite est qu’il n’existe pas de contrat définissant l’apparence de l’API (demande / réponses de chaque action), il s’agit généralement de: un WSDL pour WCF / Soap.

Il me semble que cela serait très utile et faciliterait la vie des utilisateurs de votre API.

Y a-t-il une raison pour qu'il n'y en ait pas? Existe-t-il un paradigme ou un principe de programmation dont je ne suis pas au courant? Y a-t-il un moyen de créer un?

SAVON, REPOS ET CRÉATIVITÉ DES PERSONNES

SOAP a besoin d'un document de description tel que WSDL, car chaque ressource peut être utilisée avec différents messages. Le protocole ne définit pas les contraintes relatives aux noms / messages possibles que vous pouvez manipuler.

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, tels que:

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 vraiment des gens créatifs.

D'autre part, si vous exposez votre système sous-jacent à l'aide d'une API Web qui respecte réellement les principes REST, le client doit simplement savoir que vous disposez d'une ressource nommée Utilisateurs, car il y a 99% de chance que vous puissiez créer un utilisateur dans cette application. façon

POST /Users

Et cela se produit pour chaque opération que vous souhaitez exposer à l'aide de SOAP ou d'une application Web REST.

Bien qu’il soit un protocole SOAP, qui limite ce que vous pouvez ou ne pouvez pas faire, et soit une architecture de style REST, ce qui laisse de nombreux points en suspens sur la façon de faire les choses. Des efforts sont en cours pour définir des conventions sur la manière d'exposer et de consommer les sites Web REST.

DESCRIPTION D'UN REST D'API WEB

Dans le domaine de la description d’une API Web REST, je peux citer Swagger . Il ne s’agit pas d’une tentative de création d’un WSDL semblable à une application Web REST, mais d’une bonne tentative de création d’un standard ouvert pour décrire l’API Web.

Swagger est une spécification et une implémentation complète du framework permettant de décrire, produire, consommer et visualiser les services Web RESTful.

J'utilise beaucoup Swagger et je l'aime beaucoup, principalement parce que l' interface utilisateur Swagger vous permet de générer une console live et une documentation de qualité 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 l’API Web ASP .NET, certains projets générant automatiquement la spécification Swagger, tels que Swagger.NET

GÉNÉRATION DE CLIENTS SUR UN RESTE D'API WEB

Parce que les contraintes de REST, telles que le nombre limité de verbes (GET, POST, PUT, DELETE, etc.), il n’est pas si difficile de générer une bibliothèque cliente pour une application Web REST.

Des projets tels que WebApiProxy peuvent facilement générer des clients en C # et Javascript.

CONVENTIONS POUR LE RESTE API WEB

Pour que notre vie de développeur soit plus facile, il est bon de définir certaines conventions concernant le comportement de notre api Web REST. Le meilleur effort que je connaisse dans ce domaine est le très bon ebook Apigee - Web Api Design . Le livre électronique 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 dans de grandes applications Web REST, telles que Twitter, Facebook, Linkedin, Google, etc.

En résumé, parce que SOAP a été conçu pour être auto-descriptif: un point de terminaison SOAP comprend généralement un wsdl décrivant les opérations qu’il fournit et l’apparence des données (au moyen de fichiers XSD incorporés) prises et / ou renvoyées.
En raison de ce caractère auto-descriptif, 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 à SOAP (les spécifications WS- *) qui permettent d'utiliser le cryptage ou le comportement transactionnel avec SOAP. L'idée est que vous pouvez utiliser SOAP comme guichet unique pour créer des services Web de niveau 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 simple - bien que cela n’importe vraiment pas, il peut même s'agir de texte brut. Les services REST suivent une philosophie complètement différente: ils sont conçus pour être légers, de sorte qu'ils puissent être facilement consommés par des scripts côté client dans le cadre d'une solution AJAX ou par des appareils mobiles.
En tant que tel, il est nécessaire de maintenir le niveau de cérémonie au minimum, y compris en ce qui concerne l'autodéclaration. En outre, même si vous le souhaitiez, la plupart des formats de communication utilisés dans les services REST (tels que JSON) ne disposent pas de moyen formel pour décrire leur contenu.

En résumé, vous pouvez 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 plus adaptés pour assurer la communication entre des éléments d'une même solution.

Les API SOAP / WS- * et RESTful ne sont pas identiques. Si vous souhaitez créer des API prenant 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 prenant en charge WSDL).

En pratique, consommer un WSDL depuis un langage ou une plate-forme d'implémentation différents était problématique. WS- * couches de sécurité sur le dessus encore plus.

À cet égard, ma propre expérience a été principalement liée à .Net, Node, Java et PHP, et je peux dire que lorsque vous avez des plateformes qui ne doivent pas définir les détails d’un type enfant, ou qui utilisent "Object" comme définition, il devient problématique pour le moins. En dehors de cela, pour la plupart, personne ne comprend vraiment tout ce que SOAP / WS- * dépend fortement des outils pour le faire fonctionner. Cet outillage 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. Les services REST (comme l'API Web) offrent 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’objet plus simples représentées au format JSON et les ordinateurs d'extrémité à utiliser contre ces structures que d'essayer d'utiliser WSDL à partir d'un environnement extraterrestre qui ne fonctionne pas, puis d'essayer de creuser et de contourner le problème.

Ironiquement, c’est l’un des domaines où j’ai utilisé Node beaucoup en tant que service de traduction, tout simplement parce qu'il était suffisamment souple pour accepter les implémentations sales en tant que client, et je pourrais écrire des clients simples contre ma charge adaptée qui fonctionnait mieux. EX: C # obtient le texte JSON, que j’utilise JSON.Net pour convertir en une représentation d’objet que j'ai définie et qui fonctionnait réellement lorsque je ne pouvais pas utiliser une importation WSDL.

En pratique, cela arrive souvent.

Bien que beaucoup des réponses soient bonnes, je pense que la réponse est BEAUCOUP plus simple: vous utilisez la mauvaise technologie pour le poste.

Si vous cherchez à créer un service SOAP, vous devriez vraiment vous en tenir à la WCF. C’est toujours un framework très puissant, Microsoft le développe activement, aucune annonce n’a été faite pour que nous puissions penser que cela irait quelque part dans le futur, et cela a été fait dans cet esprit. La Web API ne remplace en aucun cas la WCF (même si elle est probablement plus tendance que la WCF).

Les API Web faisaient autrefois partie de WCF, mais elles ont été transférées dans la famille ASP.NET, car elles ne cadraient pas vraiment avec les autres technologies WCF. L'API Web est beaucoup plus soucieuse d'utiliser HTTP comme protocole d'application que comme protocole de transfert. Dans les API Web, les verbes HTTP sont la règle, dans WCF HTTP sert simplement à activer le protocole SOAP.

Ne blâmez pas l'API Web de ne pas avoir donné la possibilité de faire certaines choses pour lesquelles elle n'a pas été conçue.