SOAP vs REST: résoudre les défis de test de chacun

La différence entre SOAP et REST API. Peut-être que vous êtes déjà bien familiarisé avec SOAP et REST, vous cherchez à élargir vos connaissances ou à obtenir une nouvelle perspective. Ou peut-être que vous en avez entendu parler et que vous essayez de mieux les comprendre. Après tout, SOAP et REST sont bien établis avec des définitions et des spécifications remontant à des décennies.

Permettez-moi de décrire la différence SOAP et REST, de comparer et de faire la lumière sur ces deux approches importantes du service Web et de la conception d'API Web. Je vais également souligner certains des défis de test associés à ces approches et comment les résoudre. Tout d'abord, définissons ce qu'ils sont et comment ils se rapportent au World Wide Web.

Différence entre les services Web SOAP et REST

Les World Wide Web Consortium (W3C) recommande des normes et des protocoles pour la collection mondiale de ressources interconnectées que nous connaissons sous le nom de World Wide Web. Une ressource «Web» est accessible à une adresse «Web» et livrée via un protocole «Web».

En tant que personne lisant ce billet de blog, vous savez peut-être que vous lisez un document HTML à l'URI indiqué dans la barre d'adresse de votre navigateur qui a été demandé et livré à l'aide du protocole HTTP (S). Le W3C a défini comment ces mêmes technologies qui vous permettent de lire ce billet de blog peuvent faciliter la communication entre les systèmes logiciels. En particulier, le W3C a défini des «services Web», ce qui a conduit à la création de nombreuses autres normes et technologies au fil des ans. Jetons un regard de haut niveau sur ce qu'ils sont.

SAVON. Simple Object Access Protocol est un protocole orienté objet dans lequel des objets sont échangés entre le client et le serveur, sérialisés vers et depuis XML. La spécification SOAP s'appuie sur d'autres technologies « Web » telles que définies par le W3C, notamment XML et HTTP. De nombreuses spécifications sont basées sur ou étendent la spécification SOAP, y compris certaines qui ne sont pas si "simples". Un service SOAP échange des messages SOAP avec un client SOAP. Un message SOAP est aussi appelé une « enveloppe ». Une enveloppe SOAP a un élément "Body" et un élément optionnel "Header". Le "Corps" enveloppe généralement ou littéralement "enveloppe" un autre document XML. Une requête SOAP indique également l'opération ou l'action invoquée. Différentes opérations acceptent et renvoient différents types de documents.

DU REPOS. Transfert d'État représentatif. Contrairement à SOAP, REST n'est pas une technologie spécifique mais un style architectural, définissant des contraintes spécifiques pour un système logiciel. Un service Web ou une API Web compatible REST est souvent appelé API RESTful ou API REST. Le but d'une API REST est d'échanger des représentations d'une ressource. Une ressource peut être n'importe quel type d'entité qui peut être conceptuellement identifiée par un URI. Une API REST écoute un URI de base avec des chemins enfants pour accéder à chacune des ressources exposées par l'API. Un chemin de ressource peut inclure un ou plusieurs paramètres qui peuvent être utilisés pour identifier une ressource, certains segments de chemin pouvant contenir des identifiants. Les paramètres de ressource peuvent également prendre la forme de paramètres de requête ou d'en-têtes. Une API REST expose une ou plusieurs opérations CRUD pour récupérer ou manipuler une ressource (créer, récupérer, mettre à jour et supprimer).

Maintenant, explorons quelques détails sur la différence entre le savon et le repos, en comprenant comment ces approches se comparent les unes aux autres.

Opérations

Un service SOAP définit un ensemble d'opérations. Les opérations peuvent être arbitraires dans la mesure où il n'y a aucune restriction quant à la portée ou à l'objectif des opérations définies. Les opérations ont une signature, généralement représentative du nom complet de l'élément à l'intérieur de l'élément Body de l'enveloppe. Par exemple, le nom de l'élément peut être «CalculateSomething» ou «doSomethingFun».

Une API REST a une collection d'opérations pour chaque ressource. Les opérations disponibles sont limitées à CRUD (créer, récupérer, mettre à jour et supprimer). Les opérations sont mappées à des méthodes HTTP telles que GET, POST, PUT, PATCH et DELETE.

Comparaison positive

Opérations SOAP offrent un degré de flexibilité plus élevé car ils ne se limitent pas à CRUD et ne doivent pas être structurés autour de types de ressources spécifiques comme REST. Cependant, les opérations peuvent également être utilisées pour CRUD, où le XML dans le corps SOAP peut inclure une représentation XML d'un objet avec son identifiant.

Opérations REST offrent un plus haut degré de simplicité. Un URI est utilisé pour identifier la ressource, découplé de la représentation de la ressource échangée. De plus, les opérations doivent être sans état, ce qui signifie qu'elles se comportent de manière cohérente et non en fonction de l'état de la conversation entre le client et le point de terminaison de service.

Comparaison critique

Services SOAP peut avoir une complexité beaucoup plus élevée en prenant en charge des opérations arbitraires et en suivant potentiellement l'état. Un exemple pourrait être un service de librairie ayant une opération "addToCart". Chaque fois qu'un client appelle "addToCart", le service suit l'article dans le panier du client. Un client différent peut appeler "addToCart" et ne pas affecter le panier d'achat d'un client différent. Le service suit l'état de chaque client séparément.

API REST sont plus restreints que SOAP en ayant des opérations limitées à CRUD. De plus, les clients ont la charge de suivre leur propre état. Dans l'exemple de la librairie, le client doit connaître l'ID de son panier afin de pouvoir créer l'URI correct pour son panier, comme "cart/{id}". Le client peut effectuer un GET à cet URI pour récupérer une représentation structurée de son panier. Le client peut également faire un PUT à ce même URI pour mettre à jour son panier avec une représentation mise à jour.

Représentation des données

Messagerie SOAP implique l'échange de documents XML appelés enveloppes SOAP. Une enveloppe SOAP contient un élément "Body" et un élément optionnel "Header". Le XML dans l'élément "Body" peut être arbitraire mais représente généralement une ou plusieurs entités ou objets. Le type de contenu est soit "text/xml" soit "application/soap+xml" selon que SOAP version 1.1 ou SOAP version 1.2 est suivi. Les éléments XML du SOAP peuvent également être utilisés pour envelopper d'autres types de données, textuelles ou binaires. Les méthodes définies par le W3C appelées "XOP" et "MTOM" décrivent comment empaqueter efficacement des données binaires dans des messages XML et SOAP en tant que "Multipart/Related" MIME, évitant ainsi d'avoir à coder en base64 les données binaires directement dans des balises XML.

Messagerie API REST implique l'échange de représentations d'une ressource. Une "représentation" peut être n'importe quel format de données. Il peut s'agir d'un format d'échange/d'échange de données structuré tel que XML ou JSON, ou quelque chose de complètement différent comme PDF ou JPEG. Il n'y a pas de restriction de type de contenu. Une API REST peut prendre en charge plusieurs formats de données ou différents formats de données pour différentes ressources.

Comparaison positive

SAVON. XML est standardisé et bien compris, défini par diverses recommandations du W3C. XML a un concept d'espaces de noms, qui aident à lever l'ambiguïté des éléments, en évitant les conflits de noms. Les enveloppes SOAP fournissent une couche d'encapsulation, permettant l'inclusion de métadonnées supplémentaires sous l'élément «En-tête».

DU REPOS. Les API REST ne sont pas limitées en termes de formats de données qu'elles peuvent utiliser. Pour les données structurées, l'utilisation de JSON est courante et beaucoup plus rapide à consommer et à produire que XML. Cependant, il existe d'autres formats de sérialisation de données structurées qui peuvent être encore plus compacts et efficaces que JSON, comme BSON (JSON binaire) ou de Google Tampons de protocole (Protobuf). Tout type de contenu est une possibilité.

Comparaison critique

SAVON. XML peut également être verbeux ou gonflé par rapport à d'autres formats de données avec un coût de sérialisation relativement élevé à la fois à produire et à consommer. Cependant, la taille des messages peut être réduite en utilisant une compression comme le schéma de compression HTTP «Content-Encoding: gzip». Le coût de sérialisation peut être réduit en utilisant des encodages XML alternatifs ou binaires, comme ceux de Microsoft Format binaire .NET pour XML.

DU REPOS. Il n'existe pas de format standard d'échange de données pour les API REST. Ainsi, vous devrez peut-être un ensemble différent de bibliothèques pour consommer et produire des données structurées en fonction de l'API REST avec laquelle vous communiquez. Cependant, JSON est très populaire et souvent disponible.

Extensibilité

SOAP et REST sont extensibles mais de manières très différentes. Plongeons dans la comparaison.

Comparaison positive

SAVON. La liaison de protocole ne doit pas nécessairement être HTTP mais peut être n'importe quoi. Les messages SOAP peuvent être envoyés via d'autres protocoles basés sur TCP comme SMTP ou peuvent être envoyés via un socket UDP comme cela est fait dans WS-Discovery et UPnP. L'infrastructure SOAP .NET WCF de Microsoft possède des transports TCP et des canaux nommés. Interfaces événementielles ou de mise en file d'attente de messages telles que JMS (Java Message Service) ou AMQP (protocole avancé de mise en file d'attente de messages) sont également utilisés pour SOAP.

SOAP permet également différents modèles d'échange de messages. Il n'est pas nécessaire que ce soit une demande-réponse. Cela peut être asynchrone, unidirectionnel ou "fire-and-forget". SOAP est utilisé dans l'architecture orientée services (SOA) où les services sont faiblement couplés, poussent ou réagissent aux messages acheminés par un bus de services d'entreprise (ESB).

DU REPOS. Les API REST sont extensibles dans la mesure où elles peuvent potentiellement représenter des ressources avec différents formats de message. Contrairement à SOAP, vous n'êtes pas limité aux représentations XML. De nouvelles ressources peuvent être ajoutées sans affecter les ressources existantes. Les API REST peuvent être versionnées en incluant un numéro de version ou un identificateur de version dans le cadre de l'URI.

Comparaison critique

SAVON. Une plus grande extensibilité s'accompagne d'une plus grande complexité. Il n'y a pas de moyen unique d'implémenter la messagerie SOAP, étant donné les différents protocoles, modèles de messagerie et spécifications WS- * qui peuvent être appliqués.

DU REPOS. Les API REST sont généralement limitées à HTTP, où la méthode et l'URI de ressource sont envoyés dans l'en-tête de la requête HTTP. Cependant, des approches RESTful ont été réalisées avec d'autres technologies telles que Protocole d'application contraint (CoAP), qui est une implémentation de REST pour les environnements contraints pour les applications Iot (Internet des objets). Les principes RESTful peuvent également être suivis dans les courtiers de messagerie tels que RabbitMQ et MQTT, où l'identificateur de ressource et l'opération CRUD pourraient être potentiellement mappés à des destinations de message ou à des «sujets».

Interopérabilité

SOAP a été conçu avec l'interopérabilité à l'esprit, suivant des normes ouvertes, non lié à une implémentation, une plate-forme ou un langage de programmation spécifiques. Cependant, certains éléments de la spécification ont été laissés ouverts à l'interprétation. Certaines parties peuvent prêter à confusion ou contenir des erreurs, des fautes de frappe ou de mauvais exemples. Les problèmes découlent de choses simples comme si:

• Une valeur particulière est censée être entourée de guillemets ou non.
• Certaines constructions XML sont correctes ou doivent être évitées.
• Des types spécifiques de choses doivent être autorisés ou restreints dans le corps SOAP.

Un autre organisme de normalisation, le Organisation d'interopérabilité des services Web (WS-I), a commencé à fournir des lignes directrices pour l'interopérabilité des services Web. Le WS-I fournit divers profils d'interopérabilité. Chaque profil a une liste d'exigences et une liste d'assertions, qui définissent comment vérifier les exigences. En bref, les profils WS-I disent des choses comme «vous devriez faire ceci» et «vous ne devriez pas faire cela». Fait amusant: Parasoft a contribué au document d'assertions de test (TAD) WS-I Basic Profile 1.1.

Les API REST sont interopérables dans la mesure où elles sont simples à appeler. Il existe de nombreux outils et API qui peuvent effectuer des requêtes HTTP. Les outils populaires incluent cURL et Facteur. Même un simple formulaire sur une page Web peut être utilisé pour effectuer des requêtes HTTP. Il existe également diverses normes ouvertes généralement utilisées pour les API REST en dehors de HTTP, y compris des formats de message ouverts tels que JSON. Les API REST peuvent également implémenter diverses normes ouvertes pour la sécurité et l'autorisation (nous en parlerons plus tard).

Comparaison positive

SOAP a été conçu dans un souci d'interopérabilité. Les spécifications SOAP du W3C sont principalement rédigées par Microsoft, qui possède sa propre pile SOAP qui est implémentée dans le cadre du .NET Framework de Microsoft, à l'origine .NET Web Service Enhancements (WSE) et plus tard .NET Windows Communication Foundation (WCF). Cependant, les piles SOAP sont disponibles auprès de nombreux autres fournisseurs, y compris des projets open source comme le projet Apache. Outre .NET, les piles SOAP sont également disponibles pour différentes plates-formes et langages de programmation tels que Java, Python et TypeScript. Les clients SOAP et les services SOAP implémentés avec différentes piles SOAP sont capables de communiquer s'ils suivent le même ensemble de normes SOAP ouvertes.

REST Les API suivent le principe KISS ("keep it simple, stupid"), suivant les principes généraux de conception de l'architecture logicielle REST. Étant simples à invoquer, les API REST ne nécessitent pas nécessairement une pile logicielle complexe comme vous en avez généralement besoin pour communiquer avec les points de terminaison SOAP.

Comparaison critique

SOAP a une myriade d'extensions souvent appelées WS-*. Il y a WS-Addressing, WS-Policy, WS-Discovery, WS-MetadataExchange, WS-SecureConversation, WS-SecurityPolicy, WS-Trust, WS-Federation. Il existe également WS-Security avec diverses spécifications connexes, notamment celles liées à la signature XML et SOAP, au cryptage XML et SOAP et au SAML (Security Assertion Markup Language). La liste continue encore et encore et encore. Il y a de fortes chances qu'un service SOAP suive plusieurs spécifications WS-*, ajoutant de la complexité à ce qui était initialement défini comme étant un protocole "simple". Votre client doit suivre les mêmes normes WS-* que le service, sinon il ne pourra pas communiquer correctement.

REST Les API ne doivent pas nécessairement suivre des normes ouvertes. Bien que JSON soit très populaire, il n'existe pas de format d'échange de données standard. Tout type de contenu est une possibilité, y compris éventuellement des formats de données propriétaires. De plus, certains cadres de sécurité ou d'autorisation peuvent introduire une complexité supplémentaire, nécessitant une implémentation compatible côté client.

Active Directory

La sécurité est une considération importante pour SOAP et REST. La sécurité de la couche de transport est nécessaire pour crypter les messages au fur et à mesure qu'ils sont envoyés sur le fil afin d'éviter les écoutes clandestines. La sécurité de la couche message est nécessaire pour une sécurité complète de bout en bout, de sorte que le message est protégé de tout intermédiaire qui peut y avoir accès avant d'atteindre sa destination prévue. Des mécanismes d'authentification ou d'autorisation sont nécessaires pour établir l'identité entre le client et le serveur.

Comparaison positive

SOAP possède une vaste collection de spécifications de sécurité connues sous le nom de WS-Security, publiées par l'organisme de normalisation OASIS. Outre les mécanismes de sécurité de la couche de transport tels que HTTPS, les spécifications WS-Security décrivent comment intégrer la sécurité directement dans les messages SOAP eux-mêmes (y compris les signatures, les données chiffrées) et comment empaqueter les jetons de sécurité pour établir une identité comme SAML (Security Assertion Markup Language).

REST peut tirer parti des mécanismes existants dans HTTP pour la sécurité, y compris les schémas d'authentification basés sur SSL et HTTP. Il existe également des normes ouvertes d'autorisation, notamment Connexion OpenID (OIDC), qui s'appuie sur OAuth et quelques autres spécifications ouvertes comme Jeton Web JSON (JWT).

Comparaison critique

SAVON. Les spécifications OASIS WS-Security sont complexes. Les services mettant en œuvre plusieurs spécifications WS-Security et autres spécifications WS- * posent des défis pour la création de clients. De quels magasins clés ai-je besoin? Dois-je également signer le message ou le crypter? Quel algorithme de canonisation XML suis-je censé utiliser? Dois-je d'abord obtenir un jeton SAML et l'inclure dans un en-tête SOAP? Quelles parties du message dois-je signer et chiffrer?

DU REPOS. La sécurité de la couche de message n'est pas standard, certaines étant propriétaires. Par exemple, Amazon AWS fournit des mécanismes côté serveur et côté client pour chiffrer les messages envoyés vers ou depuis leurs API.

Définitions de service

Il existe différents types de formats de documentation sur les consommables machine pour les services SOAP et REST. Les documents de définition de service permettent un traitement automatisé, comme la génération automatisée de code pour les clients ou les talons de service. Les documents de définition de service peuvent également être traduits dans un format de documentation convivial comme une page Web.

Comparaison positive

SAVON. Les services SOAP sont décrits par WSDL, une autre spécification ouverte du W3C. Un WSDL est un document XML. Il définit les points de terminaison de service, les opérations et les schémas XML pour les messages de demande, de réponse et d'erreur.

DU REPOS. Il existe différents formats de définition de service pour les API REST. Ceux-ci inclus OpenAPI, RAML, Plan directeur de l'API et WADL. Ils fournissent tous différents moyens de décrire les éléments communs aux API REST, tels que les chemins de ressources, les paramètres, les opérations, ainsi que le type et le format ou le schéma des représentations. OpenAPI est basé sur Schéma JSON spécifications et peut être représenté sous forme de JSON ou YAML. Les documents RAML sont basés sur YAML et prend en charge à la fois le schéma JSON et le schéma XML (XSD). Le plan de l'API est basé sur la syntaxe Markdown pour la notation d'objet (MSON) avec prise en charge du schéma JSON. WADL est une soumission W3C, basée sur XML avec prise en charge de la description des représentations XML à l'aide de XML Schema, un peu analogue à WSDL pour SOAP.

Comparaison critique

SAVON. La spécification WSDL a quelques problèmes avec des clarifications supplémentaires et des recommandations d'interopérabilité fournies par l'Organisation d'interopérabilité des services Web (WS-I). Il existe également plusieurs versions de WSDL. WSDL 1.1 est le plus couramment implémenté. WSDL 2.0, anciennement WSDL 1.2, n'a pas été adopté par toutes les piles SOAP, y compris .NET WCF de Microsoft. Fait intéressant, WSDL 2.0 a introduit la prise en charge de la description des API REST.

DU REPOS. Il n'existe pas de format de définition de service standard pour les API REST. Cependant, OpenAPI est une considération étroite pour être la norme. OpenAPI a été initialement développé par SmartBear sous le nom de «Swagger», puis donné à la Fondation Linux sous le nom d'OpenAPI. La spécification est supervisée par le Initiative OpenAPI, qui comprend des membres d'un ensemble diversifié de grandes entreprises, notamment Google, IBM et Microsoft.

Chaque format de définition de service possède sa propre collection d'outils pour la génération de code et de doc. Cela signifie que vous devez utiliser un ensemble d'outils différent en fonction de l'implémentation du service. Cependant, des convertisseurs existent afin que vous puissiez convertir un document OpenAPI en RAML (ou vice versa).

Comment suis-je censé tester tout cela? 😵

REST et SOAP offrent leurs propres compromis et défis uniques, en particulier en ce qui concerne les tests. Pour tester une API, vous devez être en mesure de créer des clients, d'envoyer des données d'entrée, puis de pouvoir afficher et valider la sortie renvoyée.

Comparaison positive

SAVON. Un document WSDL peut fournir une description complète d'un service SOAP, y compris ses exigences en matière de sécurité. Il existe divers outils commerciaux et open source disponibles qui peuvent utiliser des documents WSDL pour produire automatiquement des clients pour tester les points de terminaison SOAP. Un exemple simple est celui de Microsoft Client de test WCF .

DU REPOS. Les API REST peuvent également fournir un document de définition de service, qui peut être utilisé pour produire des clients de test. Pour OpenAPI, Interface utilisateur Swagger fournit une interface Web simple pour «essayer» chaque opération exposée par l'API.

Comparaison critique

Services SOAP peut être implémenté à l'aide de protocoles autres que HTTP, où la communication peut nécessiter une interface de messagerie spécifique telle que JMS. Divers protocoles WS-* sont complexes. Les outils gratuits et open source ont des limitations et un manque de support pour tous les protocoles de transport et WS-*. Cependant, Parasoft SOAtest aide à résoudre ce problème, avec une prise en charge complète de SOAP et des protocoles associés.

Services REST n'ont pas nécessairement de définitions de service. La création manuelle de clients peut être difficile et fastidieuse, déterminer la bonne séquence d'appels d'API à enchaîner pour créer les scénarios souhaités. Cependant, Parasoft SOAtest aide à résoudre ce problème. En plus de pouvoir créer des clients de test à partir de différents formats de définition de service, SOAtest Générateur de test d'API intelligent automatise la création de tests d'API en surveillant les appels d'API et en utilisant l'intelligence artificielle pour créer et configurer automatiquement des scénarios de test.

Votre tête tourne encore ? Laissez Parasoft vous aider. Réduisez le coût, le temps et la complexité des interfaces de service de test avec la solution complète de test d'API de bout en bout, Parasoft SOAtest.