SOAP ou REST pour les services Web?

REST est-il une meilleure approche pour faire des services Web ou SOAP? Ou sont-ils des outils différents pour différents problèmes? Ou est-ce une question nuancée – c’est-à-dire est-ce que l’un est légèrement meilleur dans certaines arènes que dans une autre, etc.?

Bounty-Edit:

Maintenant, presque trois ans plus tard, je voudrais poser à nouveau cette question – offrir une prime pour encourager une réponse approfondie. 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 originale telle qu’elle était développée, lorsque je travaillais chez Hewlett-Packard. Je ne recommande pas d’utiliser SOAP pour quelque chose.

L’acronyme “SOAP” est un mensonge. Ce n’est pas simple, ce n’est pas orienté object, il ne définit pas de règles d’access. C’est sans doute un protocole. C’est la pire spécification de Don Box, et c’est tout un exploit, car c’est lui qui a commis “COM”.

Il n’y a rien d’utile dans SOAP qui ne peut ê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 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.

C’est le premier problème.

Vous pouvez envoyer des enveloppes SOAP dans une application REST.

SOAP lui-même est en fait assez simple et basique, 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 sont pas nécessairement une architecture REST, ce ne sont que des messages vers des URL. Tout fonctionne parfaitement, mais il existe des composants clés pour l’idiome REST. Il est facile de confondre les deux cependant. Mais ce n’est pas parce que vous parlez de requêtes HTTP que vous avez une architecture REST. Vous pouvez avoir une application REST sans HTTP (attention, c’est rare).

Donc, si vous avez des serveurs et des consommateurs qui sont “à l’aise” avec SOAP, la stack SOAP et WSS peut vous être utile. Si vous faites plus de choses ad hoc et souhaitez améliorer l’interface avec les navigateurs Web, un protocole HTTP plus léger peut également 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 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 peuvent être appliqués à de nombreux noms différents (c.-à-d. De nombreuses fonctions différentes).

Pour REST, les quatre verbes correspondent aux requêtes HTTP correspondantes, tandis que les noms sont identifiés par des URL. Cela rend la gestion de l’état beaucoup plus transparente que dans SOAP, où son état n’est souvent pas clair sur le serveur et sur le client.

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

Quickdown rapide pour la question de 2012:

Les domaines pour lesquels REST fonctionne vraiment bien sont:

  • Bande passante et ressources limitées. Rappelez-vous que la structure de retour est vraiment dans n’importe quel format (défini par le développeur). De plus, tout 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’object 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, REST n’est pas la meilleure approche et SOAP peut lui convenir mieux. Toutefois, si vous avez besoin d’opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) sans état, alors c’est REST.

  • Caching situations. Si les informations peuvent être mises en cache en raison du fonctionnement totalement sans état de l’approche REST, c’est parfait. Celles-ci couvrent un grand nombre de solutions dans les trois précédentes.

Alors, pourquoi envisagerais-je même SOAP? Encore une fois, SOAP est assez mature et bien défini et vient avec une spécification complète. L’approche REST est justement une approche et est largement ouverte au développement, donc si vous avez les éléments suivants, SOAP est une excellente solution:

  • Traitement asynchrone et invocation. Si votre application a besoin d’un niveau de fiabilité et de sécurité garanti, SOAP 1.2 offre des normes supplémentaires pour garantir ce type d’opération. Des choses comme WSRM – WS-Reliable Messaging.

  • Contrats formels Si les deux parties (fournisseur et consommateur) doivent s’entendre 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 nécessite des informations contextuelles et une gestion de l’état conversationnel, SOAP 1.2 possède la spécification supplémentaire dans la structure WS * pour prendre en charge ces éléments (sécurité, transactions, coordination, etc.). Comparativement, l’approche REST inciterait les développeurs à créer cette plomberie personnalisée.

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

SOAP présente actuellement l’avantage de disposer de meilleurs outils, dans lesquels il génèrera beaucoup de code passe-partout pour la couche de service, ainsi que pour générer des clients à partir de n’importe quel WSDL.

REST est plus simple, peut être plus facile à gérer en conséquence, se situe au cœur de l’architecture Web, permet une meilleure visibilité des protocoles et s’est avéré évolutif à la taille du Web 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 soutien aux outils fait défaut.

SOAP est utile du sharepoint vue de l’outillage, car le WSDL est facilement utilisé 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 joue bien avec les pages Web AJAX’y. Si vous gardez vos demandes simples, vous pouvez faire des appels de service directement depuis votre JavaScript, ce qui est très pratique. Essayez de ne pas avoir d’espaces de noms dans votre XML de réponse, j’ai vu les navigateurs s’étouffer avec ceux-ci. 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 les réponses REST ont tendance à être inférieurs à ceux des frameworks SOAP. De plus, si vos canards de génération XML sont alignés du côté serveur, vous pouvez diffuser du XML efficacement vers le client. Imaginez donc que vous lisez des lignes de curseur de firebase database. En lisant une ligne, vous la formatez en tant qu’élément XML et vous l’écrivez directement auprès du consommateur de services. De cette façon, vous n’avez pas besoin de collecter toutes les lignes de la firebase database en mémoire avant de commencer à écrire votre sortie XML – vous lisez et écrivez en même temps. Regardez les nouveaux moteurs de template ou XSLT pour que le streaming fonctionne pour REST.

SOAP, quant à lui, a tendance à être généré par les services générés par les outils en tant que gros blob, puis seulement écrit. Ce n’est pas une vérité absolue, mais il existe des moyens d’obtenir des caractéristiques de diffusion en continu à partir de SOAP, par exemple en utilisant des pièces jointes.

Mon processus de prise de décision est le suivant: si je souhaite que mon service soit facilement utilisé par les consommateurs et que les messages que je rédige soient de taille moyenne à petite (10 Mo ou moins), cela ne me dérange pas cycles sur le serveur, je vais avec SOAP. Si j’ai besoin de servir à AJAX sur des navigateurs Web, ou si j’ai besoin de la chose à diffuser, ou si mes réponses sont gigantesques, je vais sur REST.

Enfin, il existe de nombreuses normes élaborées autour de SOAP, telles que WS-Security et l’obtention de services Web dynamics, auxquelles vous pouvez accéder si vous utilisez les bons outils. Ce genre de choses fait vraiment la différence et peut vous aider à satisfaire certaines exigences poilues.

Je sais que c’est une vieille question mais je dois poster ma réponse – peut-être que quelqu’un le trouvera utile. Je n’arrive pas à croire combien de personnes recommandent REST plutôt que SOAP. Je ne peux que supposer que ces personnes ne sont pas des développeurs ou n’ont jamais implémenté de 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, cela se révèle beaucoup plus compliqué. 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 / plates-formes modernes à lire dans un WSDL et des classes proxy et des clients. L’implémentation d’un service REST se fait à la main et – obtenez ceci – en lisant la documentation. De plus, lors de la mise en œuvre de ces deux services, vous devez faire des “suppositions” sur ce qui va revenir sur le canal car il n’existe pas de véritable schéma ou document de référence.

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

3) J’ai entendu dire avec SOAP que vous avez la “surcharge” de l’enveloppe SOAP. De nos jours, faut-il vraiment s’inquiéter d’une poignée d’octets?

4) J’ai entendu l’argument selon lequel avec REST, vous pouvez simplement afficher l’URL dans le navigateur et voir les données. Bien sûr, si votre service REST utilise une authentification simple ou sans authentification. Le service Netflix, par exemple, utilise OAuth, ce qui vous oblige à signer des éléments 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, est-ce que nous nous soucions vraiment de l’URL réelle?

Ai-je besoin de continuer?

La plupart des applications que j’écris sont des applications C # ou Java côté serveur ou des applications de bureau dans WinForms ou WPF. Ces applications ont tendance à nécessiter une API de service plus riche que celle fournie par 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 d’append de la valeur métier.

Maintenant, si j’écrivais un service Web explicitement pour certains appels java JavaScript, ce serait probablement dans REST; juste pour connaître la technologie client et exploiter 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; juste pas aussi bien qu’un service REST retournant des chaînes JSON. Donc, si j’avais un service Web que je voulais être suffisamment complexe 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 pour 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 de discussion, le problème avec SOAP est sa complexité lorsque les autres spécifications WS- * entrent en jeu et qu’il ya d’innombrables problèmes d’interopérabilité si vous vous trompez 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 autres – ont tendance à préférer les API RESTful à celles de SOAP.

L’autre approche intéressante à suivre avec REST est que vous pouvez réutiliser beaucoup de code et d’infrastructure entre une application Web et une interface frontale REST. Par exemple, le rendu HTML par rapport à XML par rapport à JSON de vos ressources est généralement assez facile avec des frameworks tels que JAX-RS et les vues implicites – et il est facile de travailler avec des ressources RESTful à l’aide d’un navigateur Web.

Je suis sûr que Don Box a créé SOAP comme une blague – “regardez, vous pouvez appeler les méthodes RPC sur le Web” et aujourd’hui, il comprend à quel point il est devenu un cauchemar gonflé 🙂

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 / 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 les sites Web, avec une API publique, sur le haut de la couche (VIEW, c.-à-d. Javascripts prenant les appels aux URI).

Une chose qui n’a pas été mentionnée est qu’une enveloppe SOAP peut contenir des en-têtes et des parties du corps. Cela vous permet d’utiliser toute l’expressivité de XML pour envoyer et recevoir des informations hors bande. REST, pour autant que je sache, 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 de 2012 (par la deuxième prime) et revoir les résultats du jour (autres réponses).


SOAP, avantages et inconvénients

À propos de SOAP 1.2, avantages et inconvénients lors de la comparaison avec “REST” … Eh bien, depuis 2007, vous pouvez décrire les services Web REST avec WSDL , et utiliser le protocole SOAP … Si vous travaillez un peu plus dur, tous les standards W3C de la stack de protocoles de services Web peut être REST !

C’est un bon sharepoint départ, car nous pouvons 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 montré par L.Mandel , WSDL2 peut décrire un service Web REST, et si nous supposons que le XML illustré 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 … C’est-à-dire “90%” des exemples REST bien connus. Certains n’utilisent pas XML (par exemple, les REST AJAX utilisent JSON à la place), d’autres utilisent une autre structure XML, sans les en-têtes ou règles SOAP. PS: pour éviter le caractère informel, on peut supposer que le niveau 2 de REST est utilisé dans les comparaisons.

Bien entendu, pour comparer plus conceptuellement, comparez “NON-REST-SOAP” avec “NON-SOAP-REST”, car différentes approches de modélisation. Donc, en complétant cette taxonomie de services web:

  • NON-REST-SOAP : tout service Web SOAP qui ne peut pas être REST … C’est-à-dire “90%” des exemples SOAP bien connus.

  • NON-REST-NEITHER-SOAP : oui, l’univers de la “modélisation de services web” comprend d’autres choses (ex. XML-RPC ).

SOAP dans les conditions REST

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

AVANTAGES

Expliquer certains termes,

  • Stabilité contractuelle : pour tous les types de contrats (en tant que “accords écrits”),

    • Par l’ utilisation de standards : tous les niveaux de la stack W3C sont conformes. REST, par contre, 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 , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0) a déjà dit, dans un contexte où il est nécessaire d’avoir des normes, vous avez besoin de SOAP.

    • En utilisant les meilleures pratiques : «l’aspect verbeux» des implémentations de la stack du 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 la pleine expressivité de XML) et la vérification, vous disposez d’une “police d’assurance” contre tout changement ou bruit.
    SOAP a “la fiabilité transactionnelle (…) face aux é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 des garanties de service”, E. Terman .

Tri des pros par popularité

  • De meilleurs outils (~ 70 votes): SOAP bénéficie actuellement de meilleurs outils, depuis 2007 et 2012, car il s’agit d’un standard bien défini et largement accepté. Voir @ MarkCidade (27 votes), @DaveWoldrich (20), @JoshM (13), @ TravisHeseman (9).

  • Conformité des standards (25 votes): comme je , @DaveWoldrich (20 votes), @cynicalman (5), @Exitos (0) ont déjà dit, 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, ainsi que 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’ expéditeur SOAP ) peuvent être plus simples et informels.

  • La ressortingction “uniquement XML” est un obstacle à la performance lors de l’utilisation de services minuscules (~ 50 votes): consultez 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 , nous pouvons envisager une norme de facto pour la communauté des logiciels Web.


Services de modélisation avec SOAP

Maintenant, nous pouvons append 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” 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 questions importantes pour l’automatisation des outils.

  • Traitement lourd parallèle (voir la section «Contexte / Fondations» ci-dessous): avec des processus plus grands et / ou plus lents, peu importe la complexité de SOAP, la fiabilité et la stabilité sont les meilleurs investissements.

  • Besoin de plus de sécurité : lorsque plus que HTTPS est requirejs, 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 sur un chemin plus compliqué que demande / réponse ou sur un transport qui n’implique pas HTTP”, S. Seely . XML est un problème majeur, proposant des normes pour le cryptage XML, la signature XML et la canonisation XML , et, uniquement avec SOAP, vous pouvez incorporer ces mécanismes dans un message par un standard bien accepté comme WS-Security .

  • Besoin de plus de flexibilité (moins de ressortingctions): SOAP n’a pas besoin d’une correspondance exacte avec un URI; pas restreint au HTTP; pas besoin de restreindre à 4 verbes. Comme le dit @TravisHeseman (9 votes), si vous vouliez quelque chose de “flexible pour un nombre arbitraire de technologies et d’utilisations client”, 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 stack W3C utilise des méthodes formelles et 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

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

Avant la standardisation du W3C, il existe une certaine anarchie. Était difficile de mettre en œuvre des services interopérables avec des frameworks différents, et plus difficile, coûteux et fastidieux de mettre en œuvre quelque chose d’interopérable entre les entresockets. Les normes de la stack du W3C ont été une lumière, un nord pour l’interopérabilité des ensembles de services Web complexes.

Pour les tâches quotidiennes, comme pour implémenter AJAX, SOAP est lourd … Donc, le besoin d’approches simples nécessite de choisir un nouveau framework-théorie … Et de gros “lecteurs de logiciels Web”, comme Google, Amazon, Yahoo, et al, ont choisi la meilleure solution, à savoir l’approche REST. Était dans ce contexte que le concept REST est arrivé en tant que “cadre concurrentiel”, et, aujourd’hui (2012), cette alternative est un standard de facto 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 “aucune tâche”: les services Web peuvent être classés comme
parallélisme grossier et embarrassant .

Au fur et à mesure que la tâche prend de l’ampleur, elle devient un «débat de complexité» moins important et devient plus pertinente quant à la robustesse de la communication et à la solidité des contrats.

C’est nuancé.

Si vous avez besoin d’autres systèmes d’interface avec vos services, beaucoup de clients seront plus heureux avec SOAP, en raison des couches de “vérification” que vous avez avec les contrats, WSDL et le standard SOAP.

Pour les systèmes au jour le jour faisant appel à des systèmes, je pense que SOAP représente une charge supplémentaire inutile lorsqu’un simple appel HTML fera l’affaire.

Ne négligez pas XML-RPC. Si vous êtes juste après une solution légère, il y a beaucoup à dire sur 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 est devenu démodé pendant un certain temps – mais l’attrait minimaliste semble lui donner un regain d’intérêt.

Je regarde la même chose, et je pense que ce sont des outils différents pour différents problèmes .

Le standard SOAP (Simple Object Access Protocol) standard utilisé par les services Web pour définir une architecture de messages et des formats de messages contient une description des opérations. WSDL est un langage basé sur XML pour décrire les services Web et comment y accéder. s’exécutera 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 de Representational State Transfer (RESTful). ce sont des services Web de deuxième génération. Les services Web RESTful, communiquent via HTTP par rapport aux services SOAP et n’exigent pas de messages XML ou de définitions de service WSDL. pour REST aucun middleware n’est requirejs, seul le support 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 d’utiliser les services Web RESTful tout en permettant au serveur d’évoluer et d’évoluer. Les clients peuvent choisir de consumr certains ou tous les aspects du service et les mélanger avec d’autres services Web.

  1. REST utilise un protocole HTTP standard, ce qui simplifie la création de clients et le développement d’API
  2. REST permet de nombreux formats de données différents, tels que XML, texte brut, JSON, HTML où SOAP ne permet que le XML.
  3. REST offre de meilleures performances et une meilleure é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 aucune gestion des erreurs
  6. REST est particulièrement utile pour les PDA et autres appareils mobiles.

Les services REST is 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 interopèrent 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 l’API complexe, SOAP sera plus utile.

REST est une architecture inventée par Roy Fielding et décrite dans sa thèse intitulée Architectural Styles et Design of Network-based Software Architectures . 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 les services Web REST”, il est probablement plus juste de dire “utiliser HTTP”.

SOAP est un protocole basé sur XML qui tunnels à l’intérieur d’une requête / réponse HTTP. Ainsi, 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 significatives au HTTP de base.

Avant de créer un service Web, je vous recommande d’étudier HTTP. Les cotes sont vos exigences peuvent être implémentées avec des fonctionnalités déjà définies dans la spécification, donc d’autres protocoles ne seront pas nécessaires.

Je regarde le même problème. Il me semble que REST est en fait rapide et facile, idéal pour les appels et les 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, là où REST semble tomber, c’est parce que ce n’est pas une norme (même si elle est composée 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 à l’utilisation d’un service SOAP. Ainsi, les services Web basés sur REST, qui consumnt beaucoup, semblent constituer une approche plus spécifique pour écrire une interface correspondant aux appels possibles. Faire une requête http manuelle puis parsingr la réponse. Cela en soi peut être dangereux.

L’avantage de SOAP est qu’une fois qu’un WSDL est émis, business peut structurer sa logique et définir le contrat. Toute modification apscope à l’interface modifiera le wsdl. Il n’y a pas de place pour la manœuvre. Vous pouvez valider toutes les demandes sur ce WSDL. Cependant, comme un WSDL ne décrit pas correctement un service REST, vous ne disposez d’aucun moyen défini pour accepter l’interface de communication.

D’un sharepoint 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 dans ce thread semble indiquer que SOAP est synonyme de protocole d’access orienté object simple, mais en regardant wiki, O signifie object non orienté object. Ce sont des choses différentes.

Je sais que cet article est très ancien, mais j’ai pensé que je devais répondre avec mes propres conclusions.

C’est une bonne question … Je ne veux pas vous égarer, alors je suis ouvert aux réponses des autres autant que vous. Pour moi, cela se résume au coût des frais généraux et à l’utilisation de l’API. Je préfère consumr 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 a un poids plus léger, mais je n’aime pas beaucoup travailler avec lui du sharepoint 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, son 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 devriez probablement utiliser REST. Si vous souhaitez transmettre des données structurées entre services back-end, utilisez SOAP.

SOAP peut être une véritable peine à mettre en place parfois et est souvent exagéré pour les échanges de données simples entre les clients Web et les serveurs. Malheureusement, les exemples de programmation les plus 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 vaste piloté par un workflow de données (pensez aux logiciels d’entreprise). C’est quelque chose que la plupart des 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 elle-même, à moins 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és par un processus plus important.

C’est un peu sortingste, car cela donne une mauvaise réputation à SOAP, car il est difficile de montrer les avantages de SOAP sans le présenter dans le contexte complet de l’utilisation du produit final.

SOAP incarne une approche orientée services des services Web, dans laquelle les méthodes (ou les verbes) constituent le principal mode d’interaction avec le service. REST adopte une approche axée sur les ressources dans laquelle l’object (ou le nom) occupe le devant de la scène.

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

Je trouve 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 anciens services de style SOAP Encoding (Dieu sait comment) avec les messages SOAP.

Évitez tout ce gâchis en restant fidèle à REST, REST n’a rien de vraiment important 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 utiliser les fonctionnalités HTTP pour implémenter les services RESTFul. HTTP est insortingnsèquement REST, cela ne signifie pas que l’utilisation de HTTP rend vos services RESTFul.

SOAP néglige les fonctionnalités de base de HTTP et considère HTTP uniquement comme un protocole de transport, ce qui en fait un protocole de transport indépendant en théorie (en pratique, ce n’est pas le cas si vous avez entendu parler de l’en-tête SOAP Action?

Avec l’adaptation JSON croissante et HTML5 avec javascript maturation REST avec JSON est devenu le moyen le plus courant de traiter les services. Le schéma JSON a également été défini. Il peut être utilisé pour les solutions de niveau entreprise (encore au tout début) avec WADL si nécessaire.

La prise en charge de PHP pour REST et JSON est nettement meilleure que celle du support SOAP intégré existant.

Ajout de quelques mots supplémentaires BUZZ ici SOA, WOA, ROA

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

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

en passant, j’adore 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 avoir quelque chose de similaire pour JSON, comme le cryptage au niveau du terrain, etc.

Un point rapide – protocole de transmission et orchestration;

J’utilise SOAP over TCP pour des raisons de rapidité, de fiabilité et de sécurité, y compris des services de machine à machine orchestrés (ESB) et des services externes. Modifiez la définition du service, l’orchestration génère une erreur à partir de la modification WSDL et elle est immédiatement évidente et peut être reconstruite / déployée.

Je ne suis 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 du service – rien ne le sait jusqu’à ce qu’il retourne 400 (ou peu importe).

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

Je crée une référence pour trouver lequel d’entre eux est plus rapide! 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

An old question but still relevant today….due to so many developers in the enterprise space still using it.

My work involves designing and developing IoT (Internet of Things) solutions. Which includes developing code for small embedded devices that communicate with the Cloud.

It is clear REST is now widely accepted and useful, and pretty much the defacto standard for the web, even Microsoft has REST support included throughout Azure. If I needed to rely on SOAP I could not do what I need to do, as is just too big, bulky and annoying for small embedded devices.

REST is simple and clean and small. Making it ideal for small embedded devices. I always scream when I am working with a web developer who sends me a WSDLs. As I will have to begin an education campaign about why this just isn’t going to work and why they are going to have to learn REST.

1.From my experience. I would say REST gives you option to access the URL which is already built. eg-> a word search in google. That URL could be used as webservice for REST. In SOAP, you can create your own web service and access it through SOAP client.

  1. REST supports text,JSON,XML format. Hence more versatile for communicating between two applications. While SOAP supports only XML format for message communication.