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.