REST est-il une meilleure approche pour faire des services Web ou SOAP? Ou sont-ils différents outils pour différents problèmes? Ou s'agit-il d'une question nuancée - c'est-à-dire, est-ce que l'un est légèrement meilleur dans certains domaines que dans un autre, etc.?

J'apprécierais particulièrement les informations sur ces concepts et leur relation avec l'univers PHP ainsi que les applications web modernes haut de gamme.

J'ai construit l'un des premiers serveurs SOAP, y compris la génération de code et la génération WSDL, à partir des spécifications d'origine lors de son 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 pas de règles d'accès. Il s'agit sans doute d'un protocole. C'est la pire spécification de Don Box, et c'est tout un exploit, car c'est lui qui a perpétré "COM".

Il n'y a rien d'utile dans SOAP qui ne peut 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é des transports, vous pouvez utiliser https. Pour l'authentification, l'authentification de base. Pour les sessions, il y a des cookies. La version REST sera plus simple, plus claire, fonctionnera plus rapidement et utilisera moins de bande passante.

XML-RPC définit clairement les protocoles de demande, de réponse et d'erreur, et il existe de bonnes bibliothèques pour la plupart des langues. Cependant, XML est plus lourd que nécessaire pour de nombreuses tâches.

REST est une architecture, SOAP est un protocole.

Voilà le premier problème.

Vous pouvez envoyer des enveloppes SOAP dans une application REST.

SOAP lui-même est en fait assez basique et simple, ce sont les normes WSS- * en plus 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 déplacement de données sont essentiellement un clic de souris dans les IDE modernes.

Si vos consommateurs 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 sont pas nécessairement une architecture REST, ce sont juste des messages vers des URL. Tous parfaitement réalisables, mais il y a des composants clés à l'idiome REST. Il est cependant facile de confondre les deux. Mais ce n'est pas parce que vous parlez de requêtes HTTP que vous avez nécessairement une architecture REST. Vous pouvez avoir une application REST sans HTTP du tout (attention, c'est rare).

Donc, si vous avez des serveurs et des consommateurs qui sont "à l'aise" avec SOAP, SOAP et la pile WSS peuvent bien vous servir. Si vous faites des choses plus ponctuelles et que vous souhaitez une meilleure interface avec les navigateurs Web, un protocole plus léger sur HTTP peut également bien fonctionner.

REST 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 est un peu un changement de paradigme en se concentrant sur les "noms" et en limitant le nombre de "verbes" que vous pouvez appliquer à ces noms. Les seuls verbes autorisés sont "get", "put", "post" et "delete". Cela 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 sont mappés aux requêtes 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 est l'état sur le serveur et ce qui se trouve sur le client.

En pratique, bien que la plupart de ces problèmes disparaissent, et REST se réfère généralement à de simples requêtes HTTP qui renvoient des résultats en JSON , tandis que SOAP est une API plus complexe qui communique en transmettant XML. Les deux ont leurs avantages et leurs inconvénients, mais j'ai constaté que, selon mon expérience, REST est généralement le meilleur choix car vous avez rarement, voire jamais, besoin de toutes les fonctionnalités que vous obtenez de SOAP.

Lowdown rapide pour la question 2012:

Les domaines pour lesquels REST fonctionne très bien sont:

• Bande passante et ressources limitées. N'oubliez pas que la structure de retour est vraiment 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 GET, PUT, POST et DELETE standard. Encore une fois, n'oubliez pas que REST peut également utiliser l'objet XMLHttpRequest que la plupart des navigateurs modernes prennent en charge aujourd'hui, 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 mieux l'adapter. Cependant, si vous avez besoin d'opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) sans état, REST est le cas.

• Situations de mise en cache.  Si les informations peuvent être mises en cache en raison du fonctionnement totalement sans état de l'approche REST, c'est parfait, ce qui couvre de nombreuses solutions dans les trois ci-dessus.

Alors pourquoi envisagerais-je même du savon? Encore une fois, SOAP est assez mature et bien défini et est livré avec une spécification complète. L'approche REST est juste cela, une approche et est largement ouverte au développement, donc si vous avez ce qui suit, SOAP est une excellente solution:

• Traitement et invocation asynchrones.  Si votre application a besoin d'un niveau de fiabilité et de sécurité garanti, 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, SOAP 1.2 donne les spécifications rigides 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, SOAP 1.2 possède les spécifications supplémentaires dans la structure WS * pour prendre en charge ces éléments (sécurité, transactions, coordination, etc.). Comparativement, l'approche REST inciterait les développeurs à construire cette plomberie personnalisée.

http://www.infoq.com/articles/rest-soap-when-to-use-each

SOAP a actuellement l'avantage de meilleurs outils où ils généreront une grande partie du code passe-partout pour la couche service ainsi que pour générer des clients à partir d'un WSDL donné.

REST est plus simple, peut donc être plus facile à entretenir, se situe au cœur de l'architecture Web, permet une meilleure visibilité du protocole et a été prouvé à l'échelle à la taille du WWW lui-même. Certains frameworks vous aident à créer des services REST, comme Ruby on Rails, et certains vous aident même à écrire des clients, comme ADO.NET Data Services. Mais pour la plupart, le support d'outils fait défaut.

SOAP est utile du point de vue des outils, car le WSDL est si facilement consommé par les outils. Ainsi, vous pouvez obtenir des clients de 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 vous gardez vos demandes simples, vous pouvez effectuer des appels de service directement à partir de votre JavaScript, ce qui est très pratique. Essayez de ne pas avoir d'espaces de noms dans votre réponse XML, j'ai vu des navigateurs s'y étouffer. Donc, xsi: type ne fonctionnera probablement pas pour vous, pas de schémas XML trop complexes.

REST a également tendance à avoir de meilleures performances. Les besoins en CPU du code générant des réponses REST ont tendance à être inférieurs à ceux des frameworks SOAP. Et, si vous avez vos canards de génération XML alignés côté serveur, vous pouvez efficacement diffuser XML vers le client. Imaginez donc que vous lisez des lignes 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 services. De cette façon, vous n'avez pas à collecter toutes les lignes de la base de données en mémoire avant de commencer à écrire votre sortie XML - vous lisez et écrivez en même temps. Recherchez de nouveaux moteurs de modèles ou XSLT pour que le streaming fonctionne pour REST.

SOAP, d'autre part, a tendance à être généré par les services générés par les outils sous la forme d'un gros blob et n'est alors écrit. Ce n'est pas une vérité absolue, rappelez-vous, il existe des moyens d'obtenir des caractéristiques de streaming à partir 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 utilisé par les consommateurs, et que les messages que j'écrirai seront de taille moyenne à petite (10 Mo ou moins), et cela ne me dérange pas de graver du CPU supplémentaire cycles sur le serveur, je vais avec SOAP. Si je dois servir à AJAX sur des navigateurs Web, ou si j'ai besoin de la chose à diffuser, ou si mes réponses sont gigantesques, je vais REST.

Enfin, il existe de nombreuses normes géniales autour de SOAP, comme WS-Security et l'obtention de services Web avec état, auxquelles vous pouvez vous connecter si vous utilisez les bons outils. Ce genre de choses fait vraiment une différence et peut vous aider à satisfaire certaines exigences velues.

Je sais que c'est une vieille question mais je dois poster ma réponse - peut-être que quelqu'un la 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 réellement mis en œuvre un service REST d'une 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, cela sort aussi beaucoup plus mal. 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 tous les langages / frameworks / plateformes modernes pour lire dans un WSDL et produire des classes et des clients proxy. L'implémentation d'un service REST se fait à la main et - 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 reviendra à travers le canal car il n'y a pas de véritable schéma ou document de référence.

2) Pourquoi écrire un service REST qui retourne quand même XML? La seule différence est qu'avec REST, vous ne connaissez pas les types que chaque élément / attribut représente - vous êtes seul pour l'implémenter et espérez qu'un jour une chaîne ne se rencontrera pas dans un champ que vous pensiez être toujours un int. SOAP définit la structure des données à l'aide du WSDL, c'est donc une évidence.

3) J'ai entendu la plainte selon laquelle avec SOAP, vous avez le "surcoût" 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 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 qui vous oblige à signer des choses et à les coder 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?

Dois-je continuer?

La plupart des applications que j'écris sont C # ou Java côté serveur, ou des applications de bureau dans WinForms ou WPF. Ces applications nécessitent généralement une API de service plus riche que REST. De plus, je ne veux pas passer plus de quelques minutes à créer mon client de service Web. Les outils de génération de clients de traitement WSDL me permettent d'implémenter mon client et de passer à l'ajout de valeur commerciale.

Maintenant, si j'écrivais un service Web explicitement pour certains appels ajax javascript, ce serait probablement en REST; juste pour le plaisir de connaître la technologie client et de tirer parti de 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 existe des clients SOAP pour javascript; Je sais que jQuery en a un. Ainsi, SOAP peut être exploité à partir de javascript; tout simplement pas aussi bien qu'un service REST renvoyant des chaînes JSON. Donc, si j'avais un service Web que je voulais être suffisamment complexe pour être flexible pour un nombre arbitraire de technologies et d'utilisations client, j'irais avec SOAP.

Je vous recommande de commencer par REST - si vous utilisez Java, regardez JAX-RS et l' implémentation de Jersey . REST est beaucoup plus simple et facile à interopérer dans de nombreuses langues.

Comme d'autres l'ont dit dans ce fil, le problème avec SOAP est 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 égarez dans les mauvaises parties de WSDL, XSD, SOAP, WS-Addressing, etc.

La meilleure façon de juger le débat REST v SOAP est de regarder sur Internet - à peu près tous les grands acteurs de l'espace web, google, amazon, ebay, twitter et al - ont tendance à utiliser et à préférer les API RESTful aux API SOAP.

L'autre bonne approche pour utiliser REST est que vous pouvez réutiliser beaucoup de code et une infrastructure entre une application Web et un frontal REST. Par exemple, le rendu HTML par rapport à XML par rapport à JSON de vos ressources est normalement assez facile avec des frameworks comme JAX-RS et des vues implicites - plus sa facilité de travailler avec des ressources RESTful à l'aide d'un navigateur Web

Je suis sûr que Don Box a créé SOAP comme une plaisanterie - `` regardez, vous pouvez appeler des méthodes RPC sur le Web '' et grogne aujourd'hui quand il se rend compte de quel cauchemar gonflé de normes Web il est devenu :-)

REST est bon, simple, implémenté partout (donc plus un «standard» que les standards) rapide et facile. Utilisez REST.

Je pense que les deux ont leur propre place. À mon avis:

SOAP : Un meilleur choix pour l'intégration entre les systèmes hérités / critiques et un système web / service web, sur la couche de base, où WS- * a du sens (sécurité, politique, etc.).

RESTful : Un meilleur choix pour l'intégration entre les sites Web, avec une API publique, sur le dessus 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. Pour autant que je sache, REST 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 hors bande de type "en-tête"?)

Ne négligez pas XML-RPC. Si vous recherchez une solution légère, il y a beaucoup à dire pour un protocole qui peut être défini sur quelques pages de texte et implémenté dans un minimum de code. XML-RPC existe depuis des années mais s'est démodé pendant un certain temps - mais l'attrait minimaliste semble lui donner quelque chose d'un renouveau récemment.

Répondre à la question rafraîchie de 2012 (par la deuxième prime) et revoir les résultats d'aujourd'hui (autres réponses).

SAVON, pour et contre

À propos de SOAP 1.2, avantages et inconvénients par rapport à "REST" ... Eh bien, depuis 2007, vous pouvez décrire les services Web REST avec WSDL et utiliser le protocole SOAP ... Autrement dit, si vous travaillez un peu plus, toutes les normes W3C de la pile de protocoles des 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" avec "NON-SOAP-REST" dans des services similaires,

• SOAP-REST (= "REST-SOAP"): comme l'a montré L.Mandel , WSDL2 peut décrire un webservice REST, et, si nous supposons qu'un exemple XML peut être enveloppé dans SOAP, toute l'implémentation sera "SOAP-REST" .

• NON-SOAP-REST : tout service Web REST qui ne peut pas être SOAP ... Autrement dit, "90%" des exemples REST bien connus. Certains n'utilisent pas XML (par exemple, les REST AJAX typiques utilisent JSON à la place), certains utilisent une autre structure XML, sans en-têtes ni règles SOAP. PS: pour éviter l'informalité, on peut supposer le niveau REST 2 dans les comparaisons.

Bien sûr, pour comparer plus conceptuellement, comparez "NON-REST-SOAP" avec "NON-SOAP-REST", comme différentes approches de modélisation. Ainsi, complétant cette taxonomie des services Web:

• NON-REST-SOAP : tout service Web SOAP qui ne peut pas être REST ... Autrement dit, "90%" des exemples SOAP bien connus.

• NON-REST-NIITH-SOAP : oui, l'univers de la "modélisation des services web" comprend d'autres choses (ex. XML-RPC ).

SAVON dans les conditions REST

Comparer des choses comparables: SOAP-REST avec NON-SOAP-REST .

AVANTAGES

Expliquant certains termes,

• Stabilité contractuelle : pour tous types de contrats (comme "accords écrits"),

  • Par l' utilisation de standards : tous les niveaux de la pile W3C sont mutuellement conformes. REST, d'autre part, n'est pas une norme W3C ou ISO, et n'a pas de détails normalisés sur les périphériques du service. Donc, comme je l'ai déjà dit , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0), dans un contexte où il faut des normes, vous avez besoin de savon.

  • Par l' utilisation des meilleures pratiques : "l'aspect verbeux" des implémentations de la pile W3C , traduit les accords humains / juridiques / juridiques pertinents.

• Robustesse : la sécurité de la structure et des en-têtes SOAP. Avec la communication metada (avec toute l'expressivité de XML) et la vérification, vous avez une "police d'assurance" contre tout changement ou bruit.
  SOAP a "la fiabilité transactionnelle (...) traite des échecs de communication. SOAP a plus de contrôles autour de la logique de nouvelle tentative et peut donc fournir plus de fiabilité de bout en bout et de garanties de service", E. Terman .

Tri des pros par popularité,

• De meilleurs outils (~ 70 votes): SOAP a actuellement l'avantage 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 normes (25 votes): comme je l'ai déjà dit , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0), dans un contexte où il faut des normes, vous avez besoin de SOAP.

• Robustesse : assurance des en-têtes SOAP, @JohnSaunders (8 votes).

LES INCONVÉNIENTS

• La structure SOAP est plus complexe (plus de 300 votes): toutes les réponses ici, et les sources sur "SOAP vs REST", manifestent une certaine aversion pour la redondance et la complexité de SOAP. Ceci est une conséquence naturelle des exigences de vérification formelle (voir ci-dessous) et de robustesse (voir ci-dessus). "REST NON-SOAP" (et XML-RPC, l' initiateur SOAP ) peut être plus simple et informel.

• La restriction "seulement XML" est un obstacle aux performances lors de l'utilisation de services minuscules (~ 50 votes): voir json.org/xml et cette question , ou cette autre . Ce point est montré par @toluju (41) et d'autres.
  PS: comme JSON n'est pas une norme IETF , mais nous pouvons considérer une norme de facto pour la communauté des logiciels Web.

Services de modélisation avec SOAP

Maintenant, nous pouvons ajouter SOAP-NON-REST avec des comparaisons NON-SOAP-REST et expliquer quand il est préférable d'utiliser SOAP :

• Besoin de normes et de contrats stables (voir la section "PROS"). PS: voir un "besoin B2B standard de normes" décrit par @saille .

• Besoin d'outils (voir la section "PROS"). PS: les normes , et l'existence de vérifications formelles (voir ci-dessous), sont des enjeux importants pour l'automatisation des outils.

• Traitement lourd parallèle (voir la section "Contexte / Fondations" ci-dessous): avec des processus plus gros et / ou plus lents, peu importe avec une complexité un peu plus grande de SOAP, la fiabilité et la stabilité sont les meilleurs 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 le long d'un chemin plus compliqué que la requête / réponse ou sur un transport qui n'implique pas HTTP", S. Seely . XML est une question de base, offrant des normes pour XML Encryption , Signature XML et XML Canonicalisation , et uniquement avec SOAP , vous pouvez d'intégrer ces mécanismes dans un message par une norme bien acceptée comme WS-Security .

• Besoin de plus de flexibilité (moins de restrictions): SOAP n'a pas besoin d'une correspondance exacte avec un URI; pas nedd restreindre à HTTP; pas besoin de se limiter à 4 verbes. Comme le dit @TravisHeseman (9 votes), si vous vouliez quelque chose de "flexible pour un nombre arbitraire de technologies et d'utilisations clientes", utilisez SOAP.
  PS: rappelez-vous que XML est plus universel / expressif que JSON (et al).

• Besoin de vérifications formelles : il est important de comprendre que la pile W3C utilise des méthodes formelles et que REST est plus informel. Votre description de service WSDL (un langage formel ) est une spécification formelle de vos interfaces de services Web, et SOAP est un protocole robuste qui accepte toutes les prescriptions WSDL possibles.

LE CONTEXTE

Historique

Pour évaluer les tendances est une perspective historique nécessaire. Pour ce sujet, une perspective de 10 ou 15 ans ...

Avant la normalisation du W3C, il y a une certaine anarchie. Il était difficile de mettre en œuvre des services interopérables avec différents cadres, et plus difficile, coûteux et long à mettre en œuvre quelque chose d'interopérable entre les entreprises. Les standards de pile du W3C ont été une lumière, un nord pour l'interopérabilité d'ensembles de services Web complexes.

Pour les tâches quotidiennes, comme l'implémentation d'AJAX, SOAP est lourd ... Donc, le besoin d'approches simples doit élire un nouveau cadre théorique ... Et les grands "joueurs de logiciels Web", comme Google, Amazon, Yahoo, et al, a élu 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 (2012), cette alternative est de facto une norme pour les programmeurs.

Fondations

Dans un contexte de calcul parallèle, les services Web fournissent des sous-tâches parallèles; et les protocoles, comme SOAP, assurent une bonne synchronisation et communication. Pas «n'importe quelle tâche»: les services Web peuvent être classés comme
un parallélisme grossier et embarrassant .

A mesure que la tâche prend de l'ampleur, elle devient moins importante "débat de complexité", et devient plus pertinente la robustesse de la communication et la solidité des contrats.

C'est nuancé.

Si vous avez besoin que d'autres systèmes interfacent avec vos services, de nombreux clients seront plus satisfaits de SOAP, en raison des couches de "vérification" que vous avez avec les contrats, WSDL et la norme SOAP.

Pour les systèmes au jour le jour 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 que ce sont des outils différents pour différents problèmes .

Le protocole SOAP (Simple Object Access Protocol) standard, un langage XML définissant une architecture et des formats de message, est utilisé par les services Web et contient une description des opérations. WSDL est un langage basé sur XML pour décrire les services Web et comment y accéder. fonctionnera sur SMTP, HTTP, FTP, etc. Nécessite un support de middleware, un mécanisme bien défini pour définir des services tels que WSDL + XSD, WS-Policy SOAP renverra des données basées sur XML SOAP fournit des normes de sécurité et de fiabilité

Services Web RESTful (Representational State Transfer). ce sont des services Web de deuxième génération. Les services Web RESTful, communiquent via HTTP par rapport aux services SOAP et ne nécessitent pas de messages XML ou 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 d'évoluer. Les clients peuvent choisir de consommer certains ou tous les aspects du service et de le mélanger avec d'autres services Web.

1. REST utilise HTTP standard, il est donc plus simple de créer des clients, de développer des API
2. REST autorise de nombreux formats de données différents comme XML, texte brut, JSON, HTML alors que SOAP n'autorise que XML.
3. REST offre de meilleures performances et évolutivité.
4. Reste et peut être mis en cache et SOAP ne peut pas
5. Gestion des erreurs intégrée où SOAP n'a pas de gestion des erreurs
6. REST est particulièrement utile PDA et autres appareils mobiles.

REST est que les services sont faciles à intégrer aux sites Web existants.

SOAP possède 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. Les services Web SOAP (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 Architectural Styles and the Design of Network-based Software Architectures . Roy est également le principal auteur 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 de «l'utilisation des services Web REST», il est probablement plus précis de dire «en utilisant HTTP».

SOAP est un protocole basé sur XML qui tunnelise à l'intérieur d'une requête / réponse HTTP, donc même si vous utilisez SOAP, vous utilisez également REST. Il y a un débat sur la question de savoir si SOAP ajoute des fonctionnalités importantes au HTTP de base.

Avant de créer un service Web, je recommanderais d'étudier HTTP. Il y a de fortes chances que vos besoins puissent être mis en œuvre 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 et facile et bon pour les appels et réponses légers et idéal 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 tomber, c'est parce que ce n'est pas une norme (bien qu'il soit composé de normes). La plupart des bibliothèques de programmation ont un moyen d'inspecter un WSDL pour générer automatiquement le code client nécessaire pour consommer un service basé sur SOAP. Jusqu'à présent, la consommation de services Web basés sur REST semble une approche plus adhoc de l'écriture d'une interface pour correspondre aux appels qui sont possibles. Faire une requête 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 en fonction du contrat et toute modification de l'interface changera le wsdl. Il n'y a pas de place pour le manouvre. Vous pouvez valider toutes les demandes par rapport à ce WSDL. Cependant, comme un WSDL ne décrit pas correctement un service REST, vous n'avez aucun moyen défini de vous mettre d'accord sur l'interface de communication.

D'un point de vue commercial, cela semble laisser la communication ouverte à l'interprétation et au changement, ce qui semble être une mauvaise idée.

La première «réponse» de ce fil semble dire que SOAP signifie Simple Object-Oriented Access Protocol, mais en regardant wiki, O signifie objet non orienté objet. Ce sont des choses différentes.

Je sais que ce message est très ancien, mais j'ai pensé que je devrais répondre avec mes propres conclusions.

C'est une bonne question ... Je ne veux pas vous induire en erreur, donc je suis ouvert aux réponses des autres autant que vous. Pour moi, cela se résume vraiment au coût des frais généraux et à l'utilisation de l'API. Je préfère consommer des services Web lors de la création de logiciels clients, mais je n'aime pas le poids de SOAP. REST, je crois, est plus léger mais je n'aime pas autant travailler avec lui du point de vue du client.

Je suis curieux de savoir ce que les autres pensent.

Écoutez ce podcast pour le découvrir. 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 voulez 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 les services principaux, utilisez SOAP.

SOAP peut parfois être très difficile à mettre en place et est souvent excessif pour les simples échanges de données client et serveur Web. Malheureusement, la plupart des exemples de programmation simples que j'ai vus (et appris de) renforcent quelque peu cette perception.

Cela dit, SOAP brille vraiment lorsque vous commencez à combiner plusieurs services SOAP ensemble dans le cadre d'un processus plus large piloté par un flux de données (pensez aux logiciels d'entreprise). C'est quelque chose que de nombreux exemples de programmation SOAP ne parviennent pas à transmettre car une simple opération SOAP pour faire quelque chose, comme récupérer le prix d'un stock, est généralement trop compliquée pour ce qu'elle fait par elle-même, sauf si elle est présentée dans le contexte de la fourniture d'une machine API lisible détaillant des fonctions spécifiques avec des formats de données définis pour les entrées et les sorties qui, à leur tour, sont scriptées par un processus plus large.

C'est triste, dans un sens, car cela donne vraiment une mauvaise réputation au SOAP car il est difficile de montrer les avantages du SOAP sans le présenter dans le contexte complet de l'utilisation du produit final.

SOAP incarne une approche orientée services vers les services Web - une approche dans laquelle les méthodes (ou verbes) sont le principal moyen d'interagir avec le service. REST adopte une approche orientée vers les ressources dans laquelle l'objet (ou le nom) occupe une place centrale.

Dans le sens de "PHP-univers", le support PHP pour tout SOAP avancé est un gros problème. Vous finirez par utiliser quelque chose comme http://wso2.com/products/web-services-framework/php/ dès que vous traversez les besoins de base, même pour activer WS-Security ou WS-RM sans prise en charge intégrée.

Je pense que la création d'enveloppes SOAP est très compliquée en PHP, la façon dont elle crée les espaces de noms, xsd: nil, xsd: anytype et les services de savon de style ancien qui utilisent l'encodage SOAP (Dieu sait comment c'est différent) avec les messages SOAP.

Évitez tout ce gâchis en vous en tenant à REST, REST n'est rien de vraiment gros, nous l'utilisons depuis le début de WWW. Nous avons réalisé que lorsque ce document http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm est sorti, il montre comment pouvons-nous utiliser les capacités HTTP pour implémenter les services RESTFul. HTTP est intrinsèquement REST, cela ne signifie pas que l'utilisation de HTTP rend vos services RESTFul.

SOAP néglige les capacités de base de HTTP et considère HTTP uniquement comme un protocole de transport, donc il est indépendant du protocole de transport en théorie (en pratique, ce n'est pas le cas avez-vous entendu parler de l'en-tête SOAP Action? Sinon google maintenant!).

Avec l'adaptation JSON croissante et HTML5 avec maturation javascript, REST avec JSON est devenu le moyen le plus courant de gérer les services. Le schéma JSON a également été défini et peut être utilisé pour les solutions de niveau entreprise (toujours à un stade précoce) avec WADL si nécessaire.

Le support PHP pour REST et JSON est nettement meilleur que le support SOAP intégré existant dont il dispose.

Ajouter quelques mots BUZZ de plus ici SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

par la façon dont j'aime SOAP en particulier pour la spécification WS-Security, c'est une bonne spécification et si quelqu'un qui pense à l'adaptation Enterprise JSON doit absolument venir avec quelque chose de similaire pour JSON, comme le cryptage au niveau du champ, etc.

Un point rapide - protocole de transmission et orchestration;

J'utilise SOAP sur TCP pour des raisons de vitesse, de fiabilité et de sécurité, y compris des services orchestrés de machine à machine (ESB) et des services externes. Modifiez la définition du service, l'orchestration génère une erreur à partir du changement WSDL et son immédiatement évident et peut être reconstruit / déployé.

Pas sûr que vous puissiez faire de même avec REST - j'attends d'être corrigé ou bien sûr! Avec REST, changez la définition du service - rien ne le sait jusqu'à ce qu'il renvoie 400 (ou autre).

Si vous recherchez l'interopérabilité entre différents systèmes et langues, je choisirais certainement REST. J'ai eu beaucoup de problèmes à essayer de faire fonctionner SOAP entre .NET et Java, par exemple.

je crée une référence pour trouver lesquels sont les 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 1000000 demandes:

• REST a pris 62 secondes
• SOAP a pris 114 secondes

Une vieille question mais toujours d'actualité ... en raison du nombre important de développeurs dans l'espace entreprise qui l'utilisent encore.

Mon travail consiste à concevoir et développer des solutions IoT (Internet des objets). Ce qui inclut le développement de code pour les petits appareils intégrés qui communiquent avec le Cloud.

Il est clair que REST est désormais largement accepté et utile, et à peu près la norme de facto pour le Web, même Microsoft a la prise en charge REST incluse dans Azure. Si je devais compter sur SOAP, je ne pourrais pas faire ce que je dois faire, car c'est tout simplement trop gros, encombrant et ennuyeux pour les petits appareils intégrés.

REST est simple et propre et petit. Le rendant idéal pour les petits appareils intégrés. Je crie toujours quand je travaille avec un développeur Web qui m'envoie un WSDL. Comme je vais devoir commencer une campagne d'éducation pour savoir pourquoi cela ne va tout simplement pas fonctionner et pourquoi ils vont devoir apprendre REST.

D'après 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. Dans SOAP, vous pouvez créer votre propre service Web et y accéder via le client SOAP.

2. REST prend en charge le format texte, JSON, XML. Il est donc plus polyvalent pour communiquer entre deux applications. Alors que SOAP ne prend en charge que le format XML pour la communication des messages.