Services RESTful – Equivalent WSDL

J’ai lu des articles sur REST et SOAP, et j’ai compris pourquoi l’implémentation 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 l’équivalent “WSDL” dans le monde REST. J’ai vu des messages 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 lier par programmation une définition et de créer des classes de proxy au lieu de coder manuellement? Je ne veux pas entrer dans un débat philosophique, simplement pour trouver la raison pour laquelle il n’y a pas de WSDL dans REST, ou pourquoi ce n’est pas nécessaire. Merci.

Le langage WADL ( Web Application Description Language ) est fondamentalement l’équivalent de WSDL pour les services RESTful, mais il existe une controverse sur le fait de savoir si quelque chose de ce genre est nécessaire.

Joe Gregorio a écrit un article intéressant sur ce sujet qui mérite d’être lu.

WSDL décrit les points de terminaison de service. Les clients REST ne doivent pas être couplés à des points de terminaison de serveur (c.-à-d. Qu’ils ne doivent pas connaître les URL à l’avance). Les clients REST sont couplés sur les types de média transférés entre le client et le serveur.

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

RSDL a pour but de se reposer comme une hypermédia, autrement dit, il a plus d’informations qu’un descripteur de service comme WSDL ou WADL. Par exemple, il contient des informations sur la navigation, comme l’hypertexte et les hyperliens.

Par exemple, étant donné une ressource en cours, vous avez un ensemble de liens vers une autre ressource liée.

Cependant, je n’ai pas trouvé de clients Rest qui prennent en charge ce format ou Rest Server Solutions avec une fonctionnalité permettant de le générer automatiquement.

Je pense qu’il y a un long chemin à parcourir à 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

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

Ma conclusion: Aujourd’hui, WADL est plus commun que les frameworks de repos et d’intégration comme Camel CXF qui supportent déjà WADL (générer et consumr), car il est similaire à WSDL, donc plus facile à comprendre dans ce processus de migration (SOAP à REST).

Voyons les prochains chapitres;)

Il existe un langage RSDL (Restful Service Description Language) équivalent à WSDL. L’URL ci-dessous décrit ses pratiques http://en.wikipedia.org/wiki/HATEOAS et http://en.wikipedia.org/wiki/RSDL . Le problème est que nous avons beaucoup d’outils pour générer du code de wsdl à java, ou inversement. Mais je n’ai trouvé aucun outil pour générer du code à partir de RSDL.

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

D’accord sans réserve, c’est pourquoi j’ai personnellement utilisé Swagger.io

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

Donc, fondamentalement, j’utilise Swagger pour décrire mes modèles, 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

WSDL est extensible pour permettre la description des points de terminaison 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 les verbes HTTP et l’URI pour représenter un état d’objects.

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

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

POST doit retourner un ID généré côté serveur, en utilisant le code d’état 201 CREATED et l’en-tête Location: *new_profile_id* (par exemple 12345)

Je peux ensuite effectuer des mises à jour en modifiant l’état de /profile/12345 à l’aide du verbe HTTP POST , par exemple pour modifier mon adresse e-mail ou mon numéro de téléphone. Évidemment changer l’état de l’object 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 retourner le corps.

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

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

La spécification WSDL 2.0 a également pris en charge les services Web REST. Meilleur scénario des deux mondes. Le problème est que WSDL 2.0 n’est pas encore largement pris en charge par la plupart des outils existants. 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/

Le langage WADL (Web Application Description Language) 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.

Comme les services RESTful ont des interfaces plus simples, WADL n’est pas aussi nécessaire pour ces services que WSDL pour les services SOAP de type RPC.