Services RESTful - Équivalent WSDL


94

J'ai lu sur REST et SOAP et je comprends pourquoi la mise en œuvre de REST peut être bénéfique par rapport à l'utilisation d'un protocole SOAP. Cependant, je ne comprends toujours pas pourquoi il n'y a pas d'équivalent "WSDL" dans le monde REST. J'ai vu des articles disant qu'il n'y avait "pas besoin" du WSDL ou qu'il serait redondant dans le monde REST, mais je ne comprends pas pourquoi. N'est-il pas toujours utile de se lier par programme à une définition et de créer des classes proxy au lieu de coder manuellement? Je ne veux pas entrer dans un débat philosophique, je cherche simplement la raison pour laquelle il n'y a pas de WSDL dans REST, ou pourquoi il n'est pas nécessaire. Merci.


4
J'ai la même question. Du point de vue des clients, il semble que les services reposants soient beaucoup plus difficiles à utiliser qu'un service WSDL.
w.donahue

4
Il me semble que si vous exposez quelque chose de simple, vous n'avez pas besoin d'un WADL ou d'un WSDL. Mais si vous exposez quelque chose d'aussi complexe que SAP ... Je ne peux pas imaginer ne pas avoir une sorte de réflexion et d'espace de noms pour gérer la pléthore de fonctionnalités.
Brain2000

La méthode HTTP OPTIONS ne pourrait-elle pas être considérée comme un «équivalent» car elle devrait fournir des informations sur les méthodes disponibles et les paramètres nécessaires à toute action possible?
Dim13i

Réponses:


44

Le langage de description d'application Web (WADL) est fondamentalement l'équivalent de WSDL pour les services RESTful, mais il y a eu une controverse en cours sur la nécessité de quelque chose comme ça.

Joe Gregorio a écrit un bel article sur ce sujet qui vaut la peine d'être lu.


1
Merci Joschi. J'ai lu les articles, mais je n'ai pas trouvé le second trop convaincant. Quels points il aborde avez-vous trouvé les plus précieux?
skaz

1
Il peut être intéressant de noter que .NET a également un moyen de publier des métadonnées ( msdn.microsoft.com/en-us/library/ms730243.aspx ). Cela dit, la plupart des services REST que j'ai vus développés par les grands sites incluent une variété de clients téléchargeables développés pour les principaux langages de programmation (Java, .NET, PHP, etc.). À mon avis, cela impose un lourd fardeau au fournisseur de services.
dana

4
@dana: Cela ne semble pas très utile d'écrire un service qui vous oblige à écrire également le client?
BlueChippy

19

WSDL décrit les points de terminaison de service. Les clients REST ne doivent pas être couplés aux points de terminaison du serveur (c'est-à-dire ne doivent pas en être informés à l'avance dans les URL). Les clients REST sont couplés sur les types de supports qui sont transférés entre le client et le serveur.

Il peut être judicieux de générer automatiquement des classes sur le client pour encapsuler les types de médias retournés. Cependant, dès que vous commencez à créer des classes proxy autour des interactions de service, vous commencez à obscurcir les interactions HTTP et risquez de dégénérer vers un modèle RPC.


4
Pouvez-vous élaborer un peu plus? J'ai peur de ne pas comprendre. Merci.
skaz

1
Les classes proxy sont un moyen de valider la machine au moment de la compilation. Sans eux, vous n'avez que des documents écrits manuellement et une «validation» basée sur des tests.
Eric Grange

1
@EricGrange ... et pourtant cette approche a plutôt bien fonctionné pour le Web jusqu'à présent.
Darrel Miller le

1
@DarrelMiller dépend de ce que vous appelez "bien fonctionné", c'est comme dans les années 80 quand tout le monde écrivait ses interops sur des documents papier, donc ça marche, mais "bien"?
Eric Grange

4
Les spécifications de type @BlueChippy Media sont traitées à l'ancienne. Soit vous trouvez un analyseur existant pour la spécification, soit vous allez lire la spécification et en écrire un vous-même. La chose importante à noter est que l'objectif est que les spécifications de type de média soient réutilisables dans les API. L'écriture d'un nouvel analyseur pour chaque API va à l'encontre du point. REST lorsqu'il est bien fait, c'est pour les avantages à très long terme d'une évolution indépendante du client et du serveur.
Darrel Miller

8

RSDL vise à transformer le repos comme un hypermédia, c'est-à-dire qu'il a plus d'informations qu'un descripteur de service comme WSDL ou WADL. Par exemple, il contient des informations sur la navigation, telles que l'hypertexte et les hyperliens.

Par exemple, étant donné une ressource actuelle, vous avez un ensemble de liens os vers d'autres ressources liées.

Cependant, je n'ai pas trouvé de clients de repos prenant en charge ce format ou de solutions de serveur de repos avec une fonctionnalité permettant de le générer automatiquement.

Je pense qu'il y a un long chemin pour une conclusion à ce sujet. Voir la longue histoire HTML et W3C vs Browsers lol.

Pour plus de détails sur Rest comme Hypermedia, regardez: http://en.wikipedia.org/wiki/HATEOAS

Remarque: Roy Fielding a critiqué ces tendances dans Rest Apis sans l'approche de l'hypermidie: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Ma conclusion: Now a Days, WADL est plus courant que les Frameworks de repos et d'intégration comme Camel CXF supportent déjà WADL (générer et consommer), car il est similaire à WSDL, donc plus facile à comprendre dans ce processus de migration (SOAP vers REST).

Voyons les prochains chapitres;)


8

N'est-il pas toujours utile de se lier par programme à une définition et de créer des classes proxy au lieu de coder manuellement?

D'accord de tout cœur, c'est pourquoi j'utilise Swagger.io

Swagger est un puissant framework open source soutenu par un vaste écosystème d'outils qui vous aide à concevoir, créer, documenter et consommer vos API RESTful.

Donc, fondamentalement, j'utilise Swagger pour décrire mes modèles, mes points de terminaison, etc., puis j'utilise d'autres outils comme swagger-codegen pour générer les classes proxy au lieu de les coder manuellement.

Voir aussi: RAML


Je ne savais pas que Swagger faisait aussi ça. Je pensais que c'était juste de la documentation / un cadre générique pour les API REST
Robert Dundon


3

WSDL est extensible pour permettre la description des points finaux et de leurs messages quels que soient les formats de message ou les protocoles réseau utilisés pour communiquer

Cependant, REST utilise le protocole réseau en utilisant des verbes HTTP et l'URI pour représenter un état d'objets.

Les WSDL vous indiquent à cet endroit que si vous envoyez ce message, vous effectuerez cette action et récupérerez ce format en conséquence.

Dans REST, si je voulais créer un nouveau profil, j'utiliserais le verbe POSTavec un corps JSON ou des variables de serveur http décrivant mon profil à l'URL/profile

POSTdoit renvoyer un ID généré côté serveur, en utilisant le code d'état 201 CREATEDet l'en-tête Location: *new_profile_id*(par exemple 12345)

Je peux ensuite effectuer des mises à jour en modifiant l'état d' /profile/12345utilisation du verbe HTTP POST, par exemple pour modifier mes adresses e-mail ou mon numéro de téléphone. Évidemment, changer l'état de l'objet distant.

GET renverrait le statut actuel du /profile/12345

PUT est généralement utilisé pour l'ID généré côté client

DELETE, évident

HEAD, obtient le statut sans renvoyer le corps.

Avec REST, il devrait être auto-documenté via une API bien conçue et donc plus facile à utiliser.

C'est un excellent article sur REST. Cela m'aide vraiment à le comprendre aussi.


2
Je dirais que c'est la contrainte hypermédia de REST, plus que la contrainte d'interface uniforme qui supprime le besoin de WSDL.
Darrel Miller

3
Où découvrir "profil"? Comment apportez-vous de l'aide alors qu'au lieu d'un seul, vous en avez des dizaines? Tous les autres services reposent sur des documents écrits à la main et des API écrites manuellement, qui demandent beaucoup de travail et sont sujettes aux erreurs.
Eric Grange

1
Je suis d'accord avec @EricGrange - pourriez-vous expliquer COMMENT vous savez sur quelles entités vous pouvez effectuer des opérations CRUD (L) ON ... à moins que quelqu'un ne l'écrive quelque part?
BlueChippy

2

La spécification WSDL 2.0 a également ajouté la prise en charge des services Web REST. Le meilleur des deux scénarios du monde. Le problème est que WSDL 2.0 n'est pas encore largement pris en charge par la plupart des outils. WSDL 2.0 est recommandé par le W3C, WSDL1.1 n'est pas recommandé par le W3C mais largement pris en charge par les outils et les développeurs. Réf: http://www.ibm.com/developerworks/library/ws-restwsdl/


0

Le langage de description d'application Web (WADL) est un vocabulaire XML utilisé pour décrire les services Web RESTful.

Comme avec WSDL, un client générique peut charger un fichier WADL et être immédiatement équipé pour accéder à toutes les fonctionnalités du service Web correspondant.

Étant donné que les services RESTful ont des interfaces plus simples, WADL n'est pas aussi nécessaire pour ces services que WSDL l'est pour les services SOAP de type RPC.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.