Quelle est la signification actuelle de SOAP
La dernière fois que j'ai rencontré un service basé sur SOAP, c'était pendant mon stage dans une entreprise financière en 2013. C'est à ce moment-là que j'ai commencé ma carrière en informatique. Je me souviens 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 cette question car la question de "Différence entre SOAP et REST" est venue dans l'une de mes récentes interviews. D'après ce que je sais (et ce que j'ai trouvé sur Google) SOAP est un protocole à couplage étroit entre client et serveur pour l'échange d'informations qui est étroitement lié à la logique métier. Alors 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 sur cette différence entre SOAP et REST? De plus, quelle est la signification actuelle de SOAP? Les gens développent-ils encore de nouvelles API basées sur SOAP, ou c'est principalement un héritage maintenant?
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.
Le principal objectif de REST est de représenter ressources sur Internet, et de fournir des mécanismes pour les découvrir. En revanche, SOAP est utilisé pour communiquer des données structurées entre ordinateurs, et c'est tout ce qu'il fait vraiment.
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'avez même pas besoin de cela si vous êtes prêt à être incompatible avec tout le monde.
Néanmoins, SOAP est tombé en disgrâce pour les nouvelles API accessibles au public, bien qu'il soit encore couramment utilisé pour les applications B2B car vous pouvez définir un "contrat de données" avec lui. Les services Web JSON ont la vertu d'être plutôt léger et flexible, et puisque Javascript reconnaît nativement JSON, c'est un choix naturel pour les navigateurs.
Mais rien de tout cela n'a beaucoup à voir avec REST, vraiment.
Lectures complémentaires
Est REST meilleur que SOAP? (bon article, même s'il appelle incorrectement REST un protocole).
Le modèle de maturité Richardson
REST est beaucoup plus limité que SOAP, ce 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 la fidélité. Cela a fait SOAP populaire dans les environnements d'entreprise où les transactions complexes Cette richesse de capacités est également la chute de SOAP, car elle rend les API SOAP si difficiles à comprendre et à utiliser qu'elles nécessitaient un outillage automatisé dans la forme de WSDL et SOAP bibliothèques clientes pour donner un sens aux choses. Plus encore, exposer toute la richesse du système sous-jacent n'est pas attrayant dans les API publiques, où vous souhaitez fournir des abstractions qui permettent vous faites évoluer le système sous-jacent sans avoir à casser ou à versionner votre API.
REST + JSON a gagné en popularité en particulier en raison de sa simplicité. Il définit un ensemble limité d'opérations avec un ensemble limité de types de données, obligeant le concepteur d'API à concevoir soigneusement des abstractions qui s'inscrivent dans ce vocabulaire limité et à vraiment réfléchir à la mise en correspondance du domaine métier avec les ressources REST . Une API REST est facile à comprendre et à utiliser sans aucun outil spécial. Pour une API accessible au public où vos utilisateurs d'API peuvent avoir tous les niveaux de compétence et de connaissances, c'est exactement ce que vous voulez , c'est pourquoi toutes les API que vous voyez sur le Web sont passées à REST. SOAP est relégué aux situations d'entreprise où il y a toujours un désir et un besoin de partager des API complexes entre les systèmes. Cependant , avec des tendances architecturales vers des micro-services à version indépendante développés par des équipes distinctes, même ce domaine perd du terrain.
Essentiellement, ce que les gens ont réalisé, c'est que l'ensemble de contraintes que vous devez appliquer à la conception de votre API pour rendre l'API suffisamment simple et abstraite pour qu'elle soit maintenable et facile à utiliser est exactement l'ensemble de contraintes qui REST introduit, qui neutralise efficacement les avantages de SOAP, ne vous laissant que ses inconvénients. Vous pouvez créer une API simplifiée avec SOAP, mais il ne serait jamais aussi facile à utiliser que REST, donc en pratique tout le monde choisit simplement REST.
Vous ne pouvez pas comparer REST et SOAP. REST est un style architectural alors que SOAP est un protocole).
Malheureusement, REST est devenu un langage familier 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 dans RESTful HTTP) [1] .
- Sans état (HTTP est un protocole sans état)
- Ressource (identifiée par les URI)
- Interface uniforme (méthodes HTTP)
- Représentation (MIME-TYPE)
- HATEOS (Hyperliens)
- Cache (cache HTTP)
De l'autre côté, beaucoup de gens entendent par dire SOAP un service Web basé sur WSDL et SOAP qui font partie de l'architecture du service Web W3C [ 2] .
- SOAP est utilisé comme protocole pour échanger des informations (essentiellement nom de méthode, paramètres, valeurs de retour, types de données, ...).
- WSDL un langage de définition d'interface pour décrire le service Web.
Quelle est l'importance actuelle de SOAP *?
SOAP est une norme W3C et il est utilisé comme format d'échange d'informations dans les services Web W3C. Ces services Web ont été - en particulier pendant le battage médiatique des SOA (architectures orientées services) vers 2008 (+ - 3 ans) - et (malheureusement) sont toujours implémentés principalement dans les applications d'entreprise.
Cela a plusieurs raisons. À l'époque, RESTful HTTP n'était pas bien connu et il était mal compris. Malheureusement, c'est encore mal compris jetez un œil aux autres réponses
"[...] REST est beaucoup plus limité que SOAP [...]."
„Le but principal de REST est de représenter les ressources sur Internet [...]."
De plus, SOAP (et WSDL) font partie de la pile de protocoles de service Web du W3C qui fournit encore plus de normes pour l'implémentation d'un service Web.
Les gens développent-ils encore de nouvelles API basées sur SOAP, ou est-ce principalement un héritage maintenant?
Alors oui, il y en a encore et il y en aura aussi dans les futurs systèmes qui utilisent SOAP (au moins dans les systèmes d'entreprise, principalement derrière les portes). Mais la majorité essaie de faire sorte de "REST" de nos jours.
Quelqu'un peut-il me corriger si je me trompe sur cette différence entre SOAP et REST?
Dire REST est une architecture sans état plus flexible pour le transfert de données n'est pas une bonne explication. Dit simplement REST est un style d'architecture avec des contraintes et des éléments spécifiques. Tandis 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.