WSDL vs REST Avantages et inconvénients
En relation:
Que dois-je connaître et à quoi penser si je souhaite implémenter un service Web utilisant SOAP ou REST (HTTP/XML de manière RESTful)? Je suppose que ce n’est pas une solution universelle, comment choisir lequel utiliser?.
Les liens suivants fournissent des informations utiles sur WSDL vs REST, notamment les avantages et les inconvénients
Quelques points clés sont que
1) SOAP a été conçu pour un environnement informatique réparti 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
Les deux protocoles ont des utilisations très différentes dans le monde réel.
SOAP (using WSDL) est une norme XML lourde centrée sur le passage de documents. L’avantage de cela est que vos demandes et vos réponses peuvent être très bien structurées et même utiliser une DTD. L'inconvénient est qu'il s'agit de XML et qu'il est très détaillé. Cependant, cela est utile 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. Il est bon de disposer rapidement d’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 entrent dans cette catégorie. Vous pouvez configurer votre API de manière à ce que ses mises à jour ne soient pas interrompues par 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 utile si vous souhaitez que les ordinateurs comprennent votre service Web à l'aide d'un WSDL. Les spécifications REST ne sont généralement lisibles que par l'homme.
Considérer WSDL (signifiant "SOAP") comme étant "lourd". La matière lourde comment? Si les outils font tout le "travail lourd" pour vous, alors pourquoi est-ce important?
Je n'ai encore jamais eu besoin de consommer une API compliquée REST. Dans ce cas, je pense que je souhaite 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 utiliser une API non-triviale basée sur REST, 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 converti la documentation lisible en code, avec le risque que les humains ne la lisent pas correctement. WSDL étant une description lisible par la machine du service, il est beaucoup plus difficile de "la lire mal".
Juste une remarque: depuis ce billet, j'ai ai eu l'occasion de travailler avec un service REST moyennement compliqué. En effet, je souhaitais un WSDL ou l’équivalent, et j’ai effectivement 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 appelé différentes opérations de service "à la main".
Cela fait probablement partie des commentaires de plusieurs des articles précédents, mais je n'ai pas encore le représentant pour le faire, alors allez-y.
Je pense qu’il est intéressant de noter que beaucoup des avantages et inconvénients souvent cités pour SOAP et REST ont très peu à voir avec les valeurs ou les limites réelles des deux technologies. Probablement le pro le plus cité pour REST est qu'il est "léger" ou tend à être plus "lisible par l'homme". À un certain niveau, cela est certainement vrai, REST a moins d'obstacle à l'entrée - 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 largement la réponse ici - dommage que beaucoup de l'outillage SOAP soit assez affreux).
Toutefois, au-delà de ce coût d’entrée, je pense que l’impression RESTprovient d’une combinaison de la forme des URL de requête et de la complexité des données échangées par la plupart des REST services. REST a tendance à encourager des URL de demande plus simples, plus lisibles par l'homme, et les données tendent également à être plus faciles à digérer. Cependant, dans quelle mesure sont-ils inhérents à REST et dans quelle mesure sont-ils simplement accidentels? La structure d'URL plus simple est un résultat direct de l'architecture - mais elle pourrait également être appliquée aux services basés sur SOAP. Les données les plus faciles à digérer sont probablement dues à l’absence de structure définie. Cela signifie que vous feriez mieux de garder vos formats de données simples ou vous allez devoir faire beaucoup de travail. Donc, ici, la structure supplémentaire de SOAP, ce qui devrait être un avantage, permet en réalité une conception négligée, qui est ensuite utilisée comme un Dig contre la technologie.
Donc, pour une utilisation dans l'échange de données structurées entre des systèmes informatiques, je ne suis pas sûr que REST soit intrinsèquement meilleur que SOAP (ou inversement), ils sont simplement différents. Je pense que la comparaison ci-dessus de REST vs SOAP avec le typage dynamique et statique est bonne. Là où les langues dyanmiques ont tendance à avoir des problèmes, c'est lors de la maintenance à long terme et de la maintenance 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 avec le temps. J'ai tendance à penser que si je construisais un système de traitement de l'information distribué, je m'engagerais dans le sens du mécanisme de communicationSOAP (en raison également de la transmission et de la superposition du protocole d'application ainsi que de la flexibilité qu'il offre mentionné ci-dessus).
Dans d'autres endroits cependant, 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 optimales. De même, si j'avais besoin d'un accès rapide à un service externe et que je ne pensais pas m'inquiéter de la maintenabilité de l'interaction au fil du temps (encore une fois, je suppose que c'est là que REST va aboutir cela me coûte plus cher, d’une manière ou d’une autre), puis 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 vous servir (ou mal).
Pour moi, nous devons faire attention lorsque nous utilisons le service Web Word. Nous devrions toujours spécifier si nous parlons de SOAP service Web, REST service Web ou autre type de service Web, car nous parlons de choses différentes et que les gens ne comprennent pas. plus si nous avons nommé tous les services Web.
En gros SOAP les services Web sont très bien établis depuis des années et ils suivent une spécification stricte décrivant comment communiquer avec eux en fonction de la spécification SOAP .. ... Maintenant REST Les services Web sont un peu plus récents et paraissent 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 pur. Les gens l'apprécient car ils peuvent analyser le fichier XML comme ils le souhaitent sans avoir à traiter avec un protocole de communication plus sophistiqué tel que SOAP.
Pour moi REST les services sont presque comme si vous créez un servlet au lieu d’un SOAP service Web. La servlet récupère les données et les renvoie. Le format des données est basé sur XML. Nous pouvons aussi imaginer utiliser autre chose que xml si nous voulons. Par exemple, des balises pourraient être utilisées à la place de xml et ce ne serait plus REST mais quelque chose d'autre (pourrait être encore plus léger en terme de poids car xml n'est pas léger par nature). Appellerions-nous cela encore un service Web? Oui, nous pourrions le faire, mais cela ne suivra aucune norme actuelle. C’est là le principal problème si nous commençons à appeler tous les services Web, mais nous pouvons le faire comme nous le voulons, 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 normalisé. Cela nécessite donc que le serveur et le client s’entendent sur le format des données, alors qu’avec SOAP tout est déjà prédéfini et que le serveur et le client peuvent interagir sans se connaître car ils suivent le même standard.
Ce que les gens n'aiment pas SOAP c'est qu'ils ont du mal à le comprendre et qu'ils ne peuvent pas générer les requêtes manuellement. Les ordinateurs peuvent très bien le faire, c’est pourquoi nous devons être clairs: les requêtes et services de services Web sont-ils supposés être utilisés directement par les utilisateurs finaux ou sommes-nous d’accord pour dire que les services Web sont situés sous l’API appelée par les systèmes normes?
REST n'est pas un protocole; C'est un style architectural. Ou un paradigme si vous voulez. Cela signifie que la définition de SOAP est beaucoup moins stricte. 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, en fonction de la prise en charge linguistique. Puisque SOAP est très bien modelé sur un système strictement typé, cela fonctionne mieux avec les langages statiquement typés. Pour un langage dynamique, il peut facilement devenir cruel et superflu. De plus, la prise en charge des bibliothèques clientes n’est pas aussi bonne en dehors du monde Java et .NET.
SOAP: Il peut également être transporté via SMTP, ce qui signifie que nous pouvons appeler le service en utilisant le format de texte simple Email
Un cadre/moteur supplémentaire doit être installé sur la machine cliente de service Web pour convertir le message SOAP en structure d'objets respective dans divers langages.
RESTE: WSDL2.0 prend désormais en charge la description du service Web REST également
Nous pouvons utiliser lorsque vous souhaitez rendre votre service aussi léger, par exemple, appeler à partir d'appareils mobiles tels qu'un téléphone portable, un pda, etc.
pour les systèmes d'entreprise dans lesquels votre système est confiné au sein de vos sociétés, il est plus facile et approprié d'utiliser du savon, car vous avez presque le contrôle de vos clients. c'est plus facile car il existe une variété d'outils qui créent des classes (proxies) et qui ressemblent à votre OOP habituel, qui correspond à votre environnement Java ou .net (utilisé par la plupart des entreprises).
J'utiliserais REST pour les applications faisant face à Internet afin d'exposer des interfaces (comme Twitter api), car les clients peuvent utiliser des javascripts ou du code HTML ou autres, dans lesquels la frappe n'est pas stricte. REST être plus libéral a plus de sens.
Également pour les clients faisant face à Internet (World Wide Web), il est plus facile d’analyser json ou xml sortant d’une interface de repos plutôt qu’un pur xml provenant d’une interface soap. il est difficile d'utiliser des proxies sur javascript et javascript ne prend pas naturellement en charge les objets. Si vous utilisez REST avec javascript, vous devez généralement analyser la chaîne json et le tour est joué. Les interfaces Internet sont généralement très simples (donc la plupart du temps, leur analyse simple) et n’exigent généralement pas de cohérence, c’est pourquoi REST est suffisant.
Pour les applications d'entreprise, je ne pense pas que REST soit adéquat car 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 destiné aux systèmes d'entreprise, REST à Internet ou au WWW. Vous pouvez l’utiliser de façon interchangeable, mais vous pourriez vous retrouver dans une situation difficile en n’utilisant pas le bon outil pour le travail.
désolé pour mon mauvais anglais.
Pour la défense de REST, il suit de près les principes de HTTP et d'adressabilité, par ex. Les opérations de lecture utilisent GET, les opérations de mise à jour utilisent POST, etc. Je trouve cette approche beaucoup plus propre. Le livre Rreful Web Services d’Oreilly explique cela beaucoup mieux que moi. Si vous le lisez, vous préférerez peut-être l’approche REST
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 plate-forme et du protocole, au protocole RPC?". REST a été développé à partir de la question "Comment utiliser les informations qui ont permis à HTTP de réussir si bien pour le Web et les utiliser pour l'informatique distribuée?"
SOAP consiste à vous donner des outils pour que la programmation distribuée ressemble à ... de la programmation. REST tente d'imposer un style simplifiant les interfaces distribuées, de sorte que les ressources distribuées puissent se référer les unes aux autres comme les pages HTML distribuées pouvant se référer les unes aux autres. L’une des façons de le faire est de tenter (principalement) de limiter les opérations à "CRUD" sur les ressources (créer, lire, mettre à jour, supprimer).
REST est encore jeune - bien qu'il soit orienté vers les services "lisibles par l'homme", il n'exclut pas les services d'introspection, etc., ni la création automatique de mandataires. Cependant, ceux-ci n'ont pas été normalisé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 novices à choisir REST = sauf s'ils doivent utiliser des fonctionnalités spécifiques fournies par SOAP.
À mon avis, si vous implémentez une API "greenfield" et que vous en savez très peu sur les clients possibles, je choisirais REST, car le style qu'il encourage tend à rendre les interfaces compréhensibles, et facile à développer pour. Si vous en savez beaucoup sur le client et le serveur, et qu'il existe des outils spécifiques SOAP qui faciliteront la vie des deux, je ne serais cependant pas religieux à propos de REST.
Le jeu d'outils du côté client serait un. Et la familiarité avec SOAP sert l’autre. De nos jours, de plus en plus de services empruntent la voie RESTful et il est possible de tester de tels services avec de simples exemples cURL. Bien que ce ne soit pas si difficile d'implémenter les deux méthodes et de permettre l'utilisation la plus large possible des clients.
Si vous devez en choisir un, je suggérerais REST, c'est plus facile.
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 oublié le point le plus important concernant la différence entre les 2 systèmes: SOAP utilise des types complexes pour non seulement vous donner la données, mais validez-les et conservez-les dans la désignation de type stricte pour laquelle il a été défini. Un WSDL vous indique le format et le type de données, vous permet d'ajouter des règles de style de motif reg-ex et définit le nombre de fois qu'un élément de données doit être autorisé et peut être autorisé dans une demande/réponse. . Reste d'autre part n'a aucun de ces mécanismes.
SOAP est complexe et lourd, car il vous permet d’envoyer des données hiérarchiques complexes. REST est un texte en clair, avec l'origine et le noeud final triant les règles.
SOAP est indépendant de l'entreprise, car toutes les règles de données sont intégrées au document.
La différence entre SOAP et REST est que SOAP est un schéma autonome orienté métier. REST est un document texte.
Vous pouvez facilement effectuer la transition de vos composants Web WCF générés par le WSDL vers d'autres utilisations en modifiant simplement vos paramètres de configuration. Vous pouvez accéder à HTTP, puis également aux canaux nommés, TCP, 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é, la conversation à double sens, les transactions, la concurrence, etc.
REST vous limite pratiquement à HTTP (ce qui est correct dans de nombreux cas).