Pourquoi les gens pensent que SOAP est obsolète? [fermé]

20

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement de réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 6 ans .

En parcourant SO aujourd'hui, j'ai trouvé cette question ici et elle commence par ceci:

Bien sûr, tu vas me dire que le savon est obsolète et tout, eh bien je suis obligé de l'utiliser

J'ai trouvé beaucoup de déclarations comme celle-ci sur SO jusqu'à présent, celle-ci m'a juste incité à poser cette question.

REST a ses utilisations, SOAP a ses utilisations, à certains endroits, elles se recoupent en tant que fonctionnalités mais elles ne sont pas remplaçables les unes aux autres.

Je me demande donc pourquoi les gens pensent que le savon est «obsolète»? Est-ce de l'ignorance? Complexité des spécifications SOAP et WS- *? Battage médiatique REST? Quelle?

Si vous pensez que SOAP est obsolète, dites-moi pourquoi. Je suis curieux!

web-services soa soap

— user98q37479
source

31

Le savon est déconseillé parce que beaucoup d'entre nous sont passés au gel douche. ;)

— FrustratedWithFormsDesigner

4

Voir SOAP et Evolution du langage .

— Josh K

1

Je pense que le marteau-> clou est la complexité du SOAP et en particulier des spécifications WS- *. Ces choses se sont développées bien au-delà de la capacité de compréhension moyenne de l'industrie avant que quiconque ne s'en aperçoive vraiment, et tout à coup, on s'attend à ce que les gens entrent dans l'industrie et les ramassent, ils ont probablement échoué et fait de grosses erreurs à cause de cela à plusieurs reprises, ce qui les a amenés à dire "Huh, que dirais-tu d'utiliser JSON et d'oublier tout ça ..."

— Jimmy Hoffa

18

Dans le cas des services Web basés sur SOAP, WSDL et UDDI étaient censés être la solution miracle. Les outils étaient censés créer des WSDL presque automatiquement, UDDI était censé détecter automatiquement les services et connecter les clients. Aucun des deux n'a vraiment décollé. Sans ces outils, SOAP est tout simplement trop compliqué par rapport à RESTful.

De plus, à peu près au même moment, le battage médiatique XML a disparu, remplacé par un battage médiatique en langage léger. SOAP est XML, et les frais généraux sur les messages simples sont énormes.

— vartec
source

6

Je pense que son ignorance et son battage médiatique, à l'époque et maintenant.

Pour qualifier ceci:

Beaucoup de projets qui auraient utilisé SOAP / WS- * il y a quelques années, ne le seront pas aujourd'hui et pour de bonnes raisons.
Les interfaces RESTful résolvent de nombreux cas d'utilisation qui sont particulièrement répandus dans les applications Internet.
Il y a une dizaine d'années, les applications "entreprise" ont tenté de sauter dans le train des services Web et se sont ensuite souvenues qu'elles avaient en fait besoin de nombreuses fonctionnalités dont elles essayaient d'échapper dans leurs anciennes plates-formes COM +, CORBA et J2EE RMI / IIOP. Tout le monde déteste encore ce genre de choses.

— Jeremy
source

6

SOAP a promis des fonctionnalités glorieuses, vitales, de détection automatique, de résolution de problèmes et de ne plus jamais travailler. Cependant, nous ne sommes jamais vraiment allés aussi loin. Puis vint le JSON et d'autres alternatives légères , simples et multi-plateformes qui laissèrent SOAP comme un choix stupide.

Cela aurait pu être une grande ville si tout le monde y avait emménagé.

— Xeoncross
source

4

Je pense que c'est parce que SOAP spec 1.2 réfère à elle-même comme WS- * et non plus SOAP. Il fait une distinction entre lui-même (en tant que système basé sur XML hautement formaté) et SOAP (qui, selon lui, est un morceau de XML qui se trouve être un peu standardisé et plein de `` problèmes '').

alors même s'ils l'ont normalisé sur quelques années, c'est toujours SOAP, mais je pense qu'ils ont abandonné le terme comme acronyme principal.

— gbjbaanb
source