Quelle est la raison d'utiliser le wadl ?

Question

Pour décrire RESTful, nous pouvons dire que chaque ressource a son propre URI. En utilisant HTTP GET, POST, PUT, DELETE, nous pouvons agir sur ces ressources. Toutes les ressources sont représentatives. Qui veut utiliser nos ressources, peut simplement les utiliser à partir d'un navigateur ou d'un client REST. C'est l'idée principale d'une architecture RESTful. Cette architecture permet d'offrir des services sur Internet. Alors pourquoi cette architecture a besoin de WADL. Que fait WADL que le HTTP standard ne fait pas ? Pourquoi WADL doit-il exister ?

Answer 1

L'objectif de WADL est de définir une contrat . Le contrat précise comment une partie peut en appeler une autre.

Quand vous créez une webapp à partir de rien - vous n'avez pas besoin de contrat et de WADL .

Lorsque vous intégrez votre système à celui de l'autre et que vous pouvez communiquer clairement avec son équipe de développement vous n'avez pas besoin de contrat et de WADL (parce que vous pouvez passer un appel téléphonique pour clarifier les choses).

Cependant, lorsque vous intégrez un système d'entreprise complexe à plusieurs autres systèmes d'entreprise complexes gérés par plusieurs entreprises (ou institutions fédérales) différentes, alors croyez-moi vous voulez de faire définir un contrat de communication aussi strictement que possible. Alors vous avez besoin de WADL ou de Open Specification. Vous en avez vraiment besoin .

Les personnes ayant peu d'expérience en entreprise ont tendance à considérer l'ensemble de l'informatique comme une collection d'applications web distinctes développées indépendamment. Mais la réalité de l'entreprise est parfois difficile. Parfois, vous ne pouvez même pas appeler ou écrire aux personnes qui développent l'application avec laquelle vous vous intégrez. Parfois, vous communiquez avec une application héritée qui n'est plus maintenue - elle fonctionne simplement et vous devez trouver comment communiquer avec elle correctement. Dans de telles conditions, vous avez besoin d'un contrat car il vous sauve la mise. .

En fait, la génération de clients est la caractéristique mineure de la définition du contrat. C'est juste un jouet. Le contrat oblige les mauvais communicateurs à communiquer clairement les règles d'intégration. C'est la principale raison d'utiliser WADL ou Open Specification ou autre.

Answer 2

L'utilisation du WADL implique que vous ayez la gentillesse de définir réellement les données et les documents que vous faites circuler dans les deux sens. Supposons que vous transmettiez des fragments XML, ils pourraient en fait faire partie d'un schéma défini.

Que vous utilisiez ou non la DL pour générer du code n'est pas très important pour moi. Ce qui compte, à mon avis subjectif, c'est qu'il est important d'avoir un accord formel sur les interfaces entre les partenaires commerciaux. Même si ce qui est transmis es évident, il permet d'identifier qui doit réparer quoi plus tard si quelqu'un modifie l'interface précédente.

Le format des données fait tout autant partie d'une interface que les noms des verbes.

Answer 3

Les WADL intéressent les personnes qui viennent du monde SOAP, où il est courant d'utiliser un générateur de code pour créer un code côté client basé sur les WSDL. Je ne pense pas que ce mécanisme soit utile dans REST, car il crée du code client qui est couplé aux points de terminaison du serveur.

Je pense que si vous définissez correctement vos types de médias et que vous utilisez l'hypermédia dans ces types de médias, il n'est pas nécessaire d'avoir le WADL. La description des points finaux disponibles est contenue dans les définitions des types de médias elles-mêmes. Et si vous vous dites maintenant, mais que l'application/xml ne contient aucune information sur les hyperliens disponibles, alors je dis BINGO. C'est pourquoi je ne pense pas que application/xml et application/json soient des types de médias appropriés pour REST. Je ne dis pas qu'il ne faut pas utiliser XML ou JSON, mais qu'il ne faut pas utiliser le nom générique du type de média.

L'autre intérêt de WADL est de pouvoir documenter les services REST. Malheureusement, il conduit les développeurs sur la mauvaise voie, car le WADL tente de documenter les points d'extrémité côté serveur. La documentation d'un service REST doit se concentrer principalement sur les types de médias. Un développeur de client devrait être capable d'écrire un client REST sans connaître aucune autre url que l'url Root.

Answer 4

WADL vous permet de générer du code, des tests et de la documentation. Il existe actuellement quelques outils très utiles utilisant WADL, vous pouvez voir quelques exemples aquí . Le problème avec le REST "pur", tel que décrit dans la thèse de Fielding, est d'écrire des clients supportant l'hypermédia (imaginez écrire une application client basée sur Java Swing par exemple). Avec WADL, cette tâche est complètement automatisée, et c'est un énorme avantage à mon avis. Les tests deviennent également beaucoup plus faciles.

Answer 5

Avant de donner mon explication, permettez-moi de dire que la plupart des extrémistes du REST pur le tourneront en dérision jusqu'au bout du monde. Je ne suis pas d'accord avec eux, car je préférerais que quelque chose soit fait, mais je tiens à ce que vous le sachiez.

WADL est une description d'une API de service web, un peu comme WSDL l'est pour les services web de type SOAP, qui est conçue pour être plus en phase avec les interfaces RESTful (ce que WSDL ne sait pas faire).

D'après mon expérience, son utilisation principale est de vous permettre de générer du code client qui peut appeler le service (pratique s'il s'agit d'une très grande API, ce qui permet littéralement de gagner des heures de travail). Il sert également à documenter une interface de type REST.