SOAP ou REST pour les services Web?
Est-ce que REST est une meilleure approche pour faire des services Web ou SOAP? Ou sont-ils des outils différents pour des problèmes différents? Ou est-ce une question nuancée - c'est-à-dire, est-ce que l'un est légèrement meilleur dans certains domaines que d'autres, etc.?
J'apprécierais particulièrement les informations sur ces concepts et leur relation avec l'univers PHP et les applications Web haut de gamme modernes.
J'ai construit l'un des premiers serveurs SOAP, y compris la génération de code et la génération WSDL, à partir de la spécification d'origine en cours de développement, lorsque je travaillais chez Hewlett-Packard. Je ne recommande PAS d'utiliser SOAP pour quoi que ce soit.
L'acronyme "SOAP" est un mensonge. Ce n'est pas simple, ce n'est pas orienté objet, il ne définit aucune règle d'accès. C'est sans doute un protocole. Ce sont les pires spécifications de Don Box, et c'est un exploit, car c'est lui qui a commis le "COM".
Il n'y a rien d'utile dans SOAP qui ne puisse pas être fait avec REST pour le transport et JSON, XML ou même du texte brut pour la représentation des données. Pour la sécurité du transport, vous pouvez utiliser https. Pour l'authentification, authentification de base. Pour les sessions, il y a des cookies. La version REST sera plus simple, plus claire, plus rapide et utilisera moins de bande passante.
XML-RPC définit clairement les protocoles de requête, de réponse et d'erreur, et il existe de bonnes bibliothèques pour la plupart des langages. Cependant, XML est plus lourd que nécessaire pour de nombreuses tâches.
REST est une architecture, SOAP est un protocole.
C'est le premier problème.
Vous pouvez envoyer SOAP enveloppes dans une application REST.
SOAP lui-même est en fait assez basique et simple, ce sont les normes WSS- * qui le rendent très complexe.
Si vos consommateurs sont d’autres applications et d’autres serveurs, le protocole SOAP est aujourd'hui largement pris en charge, et les bases du transfert de données consistent essentiellement en un clic de souris dans les IDE modernes.
Si vos clients sont plus susceptibles d’être des clients RIA ou Ajax, vous voudrez probablement quelque chose de plus simple que SOAP et plus natif pour le client (notamment JSON).
Les paquets JSON envoyés via HTTP ne constituent pas nécessairement une architecture REST, il s'agit simplement de messages destinés à des URL. Tout fonctionne parfaitement, mais il y a des composants clés dans l'idiome REST. Il est cependant facile de confondre les deux. Mais le fait que vous parliez de requêtes HTTP ne signifie pas nécessairement que vous avez une architecture REST. Vous pouvez avoir une application REST sans HTTP (attention, c'est rare).
Ainsi, si vous avez des serveurs et des consommateurs "à l'aise" avec SOAP, SOAP et WSS stack peuvent vous servir. Si vous faites des tâches plus ponctuelles et souhaitez une meilleure interface avec les navigateurs Web, un protocole plus léger sur HTTP peut également bien fonctionner.
Le repos est un paradigme fondamentalement différent de SOAP. Une bonne lecture sur REST peut être trouvée ici: Comment j'ai expliqué REST à ma femme .
Si vous n'avez pas le temps de le lire, voici la version courte: REST change un peu le paradigme en se concentrant sur les "noms" et en limitant le nombre de "verbes" que vous pouvez appliquer à ceux-ci. noms. Les seuls verbes autorisés sont "get", "put", "post" et "delete". Ceci diffère de SOAP où de nombreux verbes différents peuvent être appliqués à de nombreux noms différents (c'est-à-dire de nombreuses fonctions différentes).
Pour REST, les quatre verbes correspondent aux demandes HTTP correspondantes, tandis que les noms sont identifiés par des URL. Cela rend la gestion des états beaucoup plus transparente que dans SOAP, où il est souvent difficile de savoir quel état est sur le serveur et ce qui est sur le client.
En pratique, bien que la plupart de ces problèmes disparaissent et que REST ne désigne généralement que de simples requêtes HTTP renvoyant les résultats en JSON , tandis que SOAP est un plus API complexe qui communique en passant XML. Les deux ont leurs avantages et leurs inconvénients, mais selon mon expérience, REST est généralement le meilleur choix car vous avez rarement, voire jamais, besoin de toutes les fonctionnalités complètes de SOAP.
Coup de projecteur rapide pour la question de 2012:
Les domaines dans lesquels REST fonctionne vraiment bien sont les suivants:
Bande passante et ressources limitées. N'oubliez pas que la structure de retour est réellement dans n'importe quel format (défini par le développeur). De plus, n'importe quel navigateur peut être utilisé car l'approche REST utilise les verbes standard GET, PUT, POST et DELETE. Encore une fois, rappelez-vous que REST peut également utiliser l'objet XMLHttpRequest pris en charge par la plupart des navigateurs modernes, ce qui ajoute un bonus supplémentaire d'AJAX.
Opérations totalement sans état. Si une opération doit être poursuivie, alors REST n'est pas la meilleure approche et SOAP peut y aller mieux. Cependant, si vous avez besoin d'opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) sans état, alors REST l'est.
Mise en cache des situations. Si les informations peuvent être mises en cache en raison du fonctionnement totalement sans état de l'approche REST, c'est parfait. beaucoup de solutions dans les trois ci-dessus.
Alors pourquoi devrais-je même considérer SOAP? Encore une fois, SOAP est assez mature et bien défini et vient avec une spécification complète. L'approche REST n'est que cela, une approche et est largement ouverte au développement, donc si vous avez ce qui suit, alors SOAP est une excellente solution:
Traitement et appel asynchrones. Si votre application requiert un niveau de fiabilité et de sécurité garanti, alors SOAP 1.2 propose des normes supplémentaires pour garantir ce type De fonctionnement. Des choses comme WSRM - WS-Reliable Messaging.
Contrats formels. Si les deux parties (fournisseur et consommateur) doivent se mettre d’accord sur le format d’échange, alors SOAP 1.2 donne les spécifications strictes pour ce type d'interaction.
Opérations avec état. Si l'application a besoin d'informations contextuelles et d'une gestion de l'état conversationnel, alors SOAP 1.2 dispose de la spécification supplémentaire dans la structure WS * pour soutenir ces choses (sécurité, transactions, coordination, etc.). Comparativement, l'approche REST obligerait les développeurs à créer cette plomberie personnalisée.
SOAP présente actuellement l’avantage de disposer de meilleurs outils permettant de générer une grande partie du code standard pour la couche de service et de générer des clients à partir de tout WSDL donné.
RESTE est plus simple, peut être plus facile à gérer, se trouve au cœur de l’architecture Web, permet une meilleure visibilité du protocole et a fait ses preuves à l’échelle de la taille du WWW lui-même. Certains frameworks vous aident à créer REST services, tels que Ruby sur Rails, et certains vous aident même à écrire des clients, tels que ADO.NET Data Services. Mais dans la plupart des cas, le support des outils fait défaut.
SOAP est utile du point de vue de l'outillage car le WSDL est si facilement consommé par les outils. Vous pouvez ainsi obtenir les clients du service Web générés pour vous dans votre langue préférée.
REST fonctionne bien avec les pages Web AJAX'y. Si vos demandes sont simples, vous pouvez passer des appels de service directement à partir de votre JavaScript, ce qui s'avère très pratique. Essayez d'éviter d'avoir des espaces de noms dans votre réponse XML, j'ai vu des navigateurs s'étouffer avec ceux-ci. Donc, xsi: type ne fonctionnera probablement pas pour vous, pas de schémas XML trop complexes.
REST tend également à avoir de meilleures performances. La configuration requise par le processeur pour générer les réponses REST a tendance à être inférieure à celle présentée par les frameworks SOAP. De plus, si vos canards de génération XML sont alignés côté serveur, vous pouvez transférer efficacement du XML vers le client. Alors, imaginez que vous lisiez des rangées de curseur de base de données. Lorsque vous lisez une ligne, vous la formatez en tant qu'élément XML et vous l'écrivez directement au consommateur de service. Ainsi, vous n'avez pas besoin de collecter toutes les lignes de la base de données avant de commencer à écrire votre sortie XML - vous lisez et écrivez en même temps. Examinez les nouveaux moteurs de templates ou XSLT pour que le streaming fonctionne correctement avec REST.
SOAP, d’autre part, a tendance à être généré par des services générés par des outils sous forme de gros blob et seulement ensuite écrit. Ce n'est pas une vérité absolue, remarquez, il existe des moyens de tirer les caractéristiques de streaming de SOAP, comme en utilisant des pièces jointes.
Mon processus de prise de décision est le suivant: si je veux que mon service soit facilement configuré par les consommateurs, les messages que je rédigerai seront de taille moyenne à petite (10 Mo ou moins), et le fait de graver un peu plus de ressources processeur ne me dérange pas. cycles sur le serveur, je vais avec SOAP. Si je dois servir à AJAX sur des navigateurs Web, ou si j'ai besoin du contenu à diffuser, ou si mes réponses sont gigantesques, je passe à REST.
Enfin, il existe de nombreuses normes de qualité autour de SOAP, telles que WS-Security et les services Web avec état, auxquelles vous pouvez vous connecter si vous utilisez les bons outils. Ce genre de choses fait vraiment la différence et peut vous aider à satisfaire certaines exigences délicates.
Je sais que c'est une vieille question mais je dois poster ma réponse - peut-être que quelqu'un le trouvera utile. Je ne peux pas croire combien de personnes recommandent REST sur SOAP. Je ne peux que supposer que ces personnes ne sont pas des développeurs ou n’ont jamais implémenté un service REST de taille raisonnable. L'implémentation d'un service REST prend beaucoup plus de temps que l'implémentation d'un service SOAP. Et à la fin, il en sortait beaucoup plus. Voici les raisons pour lesquelles je choisirais SOAP 99% du temps:
1) L'implémentation d'un service REST prend infiniment plus de temps que l'implémentation d'un service SOAP. Des outils existent pour que tous les langages/frameworks/plates-formes modernes puissent lire dans un WSDL et des classes de proxy de sortie et des clients. L'implémentation d'un service REST se fait à la main. Vous obtenez ceci en lisant la documentation. En outre, lors de la mise en œuvre de ces deux services, vous devez faire des "suppositions" quant à ce qui va se produire dans l’absence de schéma ou de document de référence.
2) Pourquoi écrire un service REST qui renvoie quand même le XML? La seule différence est que, avec REST, vous ne connaissez pas les types représentés par chaque élément/attribut - vous êtes seul pour le mettre en œuvre et vous espérez qu'un jour une chaîne ne se trouvera pas dans un champ la pensée était toujours un int. SOAP définit la structure de données à l'aide du WSDL, il s'agit donc d'une évidence.
3) J'ai entendu dire que, avec SOAP, vous avez le "temps système" de l'enveloppe SOAP. De nos jours, avons-nous vraiment besoin de nous soucier d'une poignée d'octets?
4) J'ai entendu l'argument voulant qu'avec REST, vous pouvez simplement insérer l'URL dans le navigateur et voir les données. Bien sûr, si votre service REST utilise une authentification simple ou aucune authentification. Le service Netflix, par exemple, utilise OAuth, ce qui vous oblige à signer et à encoder des éléments avant même de pouvoir soumettre votre demande.
5) Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource? Si nous utilisions un outil pour implémenter le service, nous soucions-nous vraiment de l'URL réelle?
Ai-je besoin d'aller?
La plupart des applications que j'écris sont des applications C # ou Java côté serveur ou des applications de bureau sous WinForms ou WPF. Ces applications ont généralement besoin d'une API de service plus riche que celle que REST peut fournir. De plus, je ne souhaite pas consacrer plus de deux minutes à la création de mon client de service Web. Les outils de génération de client de traitement WSDL me permettent de mettre en œuvre mon client et d'ajouter de la valeur à l'entreprise.
Maintenant, si j’écrivais un service Web explicitement pour certains appels javascript ajax, ce serait probablement en REST; juste pour le plaisir de connaître la technologie client et d’utiliser JSON. À mon avis, les API de service Web utilisées à partir de javascript ne devraient probablement pas être très complexes, car ce type de complexité semble être mieux géré côté serveur.
Cela dit, il y a quelques SOAP clients pour javascript; Je sais que jQuery en a un. Ainsi, SOAP pouvez être exploité à partir de javascript; mais pas aussi bien qu'un service REST renvoyant des chaînes JSON. Donc, si j'avais un service Web que je voulais être assez complexe pour qu'il soit flexible pour un nombre arbitraire de technologies client et d'utilisations, je choisirais SOAP.
Je vous recommande de commencer par REST - si vous utilisez Java, regardez JAX-RS et son implémentation Jersey . REST est beaucoup plus simple et facile à interopérer dans de nombreuses langues.
Comme d'autres l'ont déjà dit dans ce fil de discussion, le problème de SOAP réside dans sa complexité lorsque les autres spécifications WS- * entrent en jeu et qu'il existe d'innombrables problèmes d'interopérabilité si vous vous écartez des mauvaises parties de WSDL, XSD, SOAP, WS-Addressing etc.
La meilleure façon de juger du REST v SOAP est de regarder sur Internet - à peu près tous les grands acteurs de l'espace Web, Google, Amazon, eBay, Twitter, etc. utiliser et préférer les API RESTful à celles SOAP.
L’autre approche intéressante pour utiliser REST consiste à réutiliser de nombreux codes et infrastructures entre une application Web et un frontal REST. par exemple. Le rendu de vos ressources en HTML, en XML et en JSON est généralement assez facile avec des frameworks tels que JAX-RS et des vues implicites. Il est également facile d'utiliser des ressources RESTful à l'aide d'un navigateur Web.
Je suis sûr que Don Box a créé SOAP comme une blague - 'regarde toi peux appelle les méthodes RPC sur le Web' et gémit aujourd'hui lorsqu'il réalise à quel cauchemar gonflé de standards Web il est devenu :-)
REST est bon, simple, mis en œuvre partout (donc plus "standard" que les standards) rapide et facile. Utilisez REST.
Je pense que les deux a sa propre place. À mon avis:
SOAP: meilleur choix d'intégration entre les systèmes existants/critiques et un système Web/service Web, sur la couche de base, où WS- * a un sens (sécurité, stratégie, etc.).
RESTful: Un meilleur choix pour l'intégration entre sites Web, avec une API publique, sur le TOP de la couche (VIEW, c'est-à-dire des javascripts prenant des appels vers des URI).
Une chose qui n’a pas été mentionnée est qu’une enveloppe SOAP peut contenir des en-têtes ainsi que des parties du corps. Cela vous permet d'utiliser toute l'expressivité de XML pour envoyer et recevoir des informations hors bande. REST, à ma connaissance, vous limite aux en-têtes HTTP et aux codes de résultat.
(otoh, pouvez-vous utiliser des cookies avec un service REST pour envoyer des données de type "en-tête" hors bande?)
Répondre à la question actualisée de 2012 (à la seconde prime) et examiner les résultats d'aujourd'hui (autres réponses).
SOAP, avantages et inconvénients
À propos de SOAP 1.2, avantages et inconvénients de la comparaison avec "REST" ... depuis 2007 vous pouvez décrire REST services Web avec WSDL , et en utilisant SOAP protocole ... Autrement dit, si vous travaillez un peu plus durement, tous les standards W3C de la pile de protocoles de services Web peut être REST!
C'est un bon point de départ, car on peut imaginer un scénario dans lequel toutes les discussions philosophiques et méthodologiques sont temporairement évitées. Nous pouvons comparer techniquement "SOAP-REST" à "NON-SOAP-REST" dans des services similaires,
SOAP-REST (= "REST-SOAP"): as affiché par L.Mandel , WSDL2 peut décrire un service Web REST, et si nous supposons que les exemples de XML puissent être enveloppés dans SOAP, toute l'implémentation sera "SOAP-REST".
NON-SOAP-REST: tout REST service Web ne pouvant pas être SOAP ... C'est-à-dire, "90%" du bien connu REST exemples. Certains n'utilisent pas XML (par exemple, les REST AJAX typiques utilisent JSON à la place), d'autres utilisent d'autres structures XML, sans les en-têtes ni les règles SOAP. PS: pour éviter l’informalité, on peut supposer niveau REST 2 dans les comparaisons.
Bien entendu, pour comparer de manière plus conceptuelle, comparez "NON-REST-SOAP" à "NON-SOAP-REST", en tant qu'approches de modélisation différentes. Alors, complétant cette taxonomie des services Web:
NON-REST-SOAP: tout SOAP service Web ne pouvant pas être REST ... C'est-à-dire, "90%" du bien connu SOAP exemples.
NON-REST-NIITHER SOAP: oui, l'univers de la "modélisation de services Web" comprend d'autres éléments (par exemple, XML-RPC ).
SOAP dans les conditions REST
Comparaison de choses comparables: SOAP-REST avec NON-SOAP-REST .
AVANTAGES
En expliquant certains termes,
Stabilité contractuelle : pour tous types de contrats (en tant qu '"accords écrits"),
Par utilisation des standards : tous les niveaux de la pile pile W3C sont mutuellement compatibles. REST, en revanche, n'est pas une norme W3C ou ISO et ne contient pas de détails normalisés sur les périphériques du service. Donc, comme I , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0) a déjà dit, dans un contexte où BESOIN DE NORMES, vous avez besoin de SOAP.
Par le utilisation des meilleures pratiques : "l’aspect verbeux" de la pile W3C , traduit les accords humains/juridiques/juridiques pertinents .
Robustness : la sécurité de la structure SOAP et des en-têtes. Avec metada communication (avec la pleine expressivité de XML) et vérification vous avez une "police d'assurance" contre tout changement ou bruit.
SOAP a "la fiabilité transactionnelle (...) des problèmes de communication. SOAP dispose de davantage de contrôles autour de la logique de nouvelle tentative et peut donc fournir davantage de fiabilité de bout en bout et de garantie de service", - E. Terman .
Tri des pros par popularité,
Meilleurs outils (~ 70 votes): SOAP bénéficie actuellement de meilleurs outils, depuis 2007 et toujours 2012, car il s'agit d'une norme bien définie et largement acceptée. Voir @MarkCidade (27 votes), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).
Conformité aux standards (25 votes): as I , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0) a déjà déclaré, dans un contexte où sont BESOIN DE NORMES, vous avez besoin de savon.
Robustness: assurance des en-têtes SOAP, @JohnSaunders (8 votes).
LES INCONVÉNIENTS
La structure de SOAP est plus complexe (plus de 300 votes): toutes les réponses ici et les sources concernant "SOAP vs REST" manifestent un certain degré d'aversion pour la redondance et la complexité de SOAP. Ceci est une conséquence naturelle des exigences pour vérification formelle (voir ci-dessous), et pour robustness (voir ci-dessus). "REST NON-SOAP" (et XML-RPC, le créateur de SOAP ) peut être plus simple et informel.
La restriction "only XML" est un obstacle à la performance lors de l'utilisation de services minuscules (~ 50 votes): voir json.org/xml et cette question , ou cet autre . Ce point est démontré par @toluju (41) et d'autres.
PS: as JSON n’est pas un standard IETF , mais on peut envisager un de facto standard pour la communauté des logiciels Web.
Services de modélisation avec SOAP
Maintenant, nous pouvons ajouter SOAP-NON-REST avec NON-SOAP-REST comparaisons, et expliquer quand est-ce que mieux utiliser SOAP:
Besoin de standards et contrats stables (voir la section "Avantages"). PS: voir un type "besoin B2B pour les standards" décrit par @saille .
Besoin d'outils (voir la section "Avantages"). PS: standards , et l'existence de vérifications formelles (voir ci-dessous), sont des questions importantes pour l'automatisation des outils.
Traitement parallèle important (voir la section "Contexte/Fondements" ci-dessous): avec des processus plus volumineux et/ou plus lents, peu importe la complexité un peu plus complexe de SOAP, la fiabilité et la stabilité sont les meilleures investissements.
Besoin de plus de sécurité : lorsque plus de HTTPS est requis et que vous avez vraiment besoin de fonctionnalités supplémentaires pour la protection, SOAP est un meilleur choix ( voir @ Bell , 32 votes). "Envoi du message par un chemin plus compliqué que demande/réponse ou par un transport ne faisant pas intervenir HTTP", S. Seely . XML est un problème fondamental, offrant des normes pour XML Encryption , Signature XML , et XML Canonicalization , et uniquement avec SOAP, vous pouvez incorporer ces mécanismes dans un message selon un standard bien accepté tel que WS-Security .
Besoin de plus de flexibilité (moins de restrictions): SOAP pas besoin de correspondance exacte avec un URI; not nedd restreindre à HTTP; pas besoin de limiter à 4 verbes. Comme @TravisHeseman (9 votes) dit, si vous voulez quelque chose de "flexible pour un nombre arbitraire de technologies client et d'utilisations", utilisez SOAP.
PS: rappelez-vous que XML est plus universel/expressif que JSON (et al).Besoin de vérifications formelles: important de comprendre que pile W3C utilise méthodes formelles , et REST est plus informel. Votre description de service WSDL (un langage formel ) est un spécification formelle de vos interfaces de services Web, et SOAP est un protocole robuste qui accepte tous les fichiers WSDL possibles. ordonnances.
LE CONTEXTE
Historique
Pour évaluer les tendances est nécessaire perspective historique. Pour ce sujet, une perspective de 10 ou 15 ans ...
Avant la normalisation du W3C, il y avait une anarchie. Était difficile à mettre en œuvre des services interopérables avec des cadres différents, et plus difficile, coûteux et prend beaucoup de temps pour mettre en œuvre quelque chose d'interopérable entre les entreprises. Les standards W3C ont été une lumière, un nord pour l’interopérabilité d’ensembles de services Web complexes.
Pour les tâches quotidiennes, comme mettre en œuvre AJAX, SOAP est lourd ... Donc, le besoin d'approches simples nécessite d'élire un nouveau cadre théorique ... Et de gros "acteurs du logiciel Web" , comme Google, Amazon, Yahoo, et autres, ont choisi la meilleure alternative, c’est l’approche REST. C’est dans ce contexte que le concept REST est arrivé en tant que "cadre concurrentiel" et, aujourd’hui (en 2012), cette alternative est un standard de facto pour les programmeurs.
Fondations
Dans un contexte Parallel Computing , les services Web fournissent des sous-tâches parallèles. et les protocoles, comme SOAP, garantissent une synchronisation et une communication satisfaisantes. Pas "n'importe quelle tâche": les services Web peuvent être classés comme
parallélisme à grain grossier et embarrassant .
À mesure que la tâche prend de l'ampleur, le "débat sur la complexité" devient moins important et la pertinence de la robustesse de la communication ainsi que la solidité des contrats deviennent plus pertinentes.
Ne négligez pas XML-RPC. Si vous recherchez une solution allégée, vous devez choisir un protocole qui peut être défini dans quelques pages de texte et implémenté dans un minimum de code. XML-RPC existe depuis des années mais est devenu un peu démodé pendant un certain temps - mais l’appel minimaliste semble lui donner une sorte de renaissance récente.
C'est nuancé.
Si vous avez besoin d'une interface système avec vos services, beaucoup de clients seront plus satisfaits de SOAP, en raison des couches de "vérification" que vous avez avec les contrats, WSDL et le standard SOAP.
Pour les systèmes quotidiens appelant des systèmes, je pense que SOAP représente beaucoup de surcharge inutile lorsqu'un simple appel HTML suffit.
Je regarde la même chose, et je pense, ce sont des outils différents pour des problèmes différents.
Le standard SOAP (Simple Object Access Protocol), un langage XML définissant une architecture et des formats de message, est utilisé par les services Web; il contient une description des opérations. WSDL est un langage basé sur XML permettant de décrire les services Web et d’y accéder. fonctionnera sur SMTP, HTTP, FTP, etc. Requiert la prise en charge de middleware, un mécanisme bien défini pour définir des services tels que WSDL + XSD, WS-Policy SOAP renverra des données XML SOAP fournissant des normes de sécurité et de fiabilité.
Services Web de représentation d'état (RESTful). ce sont des services Web de deuxième génération. Les services Web RESTful communiquent via HTTP par rapport aux services basés sur SOAP et ne nécessitent pas de messages XML ni de définitions d'API de service WSDL. pour REST, aucun middleware n'est requis, seule la prise en charge HTTP est nécessaire.WADL Standard, REST peut renvoyer XML, texte brut, JSON, HTML, etc.
Il est plus facile pour de nombreux types de clients de consommer des services Web RESTful tout en permettant au côté serveur d'évoluer et de s'adapter. Les clients peuvent choisir de consommer tout ou partie du service et de le mélanger à d’autres services Web.
- REST utilise HTTP standard, il est donc simple de créer des clients et de développer des API.
- REST autorise de nombreux formats de données différents tels que XML, texte brut, JSON, HTML, où SOAP n'autorise que XML.
- REST offre de meilleures performances et une meilleure évolutivité.
- Reste et peut être mis en cache et SOAP ne peut pas
- Traitement des erreurs intégré où SOAP n'a pas de traitement des erreurs
- REST est particulièrement utile PDA et les autres appareils mobiles.
Les services REST sont faciles à intégrer aux sites Web existants.
SOAP dispose d'un ensemble de protocoles, qui fournissent des normes de sécurité et de fiabilité, entre autres, et interagissent avec d'autres clients et serveurs conformes à WS. SOAP Les services Web (tels que JAX-WS) sont utiles pour gérer le traitement et l'appel asynchrones.
Pour les API complexes SOAP sera plus utile.
REST est une architecture inventée par Roy Fielding et décrite dans sa thèse Styles architecturaux et conception d'architectures logicielles en résea . Roy est également l'auteur principal de HTTP - le protocole qui définit le transfert de documents sur le World Wide Web. HTTP est un protocole RESTful. Lorsque les développeurs parlent "d'utiliser REST Web services" ", il est probablement plus exact de dire" utiliser HTTP ".
SOAP est un protocole XML qui tunnelise à l'intérieur d'une requête/réponse HTTP. Ainsi, même si vous utilisez SOAP, vous utilisez également REST. Il existe un débat sur le point de savoir si SOAP ajoute des fonctionnalités importantes au protocole HTTP de base.
Avant de créer un service Web, je recommanderais d’étudier HTTP. Les chances sont que vos exigences peuvent être implémentées avec des fonctionnalités déjà définies dans la spécification, de sorte que d'autres protocoles ne seront pas nécessaires.
Je regarde le même problème. Il me semble qu’en réalité, REST est rapide, simple et utile pour les appels et les réponses légers, mais également pour le débogage (quoi de mieux que de pomper une URL dans un navigateur et de voir la réponse).
Cependant, où REST semble s'effondrer, c'est que ce n'est pas une norme (bien qu'elle soit composée de normes). La plupart des bibliothèques de programmation disposent d'un moyen d'inspecter un WSDL pour générer automatiquement le code client nécessaire à la consommation de services basés sur SOAP. Les services Web basés sur REST et consommant jusqu'ici semblent constituer une approche plus ponctuelle consistant à écrire une interface pour correspondre aux appels possibles. Faire une demande http manuelle puis analyser la réponse. Cela en soi peut être dangereux.
La beauté de SOAP est qu’une fois qu'un WSDL est émis, les entreprises peuvent structurer leur logique de manière à définir un contrat, toute modification apportée à l'interface modifiant le wsdl. Il n'y a pas de place pour manouvre. Vous pouvez valider toutes les demandes par rapport à ce WSDL. Toutefois, comme un WSDL ne décrit pas correctement un service REST, vous ne pouvez définir aucun moyen de s’accorder sur l’interface de communication.
Du point de vue des entreprises, cela semble laisser la communication ouverte à l'interprétation et au changement, ce qui semble être une mauvaise idée.
En haut de la page, la réponse semble indiquer que SOAP correspond à un protocole d'accès simple orienté objet. Ce sont des choses différentes.
Je sais que ce message est très ancien, mais je pensais devoir répondre avec mes propres conclusions.
C'est une bonne question ... Je ne veux pas vous égarer, alors je suis aussi ouvert que vous aux réponses des autres. Pour moi, cela revient vraiment au coût des frais généraux et à l'utilisation de l'API. Je préfère utiliser des services Web lors de la création d'un logiciel client, mais je n'aime pas le poids de SOAP. Je pense que REST est plus léger, mais je n’apprécie pas autant de travailler avec cela du point de vue du client.
Je suis curieux de savoir ce que les autres pensent.
Écoutez ce podcast pour le savoir. Si vous voulez connaître la réponse sans écouter, alors OK, c'est REST. Mais je recommande vraiment d'écouter.
Ma règle générale est que si vous souhaitez qu'un client Web de navigateur se connecte directement à un service, vous devez probablement utiliser REST. Si vous souhaitez transmettre des données structurées entre des services principaux, utilisez SOAP.
L'installation de SOAP peut parfois s'avérer une tâche ardue et est souvent excessive pour de simples échanges de données client/serveur Web. Malheureusement, la plupart des exemples de programmation simples que j'ai vus (et dont j'ai appris) renforcent quelque peu cette perception.
Cela dit, SOAP brille vraiment lorsque vous commencez à combiner plusieurs services SOAP dans le cadre d'un processus plus vaste piloté par un flux de travail de données (logiciel d'entreprise). Ceci est quelque chose que la plupart des SOAP exemples de programmation ne parviennent pas à expliquer, car une simple opération SOAP, telle que récupérer le prix d'un stock, est généralement trop compliquée pour son travail. elle-même, sauf si elle est présentée dans le contexte de la fourniture d'une API lisible par machine détaillant des fonctions spécifiques avec des formats de données définis pour les entrées et les sorties, elle-même scriptée par un processus plus important.
C’est triste, dans un sens, car cela donne vraiment une mauvaise réputation à SOAPcar il est difficile de montrer les avantages de SOAP sans le présenter dans le contexte complet du produit final. est utilisé.
SOAP incarne une approche des services Web axée sur les services - une approche dans laquelle les méthodes (ou verbes) constituent le mode principal d'interaction avec le service. RESTE adopte une approche orientée ressources dans laquelle l’objet (ou le nom) occupe une place centrale.
Un point rapide - protocole de transmission et orchestration;
J'utilise SOAP sur TCP pour des raisons de rapidité, de fiabilité et de sécurité, notamment pour des services machine à machine orchestrés (ESB) et des services externes. Si vous modifiez la définition du service, l'orchestration soulève une erreur liée à la modification WSDL et est immédiatement évidente et peut être reconstruite/déployée.
Pas sûr que vous puissiez faire la même chose avec REST - j'attends d'être corrigé ou bien sûr! Avec REST, changez la définition de service - rien n’est connu jusqu’à ce qu’elle renvoie 400 (ou quoi que ce soit).
Si vous recherchez une interopérabilité entre différents systèmes et langages, je choisirais sans aucun doute REST. J'ai eu beaucoup de problèmes à essayer de faire fonctionner SOAP entre .NET et Java, par exemple.
je crée un repère pour trouver lesquels d'entre eux sont plus rapides! Je vois ce résultat:
pour 1000 demandes:
- REST a pris 3 secondes
- SOAP a pris 7 secondes
pour 10 000 demandes:
- REST a pris 33 secondes
- SOAP a pris 69 secondes
pour 1 000 000 de demandes:
- REST a pris 62 secondes
- SOAP a pris 114 secondes
Une question ancienne mais toujours d'actualité… en raison du grand nombre de développeurs de l'entreprise qui l'utilisent encore.
Mon travail consiste à concevoir et développer des solutions IoT (Internet of Things). Ce qui inclut le développement de code pour les petits périphériques intégrés qui communiquent avec le Cloud.
Il est clair que REST est maintenant largement accepté et utile, et quasiment le standard de facto pour le Web, même Microsoft prend en charge REST _ dans tout Azure. Si j’avais besoin de compter sur SOAP, je ne pourrais pas faire ce que je devais faire, c’est trop volumineux, encombrant et gênant pour les petits appareils intégrés.
Le reste est simple et propre et petit. Le rendant idéal pour les petits appareils intégrés. Je crie toujours lorsque je travaille avec un développeur Web qui m'envoie un WSDL. Comme je devrai commencer une campagne d’éducation sur les raisons pour lesquelles cela ne fonctionnera tout simplement pas et pourquoi ils vont devoir apprendre à se reposer.
1. de mon expérience. Je dirais que REST vous donne la possibilité d'accéder à l'URL qui est déjà construite. par exemple, une recherche de mots dans google. Cette URL pourrait être utilisée comme service Web pour REST. Sous SOAP, vous pouvez créer votre propre service Web et y accéder via le client SOAP.
- REST prend en charge le format texte, JSON et XML. D’où une plus grande polyvalence pour la communication entre deux applications. Bien que SOAP ne prenne en charge que le format XML pour la communication de messages.