WSDL et REST : avantages et inconvénients

Question

En rapport :

Pourquoi utiliser REST plutôt que des services Web ?

Lorsque je décide de mettre en œuvre un service web en utilisant SOAP ou REST (j'entends par là HTTP/XML de manière RESTful), à quoi dois-je faire attention et à quoi dois-je penser ? Je suppose qu'il ne s'agit pas d'une solution unique, alors comment choisir celle que je dois utiliser ?

Answer 1

Les deux protocoles ont des utilisations très différentes dans le monde réel.

SOAP (qui utilise WSDL) est une norme XML lourde centrée sur le passage de documents. L'avantage de cette norme est que vos demandes et réponses peuvent être très bien structurées, et peuvent même utiliser une DTD. L'inconvénient est qu'il s'agit de XML et que c'est très verbeux. Cependant, c'est une bonne chose si deux parties doivent avoir un contrat strict (par exemple pour une communication interbancaire). SOAP vous permet également de superposer des éléments tels que WS-Security à vos documents. SOAP est généralement agnostique en matière de transport, ce qui signifie que vous n'avez pas nécessairement besoin d'utiliser HTTP.

REST est très léger et s'appuie sur la norme HTTP pour faire son travail. Il permet de mettre en place et de faire fonctionner rapidement un service web utile. Si vous n'avez pas besoin d'une définition stricte de l'API, c'est la voie à suivre. La plupart des services Web entrent dans cette catégorie. Vous pouvez créer une version de votre API afin que les mises à jour de l'API n'interrompent pas le fonctionnement pour les personnes utilisant d'anciennes versions (à condition qu'elles spécifient une version). REST nécessite essentiellement le protocole HTTP et est indépendant du format (ce qui signifie que vous pouvez utiliser XML, JSON, HTML, etc.).

En général, j'utilise REST, car je n'ai pas besoin de fonctionnalités WS-* sophistiquées. SOAP est cependant bon si vous voulez que les ordinateurs comprennent votre webservice à l'aide d'un WSDL. Les spécifications REST sont généralement lisibles par l'homme uniquement.

Answer 2

Les liens suivants fournissent des informations utiles sur WSDL et REST, y compris les avantages et les inconvénients.

Voici quelques points essentiels

1) SOAP a été conçu pour un environnement informatique distribué alors que REST a été conçu pour un environnement point à point.

2) WADL peut être utilisé pour définir l'interface des services REST.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl

Answer 3

Concernant WSDL (signifiant "SOAP") comme étant "lourd". Lourd comment ? Si l'ensemble d'outils fait tout le "gros travail" pour vous, alors pourquoi est-ce important ?

Je n'ai encore jamais eu besoin de consommer une API REST compliquée. Lorsque ce sera le cas, je pense que je souhaiterai disposer d'un WSDL, que mes outils se feront un plaisir de convertir en un ensemble de classes proxy, afin que je puisse simplement appeler ce qui semble être des méthodes. Au lieu de cela, je soupçonne que pour consommer une API REST non triviale, il sera nécessaire d'écrire à la main une quantité substantielle de code "léger".

Même lorsque tout cela est terminé, vous aurez toujours traduit en code une documentation lisible par l'homme, avec tous les risques que cela comporte que l'homme lise mal. Le WSDL étant une description du service lisible par une machine, il est beaucoup plus difficile de faire une "erreur de lecture".

---

Juste une note : depuis ce post, j'ai ont a eu l'occasion de travailler avec un service REST modérément compliqué. J'ai effectivement souhaité avoir un WSDL ou l'équivalent, et j'ai effectivement dû écrire beaucoup de code à la main. En fait, une partie substantielle du temps de développement a été consacrée à supprimer la duplication de tout le code qui appelait les différentes opérations du service "à la main".

Answer 4

Il est probable que ces informations doivent être commentées dans plusieurs des messages précédents, mais je n'ai pas encore la réputation de le faire.

Je pense qu'il est intéressant de constater qu'un grand nombre des avantages et des inconvénients souvent cités pour SOAP et REST ont (IMO) très peu à voir avec les valeurs ou les limites réelles des deux technologies. L'avantage le plus souvent cité pour REST est probablement qu'il est "léger" ou qu'il tend à être plus "lisible par l'homme". A un certain niveau, c'est certainement vrai, REST a une barrière à l'entrée plus basse - il y a moins de structure requise que SOAP (bien que je sois d'accord avec ceux qui ont dit qu'un bon outillage est en grande partie la réponse ici - dommage qu'une grande partie de l'outillage SOAP soit assez épouvantable).

Cependant, au-delà de ce coût d'entrée initial, je pense que l'impression REST provient d'une combinaison de la forme des URL de requête et de la complexité des données échangées par la plupart des services REST. REST tend à encourager des URL de requête plus simples et plus lisibles par l'homme et les données tendent également à être plus digestes. Cependant, dans quelle mesure ces caractéristiques sont-elles inhérentes à REST et dans quelle mesure sont-elles simplement accidentelles ? La structure URL plus simple est un résultat direct de l'architecture, mais elle pourrait tout aussi bien être appliquée aux services basés sur SOAP. Les données plus digestes sont plus probablement le résultat de l'absence de toute structure définie. Cela signifie que vous avez intérêt à garder vos formats de données simples, sinon vous allez avoir beaucoup de travail. Ainsi, la structure supplémentaire de SOAP, qui devrait être un avantage, permet en fait une conception négligée et cette conception négligée est ensuite utilisée comme une attaque contre la technologie.

Ainsi, pour l'échange de données structurées entre systèmes informatiques, je ne suis pas sûr que REST soit intrinsèquement meilleur que SOAP (ou vice-versa), ils sont simplement différents. Je pense que la comparaison ci-dessus entre REST et SOAP et le typage dynamique et statique est bonne. Là où les langages dynamiques ont tendance à avoir des problèmes, c'est dans la maintenance à long terme et l'entretien d'un système (et par long terme, je ne parle pas d'un an ou deux, mais de 5 ou 10 ans). Il sera intéressant de voir si REST rencontre les mêmes difficultés avec le temps. J'ai tendance à penser que ce sera le cas, donc si je construisais un système de traitement de l'information distribué, j'opterais pour SOAP comme mécanisme de communication (également en raison de la transmission et de la stratification des protocoles d'application et de la flexibilité qu'il offre, comme cela a été mentionné ci-dessus).

À d'autres endroits, cependant, REST semble plus approprié. AJAX entre le client et son serveur (indépendamment de la charge utile) en est un exemple majeur. Je ne me soucie pas beaucoup de la longévité de ce type de connexion et la facilité d'utilisation et la flexibilité sont un minimum. De même, si j'avais besoin d'un accès rapide à un service externe et que je ne pensais pas que j'allais me soucier de la maintenabilité de l'interaction dans le temps (encore une fois, je suppose que c'est là que REST va finir par me coûter plus cher, d'une manière ou d'une autre), alors je pourrais choisir REST juste pour pouvoir entrer et sortir rapidement.

Quoi qu'il en soit, ces deux technologies sont viables et, en fonction des compromis que vous souhaitez faire pour une application donnée, elles peuvent vous être utiles (ou non).

Answer 5

REST n'est pas un protocole ; c'est un style architectural. Ou un paradigme si vous voulez. Cela signifie qu'il est beaucoup moins bien défini que SOAP. Pour le CRUD de base, vous pouvez vous appuyer sur des protocoles standard tels que Atompub, mais pour la plupart des services, vous aurez plus de commandes que cela.

En tant que consommateur, SOAP peut être une bénédiction ou une malédiction, selon le support linguistique. Étant donné que SOAP s'inspire fortement d'un système strictement typé, il fonctionne mieux avec les langages typés statiquement. Pour un langage dynamique, il peut facilement devenir cruel et superflu. En outre, le support de la bibliothèque client n'est pas très bon en dehors du monde de Java et .NET.