WSDL vs REST Avantages et inconvénients

En relation:

Pourquoi utiliser REST au lieu des services Web?

Lorsque je décide d'implémenter un service Web en utilisant SOAP ou REST (j'entends par là HTTP / XML de manière RESTful), à quoi dois-je être conscient et à quoi dois-je penser? Je suppose que ce n'est pas une solution universelle, alors comment choisir celle à utiliser.

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

SOAP (utilisant WSDL) est un standard XML lourd centré sur la transmission de documents. L'avantage de ceci 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 qu'il est très détaillé. Cependant, c'est bien si deux parties doivent avoir un contrat strict (par exemple pour la communication interbancaire). SOAP vous permet également de superposer des éléments tels que WS-Security sur vos documents. SOAP est généralement indépendant du 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. C'est formidable de mettre rapidement en place un service Web utile. Si vous n'avez pas besoin d'une définition d'API stricte, c'est la voie à suivre. La plupart des services Web appartiennent à cette catégorie. Vous pouvez versionner votre API afin que les mises à jour de l'API ne l'interrompent pas pour les personnes utilisant d'anciennes versions (à condition qu'elles spécifient une version). REST nécessite essentiellement HTTP et est indépendant du format (ce qui signifie que vous pouvez utiliser XML, JSON, HTML, peu importe).

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

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

Quelques points clés sont que

1) SOAP a été conçu pour un environnement informatique distribué où 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

Concernant WSDL (signifiant "SOAP") comme étant "lourd". Le lourd compte 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. Quand je le ferai, j'espère que je souhaiterai un WSDL, que mes outils convertiront volontiers 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 fait, vous aurez toujours traduit une documentation lisible par l'homme en code, avec tout le risque que les humains lisent mal. Étant donné que WSDL est une description lisible par machine du service, il est beaucoup plus difficile de «mal la lire».

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

Cela appartient probablement vraiment aux commentaires dans plusieurs des articles ci-dessus, mais je n'ai pas encore le représentant pour le faire, alors voilà.

Je pense qu'il est intéressant de constater que de nombreux avantages et inconvénients souvent cités pour SOAP et REST ont très peu à voir (IMO) avec les valeurs ou limites réelles des deux technologies. L'avantage le plus cité pour REST est probablement qu'il est "léger" ou a tendance à être plus "lisible par l'homme". À un certain niveau, c'est certainement vrai, REST a une barrière à l'entrée plus faible - il y a moins de structure requise que SOAP (même si je suis 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 affreux).

Au-delà de ce coût d'entrée initial cependant, je pense que l'impression REST provient d'une combinaison de la forme des URL de demande et de la complexité des données échangées par la plupart des services REST. REST a tendance à encourager des URL de demande plus simples et plus lisibles par l'homme et les données ont également tendance à être plus digestes. Dans quelle mesure cependant sont-ils inhérents à REST et dans quelle mesure sont-ils simplement accidentels. La structure d'URL plus simple est le résultat direct de l'architecture - mais elle pourrait également être appliquée aux services basés sur SOAP. Les données les plus digestes sont plus susceptibles d'être le résultat de l'absence de toute structure définie. Cela signifie que vous feriez mieux de garder vos formats de données simples ou vous allez devoir travailler beaucoup. Alors voici la structure supplémentaire de SOAP,

Donc, pour une utilisation dans 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 de REST vs SOAP au typage dynamique vs statique est bonne. Là où les langages dyanmiques ont tendance à avoir des problèmes, c'est dans la maintenance et l'entretien à long terme d'un système (et à long terme, je ne parle pas d'un an ou deux, je parle de 5 ou 10). Il sera intéressant de voir si REST rencontre les mêmes défis au fil du temps. J'ai tendance à penser que si je construisais un système de traitement de l'information distribué, je serais attirée par SOAP comme mécanisme de communication (également en raison de la superposition et de la flexibilité du protocole de transmission et d'application qu'il offre comme cela a été mentionné ci-dessus).

Dans d'autres endroits, REST semble plus approprié. AJAX entre le client et son serveur (quelle que soit la charge utile) en est un exemple majeur. Je ne me soucie guère de la longévité de ce type de connexion et la facilité d'utilisation et la flexibilité sont au 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 au fil du temps (encore une fois, je suppose que c'est là que REST va finir par me coûter plus cher, dans un sens ou autre), alors je pourrais choisir REST juste pour pouvoir entrer et sortir rapidement.

Quoi qu'il en soit, ce sont deux technologies viables et en fonction des compromis que vous souhaitez faire pour une application donnée, elles peuvent bien (ou mal) vous servir.

REST n'est pas un protocole; C'est un style architectural. Ou un paradigme si vous le souhaitez. Cela signifie que SOAP est beaucoup moins défini. Pour 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. Puisque SOAP est très largement modelé sur 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. De plus, la prise en charge de la bibliothèque client n'est pas très bonne en dehors du monde de Java et .NET

Pour moi, nous devons être prudents lorsque nous utilisons le mot service Web. Nous devrions tout le temps spécifier si nous parlons de service Web SOAP, de service Web REST ou d'autres types de services Web, car nous parlons de choses différentes ici et les gens ne comprennent plus si nous les nommons tous services Web.

Fondamentalement, les services Web SOAP sont très bien établis depuis des années et ils suivent une spécification stricte qui décrit comment communiquer avec eux en fonction de la spécification SOAP. Les services Web REST sont maintenant un peu plus récents et semblent fondamentalement plus simples car ils n'utilisent aucun protocole de communication. Fondamentalement, ce que vous envoyez et recevez lorsque vous utilisez un service Web REST est du XML brut. Les gens l'aiment parce qu'ils peuvent analyser le XML comme ils le souhaitent sans avoir à gérer un protocole de communication plus sophistiqué comme SOAP.

Pour moi, les services REST sont presque comme si vous créiez un servlet au lieu d'un service Web SOAP. Le servlet récupère les données et les renvoie. Le format des données est basé sur xml. On peut aussi imaginer utiliser autre chose que xml si on le souhaite. Par exemple, les balises pourraient être utilisées à la place de xml et ce ne serait plus REST mais autre chose (pourrait être encore plus léger en termes de poids car xml n'est pas léger par nature). Appellerions-nous cela encore un service Web? Oui, nous le pourrions, mais cela ne suivra aucune norme actuelle et c'est le principal problème ici si nous commençons à appeler tous les services Web, mais nous pouvons le faire comme nous le voulons, alors nous perdons du côté de l'interopérabilité. Cela signifie que le format des données échangées avec le service Web n'est plus standardisé.

Ce que les gens n'aiment pas avec SOAP, c'est qu'ils ont du mal à le comprendre et qu'ils ne peuvent pas générer les requêtes manuellement. Cependant, les ordinateurs peuvent très bien le faire, c'est donc là que nous devons être clairs: les requêtes et les réponses des services Web sont-elles censées être utilisées directement par les utilisateurs finaux ou sommes-nous d'accord que les services Web sont sous l'API appelée par les systèmes informatiques sur la base de certains normalisés? normes?

SOAP : Il peut également être transporté via SMTP, ce qui signifie que nous pouvons également appeler le service en utilisant le format de texte simple Email

Il a besoin d'un cadre / moteur supplémentaire doit être dans la machine client du service Web pour convertir le message SOAP en structure d'objets respectifs dans différentes langues.

REST : maintenant WSDL2.0 prend en charge la description du service Web REST également

Nous pouvons utiliser lorsque vous souhaitez rendre votre service aussi léger, par exemple en appelant à partir d'appareils mobiles tels que téléphone portable, PDA, etc.

pour les systèmes d'entreprise dans lesquels votre système est confiné dans vos entreprises, il est plus facile et plus approprié d'utiliser du savon parce que vous contrôlez presque les clients. c'est plus facile car il existe une variété d'outils qui créent des classes (proxies) et on dirait que vous faites votre POO standard qui correspond à votre environnement java ou .net (dans lequel la plupart des entreprises utilisent).

J'utiliserais REST pour les applications Internet pour exposer des interfaces (comme l'api Twitter) car les clients peuvent utiliser des scripts javascripts ou html ou d'autres dans lesquels la saisie n'est pas stricte. REST est plus libéral a plus de sens.

Aussi pour les clients Internet (World Wide Web), il est plus facile d'analyser json ou xml sortant d'une interface de repos plutôt que purement xml provenant d'une interface soap. il est difficile d'utiliser des proxies sur javascript et javascript ne prend naturellement pas en charge les objets. Si vous utilisez REST avec javascript, vous analyserez généralement la chaîne json et vous êtes prêt. Les interfaces Internet sont généralement très simples (donc la plupart du temps, leur analyse est simple) et ne nécessitent généralement pas de cohérence, c'est pourquoi REST est suffisamment adéquat.

Pour les applications d'entreprise, je ne pense pas que REST soit adéquat parce que les transactions, la sécurité, le typage strict, les schémas jouent un rôle très important dans le développement d'applications d'entreprise, c'est pourquoi SOAP leur convient mieux.

Ma conclusion est que SOAP est pour les systèmes d'entreprise, REST est pour Internet ou WWW. Vous pouvez l'utiliser de manière interchangeable, mais vous pourriez avoir du mal à ne pas utiliser le bon outil pour le travail.

Désolé pour mon mauvais anglais.

Pour défendre REST, il suit de près les principes de HTTP et d'adressabilité, par exemple les opérations de lecture utilisent GET, les opérations de mise à jour utilisent POST, etc. Je trouve que c'est une approche beaucoup plus propre. Le livre Oreilly RESTful Web Services explique cela bien mieux que moi, si vous le lisez, je pense que vous préféreriez l'approche REST

L'ensemble d'outils côté client en serait un. Et la familiarité avec les services SOAP de l'autre. De plus en plus de services empruntent la voie RESTful ces jours-ci, et le test de ces services peut être effectué avec de simples exemples cURL. Cependant, il n'est pas si difficile d'implémenter les deux méthodes et de permettre l'utilisation la plus large des clients.

Si vous avez besoin d'en choisir un, je suggérerais REST, c'est plus facile.

Les réponses précédentes contiennent beaucoup d'informations, mais je pense qu'il y a une différence philosophique qui n'a pas été soulignée. SOAP était la réponse à "comment créer un successeur moderne, orienté objet, indépendant de la plateforme et du protocole de RPC?". REST s'est développé à partir de la question: «comment exploiter les connaissances qui ont fait le succès de HTTP sur le Web et les utiliser pour l'informatique distribuée?

SOAP vise à vous donner des outils pour faire ressembler la programmation distribuée à ... la programmation. REST essaie d'imposer un style pour simplifier les interfaces distribuées, afin que les ressources distribuées puissent se référer les unes aux autres comme les pages html distribuées peuvent se référer les unes aux autres. Une façon de le faire est de tenter de restreindre (principalement) les opérations à "CRUD" sur les ressources (créer, lire, mettre à jour, supprimer).

REST est encore jeune - bien qu'il soit orienté vers des services «lisibles par l'homme», il n'exclut pas les services d'introspection, etc. ou la création automatique de proxies. Cependant, ceux-ci n'ont pas été standardisés (au moment où j'écris). SOAP vous donne ces choses, mais (IMHO) vous donne "seulement" ces choses, alors que le style imposé par REST encourage déjà la diffusion des services Web en raison de sa simplicité. J'encourage moi-même les fournisseurs de services débutants à choisir REST à moins qu'ils ne disposent de fonctionnalités spécifiques fournies par SOAP.

À mon avis, donc, si vous implémentez une API "greenfield" et que vous ne savez pas grand chose sur les clients potentiels, je choisirais REST car le style qu'il encourage tend à rendre les interfaces compréhensibles et faciles à développer. Si vous en savez beaucoup sur le client et le serveur et qu'il existe des outils SOAP spécifiques qui faciliteront la vie des deux, alors je ne serais pas religieux à propos de REST.

Vous pouvez facilement faire la transition de vos composants Web WCF crachant WSDL vers d'autres utilisations simplement en modifiant vos paramètres de configuration. Vous pouvez passer par HTTP, puis également par des canaux nommés, tcp, des protocoles personnalisés, etc. sans avoir à changer votre code. Je pense que les composants WCF peuvent également être plus faciles à configurer pour des éléments tels que la sécurité, les appels bidirectionnels, les transactions, la concurrence, etc.

REST vous limite à peu près à HTTP (ce qui est bien dans de nombreux cas).

Je sais que cette discussion est ancienne, mais après avoir lu toutes les réponses et commenté, je pense que tout le monde a manqué le point le plus important sur la différence entre les 2 systèmes: SOAP utilise des types complexes non seulement pour vous donner les données, mais aussi valider et conservez-le dans la désignation de type stricte pour laquelle il a été défini. Un WSDL vous indique quel est le format de données, quel est le type de données, vous permet d'ajouter des règles de style modèle reg-ex et définit combien de fois un élément de données doit être, et peut être, autorisé dans une demande / réponse . Le repos en revanche n'a aucun de ces mécanismes.

SOAP est complexe et lourd car il vous permet d'envoyer des données hiérarchiques complexes et lourdes. REST est du texte brut, avec l'origine et le point de terminaison triant les règles.

SOAP est indépendant de l'entreprise, car toutes les règles de données sont intégrées dans le document.

La différence entre SOAP et REST est que SOAP est un schéma autonome orienté métier. REST est un document texte.