WSDL vs REST avantages et inconvénients

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

SOAP (utilisant WSDL) est une norme XML lourde qui est centrée sur le transfert de document. L'avantage avec 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 est XML, et est très verbeux. Toutefois, c'est une bonne chose si deux parties doivent avoir un contrat strict(par exemple pour la communication interbancaire). Le savon vous permet également de calquer des choses comme WS-sécurité sur vos documents. SOAP est généralement transport-agnostique, ce qui signifie que vous n'avez pas nécessairement besoin D'utiliser HTTP.

reste est très léger, et s'appuie sur le standard HTTP pour faire son travail. Il est idéal pour obtenir un utile service web et exécuter rapidement. Si vous n'avez pas besoin d'une stricte Définition API, c'est la voie à suivre. La plupart des services web entrent dans cette catégorie. Vous pouvez modifier votre API de sorte que les mises à jour de L'API ne le cassent pas pour les personnes utilisant Vieux versions (dans la mesure où elles spécifient une version). Le repos nécessite essentiellement HTTP, et est format-agnostic (ce qui signifie que vous pouvez utiliser XML, JSON, HTML, quoi que ce soit).

généralement J'utilise le repos, parce que je n'ai pas besoin de fantaisie WS-* fonctionnalités. SOAP est bon cependant si vous voulez que les ordinateurs comprennent votre service Web en utilisant un WSDL. Les spécifications REST ne sont généralement lisibles que par l'utilisateur.

concernant WSDL (qui signifie "savon") en tant que "Poids lourd". De lourdes questions comment? Si l'ensemble d'outils fait tout le "levage lourd" pour vous, alors pourquoi est-ce important?

Je n'ai jamais eu besoin de consommer une API REST compliquée. Quand je le fais, je m'attends à ce que je souhaite un WSDL, que mes outils convertiront volontiers en un ensemble de classes de proxy, donc je peux juste appeler ce qui semble être des méthodes. Au lieu de cela, je soupçonne que pour consommer une API non triviale basée sur le repos, il sera nécessaire pour écrire à la main une quantité substantielle de "poids léger" code.

même si tout cela est fait, vous aurez quand même traduit de la documentation lisible par les humains en code, avec tout le risque que les humains ne la lisent pas correctement. Depuis WSDL est une description du service lisible par machine, il est beaucoup plus difficile de "lire mal".

Juste une remarque: depuis ce post, j'ai ont eu l'occasion de travailler avec un service de repos modérément compliqué. J'ai, en effet, souhaité une WSDL ou l'équivalent, et j'ai dû, en effet, écrire beaucoup de code à la main. En fait, une grande partie du temps de développement a été consacrée à supprimer la duplication de tous les codes qui appelaient différentes opérations de service "à la main".

cela appartient probablement vraiment comme commentaires dans plusieurs des postes ci-dessus, mais je n'ai pas encore le rep pour le faire, alors voici.

je pense qu'il est intéressant que beaucoup de pour et de contre souvent cités pour le savon et le repos ont (IMO) très peu à faire avec les valeurs réelles ou les limites des deux technologies. Probablement le pro le plus cité pour le repos est qu'il est "léger" ou a tendance à être plus "lisible par l'homme". À un certain niveau, cela est certainement vrai, le reste ne avoir une barrière inférieure à l'entrée - il est moins nécessaire de structure que le savon (bien que je suis d'accord avec ceux qui ont dit que bon outillage est en grande partie la réponse ici - trop mauvais de l'outillage savon est assez terrible).

au-delà de ce coût initial d'entrée cependant, je pense que l'impression de repos vient d'une combinaison de la forme des URLs de demande et la complexité des données échangées par la plupart des services de repos. Le repos tend à encourager la requête plus simple, plus lisible par l'homme Les url et les données tend à être plus digeste. Dans quelle mesure sont-ils cependant inhérents au repos 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 digérables 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 simple ou vous allez être dans un beaucoup de travail. Donc, ici, du SAVON structure supplémentaire, qui devrait être un avantage est en fait permettre un design bâclé et ce design bâclé est ensuite utilisé comme une dig contre la technologie.

donc pour l'utilisation dans l'échange de données structurées entre les systèmes informatiques, Je ne suis pas sûr que REST est intrinsèquement mieux que SOAP (ou vice-versa), ils sont juste différents. Je pense que la comparaison ci-dessus de REST vs SOAP à dynamic vs. static typing est bonne. Là où les langues dyanmic ont tendance à être en difficulté, maintenance à long terme et entretien 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 se heurte aux mêmes défis au fil du temps. J'ai tendance à penser qu'il en sera ainsi si je construisais un système de traitement de l'information distribué, Je graviterais sur SOAP comme le mécanisme de communication (également en raison de la stratification et de la souplesse du protocole de transmission et d'application qu'il offre comme il a été mentionné ci-dessus).

Dans d'autres endroits, bien que le repos semble plus approprié. AJAX entre le client et son serveur (indépendamment de la charge utile) est un exemple majeur. Je n'ai pas beaucoup de soins pour la longévité de ce type de connexion et la facilité d'utilisation et la flexibilité sont au premimum. De même, si j'avais besoin d'un accès rapide à certains services externes et je ne pensais pas que j'allais soins sur la maintenabilité de l'interaction au cours du temps (encore une fois je suppose que c'est là que le REPOS va coûter plus de moi, d'une façon ou d' un autre), puis je pourrais choisir le repos juste pour que je puisse entrer et sortir rapidement.

de toute façon, ce sont deux technologies viables et selon les compromis que vous voulez faire pour une application donnée, ils peuvent vous servir bien (ou mal).

REST n'est pas un protocole, c'est un style architectural. Ou un paradigme si vous le souhaitez. Cela signifie que C'est beaucoup plus flou défini que le savon est. Pour le CRUD de base, vous pouvez vous appuyer sur des protocoles standards comme Atompub, mais pour la plupart des services, vous aurez plus de commandes que ça.

en tant que consommateur, le savon peut être une bénédiction ou une malédiction, selon le support de la langue. Étant donné que SOAP est très calqué sur un système strictement typé, il fonctionne mieux avec statically typed langue. Pour un langage dynamique, elle peut facilement devenir cruelle et superflue. En outre, le support client-bibliothèque n'est pas si bon en dehors du monde de Java et. NET

pour moi, nous devrions faire attention quand nous utilisons le mot service web. Nous devrions tout le temps spécifier si nous parlons de SOAP web service, REST web service ou d'autres types de services web parce que nous parlons de choses différentes ici et les gens ne comprennent plus si nous avons nommé tous les services web.

essentiellement SOAP services web sont très bien établis depuis des années et ils suivent une spécification stricte qui décrivent la façon de communiquer avec eux basé sur la spécification du savon. Maintenant REST services web sont un peu plus récents et ressemble fondamentalement plus simple parce qu'ils n'utilisent aucun protocole de communication. Fondamentalement, ce que vous envoyez et recevez lorsque vous utilisez un service REST web est XML simple. Les gens aiment cela parce qu'ils peuvent analyser le xml comme ils le veulent sans avoir à traiter avec un protocole de communication plus sophistiqué comme SOAP.

pour moi les services de repos sont presque comme si vous créiez un servlet au lieu d'un web SOAP service. Le servlet reçoit les données et les renvoie. Le format des données est fondé sur le langage xml. Nous pouvons aussi imaginer d'utiliser autre chose que xml si nous le voulons. Par exemple, des balises pourraient être utilisées à la place de xml et ce ne serait plus du repos mais quelque chose d'autre (pourrait être encore plus léger en terme de poids parce que xml n'est pas léger par nature). Nous appelons encore un service web? Oui, nous pourrions mais cela ne suivra aucune norme actuelle et c'est la question principale ici si nous commençons à appeler tout services web, mais nous pouvons le faire de la manière que nous voulons ensuite nous perdre sur l'interopérabilité côté des choses. Cela signifie que le format des données échangées avec le service web n'est plus standardisé. Cela exige alors que le serveur et le client s'accordent sur le format des données alors que tout cela est déjà prédéfini avec SOAP et le serveur et le client peuvent interférer sans se connaître parce qu'ils suivent le même standard.

ce que les gens n'aiment pas avec du SAVON est qu'ils ont du mal à le comprendre et ils ne peuvent pas générer les requêtes manuellement. Les ordinateurs peuvent très bien le faire, cependant, c'est 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 API appelé par les systèmes informatiques sur la base de certaines normes normalisées?

SOAP : il peut être transporté via SMTP aussi, signifie que nous pouvons invoquer le service en utilisant le format de texte simple E-Mail aussi

Il faut plus de cadre/moteur doit être en web service consommateur de la machine à convertir le message SOAP pour les objets respectifs de la structure en plusieurs langues.

REST : Now WSDL2.0 supports pour décrire le service REST web aussi

Nous pouvons utiliser lorsque vous vous voulez rendre votre service léger, par exemple appeler à partir d'appareils mobiles comme le téléphone cellulaire, pda, etc...

pour les systèmes d'entreprise dans lesquels votre système est confiné au sein de vos entreprises, il est plus facile et approprié d'utiliser soap parce que vous êtes presque en contrôle des clients. c'est plus facile puisqu'il y a une variété d'outils qui créent des classes (proxies) et qui semblent faire votre OOP régulier qui correspond à votre environnement java ou.net (dans lequel la plupart des entreprises utilisent).

je voudrais utiliser le repos pour les applications Internet face pour exposer les interfaces (comme l'api twitter) depuis les clients peuvent être en utilisant javascripts ou html ou d'autres dans lesquels la dactylographie n'est pas stricte. Le reste est plus libéral, c'est plus logique.

aussi pour internet face aux clients (World wide web), il est plus facile de parser JSON ou xml sortant d'une interface de repos plutôt qu'un xml purement provenant d'une interface soap. il est difficile d'utiliser des mandataires sur javascript et javascript ne supporte pas naturellement les objets. Si vous utilisez REST avec javascript, vous devez simplement analyser le json string et vous partez. les interfaces faisant face à internet sont généralement très simples (donc la plupart du temps son parsing simple) et ne demande généralement pas la cohérence qui est la raison pour laquelle le repos est suffisant.

pour les applications d'entreprise Je ne pense pas que le repos 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 qui est pourquoi SOAP est plus adapté pour eux.

ma conclusion est que le savon est pour Des systèmes de l'entreprise, le RESTE est pour l'Internet ou WWW. Vous pouvez l'utiliser de façon interchangeable, mais il se peut que vous ayez de la difficulté à utiliser le bon outil pour le travail.

désolé pour mon mauvais anglais.

pour la défense du repos, il suit de près les principes de HTTP et d'adressabilité, par exemple lire les opérations utiliser GET, mettre à jour les opérations Utiliser POST, etc. Je trouve cela beaucoup plus propre approche. The Oreilly book RESTful Web Services explique cela bien mieux que je ne peux, si vous le lisez je pense que vous préféreriez l'approche du repos

la boîte à outils du côté du client serait une. Et la familiarité avec les services de savon l'autre. De nos jours, de plus en plus de services suivent le chemin du repos, et il est possible de tester de tels services à l'aide d'exemples simples. Bien que, il n'est pas si difficile de mettre en œuvre les deux méthodes et de permettre l'utilisation la plus large de la part des clients.

si vous avez besoin d'en choisir un, je vous conseille de vous reposer, 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é. SOAP était la réponse à "comment créer une plate-forme et un protocole modernes, orientés objet, indépendants du successeur de RPC?". REST a développé à partir de la question, "comment prendre les idées qui ont fait le succès de HTTP pour le web, et les utiliser pour l'informatique distribuée?"

savon est un sur vous donner des outils pour faire distribué programmation ressembler ... programmation. REST tente d'imposer un style pour simplifier 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 peuvent se référer les unes aux autres. Une façon de le faire est de tenter de restreindre les opérations à "cruder" sur les ressources (créer, lire, mettre à jour, supprimer).

le repos 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 création automatique de proxy. Cependant, ils n'ont pas été standardisés (comme je l'écris). SOAP vous donne ces choses, mais (IMHO) vous donne "seulement" ces choses, alors que le style imposé par le repos 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'il n'y ait des fonctionnalités spécifiques fournies par SOAP qu'ils doivent utiliser.

à mon avis, alors, si vous implémentez une API "greenfield", et Je ne sais pas grand chose sur les clients possibles, je choisirais REST car le style qu'il encourage tend à aider à rendre les interfaces compréhensibles, et facile à développer. Si vous en savez beaucoup sur le client et le serveur, et qu'il existe des outils SOAP spécifiques qui rendront la vie facile pour les deux, alors je ne serais pas croyant en ce qui concerne le repos, cependant.

vous pouvez facilement transformer vos composants web WSDL-spewing WCF en d'autres utilisations en changeant simplement vos paramètres de configuration. Vous pouvez aller à travers HTTP et puis aussi nommé pipes, tcp, protocoles personnalisés, etc sans avoir à changer votre code. Je crois que les composantes de la WCF peuvent aussi être plus faciles à mettre en place pour des choses comme la sécurité, les appels bidirectionnels, les transactions, la concurrence, etc.

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

je sais que cette discussion est ancienne, mais après avoir lu toutes les réponses et commenté, Je crois 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 pour non seulement vous donner les données, mais de le valider et de le garder dans la désignation de type stricte, il a été défini pour. Un WSDL vous indique ce qu'est le format de données, ce qu'est le type de données, vous permet d'ajouter des règles de style de modèle reg-ex, et définit combien de fois un morceau de données doit être, et peut-être, admis dans une requête/réponse. Le repos, en revanche, n'a aucun de ces mécanismes.

SOAP est complexe et lourd parce qu'il vous permet d'envoyer des données hiérarchiques lourdes complexes. Le reste est du texte simple, avec l'origine et le point final de tri sur les règles.

SOAP est indépendant des entreprises, parce qu'il a toutes les règles de données intégrées dans le document.

la différence entre le savon et le repos est que le savon est un autonome d'entreprise orientée schéma. Le REPOS est un document texte.