Quelle est la signification actuelle de SOAP

51

La dernière fois que j’ai rencontré un service SOAP, c’était lors de mon stage dans une entreprise financière en 2013. C’est à ce moment-là que j’ai commencé ma carrière dans l’informatique. Je me souviens d'avoir eu du matériel d'étude sur SOAP dans l'un de mes cours d'ingénierie. En dehors de cela, je n'ai pas beaucoup utilisé SOAP au cours de ma carrière.

Je pose la question depuis que la question de "Différence entre SOAP et REST" a été abordée dans l’une de mes interviews récentes. D'après ce que je sais (et ce que j'ai trouvé sur Google), SOAP est un protocole avec un couplage étroit entre client et serveur pour l'échange d'informations étroitement lié à la logique métier. Tandis que REST est une architecture sans état plus flexible pour le transfert de données.

Quelqu'un peut-il me corriger si je me trompe à propos de cette différence entre SOAP et REST? En outre, quelle est la signification actuelle de SOAP? Est-ce que les gens développent encore de nouvelles API basées sur SOAP, ou s'agit-il principalement d'un héritage?

Abhas Tandon
la source
2
voir aussi: l' avenir de SOAP, REST
moucheron
14
@gnat: Pour ce que ça vaut, les réponses à ces deux questions sont toutes terribles.
Robert Harvey
7
Avez-vous déjà vu un service REST? Tout ce que je vois, ce sont des "services Web qui ont finalement appris ce que signifient les verbes HTTP". Pourquoi appelons-nous soudainement HTTP REST?
Luaan
8
@ Luan: Il n'y a rien de soudain à ce sujet; les gens abusent du terme "repos" depuis des années.
Courses de légèreté avec Monica

Réponses:

59

REST est en effet un style architectural. SOAP est un protocole de données. La distinction est importante. vous ne pouvez pas les comparer directement.

L'objectif principal de REST est de représenter des ressources sur Internet et de fournir des mécanismes pour les découvrir. En revanche, SOAP est utilisé pour la communication de données structurées entre ordinateurs, et c'est tout ce qu'il fait.

Notez que vous n'avez pas réellement besoin de REST pour créer une relation client / serveur entre deux ordinateurs sur Internet. Tout ce dont vous avez besoin est un mécanisme qui transfère JSON ou XML, et vous n'en avez même pas besoin si vous êtes prêt à être incompatible avec les autres.

Néanmoins, SOAP n'est plus en faveur des nouvelles API destinées au public, bien qu'il soit encore couramment utilisé pour les applications B2B, car vous pouvez définir un "contrat de données" avec celle-ci. Les services Web JSON ont l'avantage d'être assez légers et flexibles, et comme Javascript reconnaît JSON de manière native, c'est un choix naturel pour les navigateurs.

Mais rien de tout cela n'a vraiment à voir avec REST.

Lectures supplémentaires
REST est-il meilleur que SOAP? (bon article, même s'il appelle incorrectement un protocole REST).
Le modèle de maturité de Richardson

Robert Harvey
la source
3
Je dirais que la principale caractéristique des services Web JSON réside dans le fait que les navigateurs prennent mal en charge XML et SOAP, alors qu'ils prennent en charge (presque) nativement JSON. SOAP a beaucoup à offrir, mais si vous ne pouvez pas faire de requêtes AJAX contre un service SOAP, c'est mort. Javascript / JSON est devenu le plus petit dénominateur commun de l'Internet, de sorte que vous auriez besoin d' un énorme avantage de ne pas l' utiliser, et SOAP n'est pas que beaucoup mieux.
Luaan
3
@Luaan Je ne dirais pas que les navigateurs supportent mal XML. En fait, il est difficile de faire mieux que de faire une requête XML HttpRequest et d'accéder à un attribut doté d'un DOM analysé. C'est simplement que si l'on veut une structure de données typique et non un document, JSON est tout simplement plus approprié, que l'on soit dans le navigateur ou dans tout autre environnement.
André Paramés
4
Tout ce dont vous avez besoin est un mécanisme qui transfère JSON ou XML, et vous n'en avez même pas besoin si vous êtes prêt à être incompatible avec les autres. -1: Si vous souhaitez connecter un client et un serveur, vous avez simplement besoin d'un protocole arbitraire que les deux parties comprennent, il n'a rien à voir avec l'utilisation de xml, JSON ou d'être compatible avec tout le monde. Même en utilisant json ou xml ne garantit pas que votre compatible avec tout le monde ou même quelqu'un. Json et XML ne sont que des formats de données, rien de plus.
Paul Wasilewski
6
@PaulWasilewski: Oui, c'est ce que j'ai dit. Ne vous attardez pas sur les mots. Il y a une raison pour laquelle tout le monde utilise JSON; c'est une norme. Son utilisation garantit que vous utilisez quelque chose qui est reconnaissable par d’autres.
Robert Harvey
3
@ RobertHarvey, non, ce n'est pas ce que vous avez écrit, c'est peut-être ce que vous vouliez dire. JSON est standard alors quoi? CSV, Protcol Buffers, BSON est normalisé ainsi que de nombreux autres. Donc, la raison pour laquelle tout le monde utilise JSON est multiple. Et il y en a même qui utilisent JSON parce que tout le monde utilise JSON;)
Paul Wasilewski
29

REST est beaucoup plus limité que SOAP, qui est sa force et la raison de sa popularité.

Dans SOAP, l'ensemble des opérations autorisées et l'ensemble des types de données autorisés sont essentiellement illimités. SOAP est un protocole de procédure à distance, que vous utilisez pour exposer les API locales sur le réseau sans perdre de fidélité. Cela a rendu SOAP populaire dans les environnements d'entreprise où des systèmes transactionnels complexes devaient interagir sur le réseau sans perdre de fidélité en cours de route. Cette richesse en capacités est également la perte de SOAP, car elle rend les API SOAP si difficiles à comprendre et à utiliser qu’elle nécessitait l’utilisation d’outils automatisés sous la forme de bibliothèques client WSDL et SOAP pour comprendre les choses. Plus précisément, exposer toute la richesse du système sous-jacent est peu attrayant dans les API destinées au public, où vous souhaitez fournir des abstractions qui vous permettent de faire évoluer le système sous-jacent sans avoir à casser ou à modifier votre API.

REST + JSON a gagné en popularité en raison de sa simplicité. Il définit un ensemble limité d'opérations avec un ensemble limité de types de données, ce qui oblige le concepteur d'API à concevoir avec soin des abstractions qui s'intègrent à l'intérieur de ce vocabulaire limité et à réfléchir au mappage du domaine métier aux ressources REST. Une API REST est facile à comprendre et à utiliser sans aucun outil spécial. Pour une API grand public où les utilisateurs de votre API peuvent avoir tous les niveaux de compétences et de connaissances, c'est exactement ce que vous voulez. C'est pourquoi toutes les API que vous voyez sur le Web sont en train de passer à REST. SOAP est relégué aux situations d'entreprise où il existe toujours une volonté et un besoin de partager des API complexes entre des systèmes. cependant,

Les utilisateurs ont essentiellement compris que l'ensemble des contraintes que vous devez appliquer à la conception de votre API pour rendre l'API assez simple et abstraite pour qu'il soit maintenable et facile à utiliser correspond exactement à l'ensemble de contraintes introduit par REST, qui neutralise efficacement les SOAP. avantages vous laissant avec seulement ses inconvénients. Vous pouvez créer une API simplifiée avec SOAP, mais elle ne sera jamais aussi facile à utiliser que REST. En pratique, tout le monde choisit donc REST.

Joeri Sebrechts
la source
4
Le bon vieux débat sur la dactylographie statique contre la dactylographie dynamique, yay: D Propre et dur contre hacky et simple, la guerre qui ne finit jamais.
Luaan
@Luaan ... and dynamic gagne toujours pour l'échange de données. youtube.com/watch?v=ROor6_NGIWU
Jared Smith
6
@ JaredSmith Je ne suis pas du tout d'accord. Les contrats sont censés être suivis pour que les deux points finaux mappent les données correctement. Si vous pouvez le faire par la publication de métadonnées au lieu de pages de documentation sujettes aux erreurs, pourquoi pas vous?
drake7707
1
REST pratique est un protocole; La thèse et la religion sont du «style architectural». Cette réponse compare correctement le repos pratique au savon pratique.
bmargulies
1
Votre réponse a déjà montré que vous ne comprenez pas REST et votre commentaire le souligne.
Paul Wasilewski
5

Vous ne pouvez pas comparer REST et SOAP. REST est un style architectural alors que SOAP est un protocole.

Malheureusement, REST est devenu un synonyme de service HTTP RESTful, ce qui signifie une réalisation de l'architecture de style REST avec HTTP comme protocole (d'application).

REST est basé sur les principes suivants (contraintes et éléments) (entre parenthèses la réalisation en HTTP RESTful) [1] .

  • Sans état (HTTP est un protocole sans état)
  • Ressource (identifiée par les URI)
  • Interface uniforme (méthodes HTTP)
  • Représentation (TYPE MIME)
  • HATEOS (hyperliens)
  • Cache (cache HTTP)

De l'autre côté, beaucoup de gens entendent dire par SOAP qu'un service Web basé sur WSDL et SOAP faisant partie de l'architecture de service Web du W3C [2] .

  • SOAP est utilisé comme protocole pour échanger des informations (essentiellement le nom de la méthode, les paramètres, les valeurs de retour, les types de données, ...).
  • WSDL est un langage de définition d'interface permettant de décrire le service Web.

Quelle est la signification actuelle de SOAP *?

SOAP est une norme du W3C utilisée comme format d'échange d'informations dans les services Web du W3C. Ces services Web étaient - en particulier lors du battage publicitaire des SOA (archtitectures orientées services) autour de 2008 (+ - 3 ans) - et (malheureusement) sont toujours principalement implémentés dans des applications d'entreprise.

Cela a plusieurs raisons. À l'époque, RESTful HTTP n'était pas bien connu et avait été mal compris. Malheureusement, il est encore incompris de regarder les autres réponses

"[...] REST est beaucoup plus limité que SOAP [...]."

„L'objectif principal de REST est de représenter des ressources sur Internet [...].“

En outre, SOAP (et WSDL) font partie de la pile de protocoles de service Web du W3C, qui fournit encore plus de normes pour la mise en œuvre d'un service Web.

Est-ce que les gens développent encore de nouvelles API basées sur SOAP, ou s'agit-il principalement d'un héritage?

Donc oui, il y a toujours et il y aura aussi à l'avenir des systèmes qui utilisent SOAP (du moins dans les systèmes d'entreprise, la plupart du temps derrière les portes). Mais la majorité essaie de faire une sorte de "REPOS" de nos jours.

Quelqu'un peut-il me corriger si je me trompe à propos de cette différence entre SOAP et REST?

Dire que REST est une architecture sans état plus flexible pour le transfert de données n'est pas une bonne explication. REST est un style d'architecture avec des contraintes et des éléments spécifiques. Considérant que SOAP est un protocole d’échange d’informations.

Comme je l'ai déjà écrit, vous ne pouvez pas les comparer. Mais vous pouvez comparer un service Web HTTP RESTful avec un service Web SOAP / WSDL.

Paul Wasilewski
la source
"Mais vous pouvez comparer un service Web HTTP RESTful à un service Web SOAP / WSDL." Mais c'est ce que demande le PO. Quelqu'un a-t-il déjà répondu à cette question?
RoboJ1M