Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

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

De Joseph Benken

9 juillet 2020

11  min lire

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.

SOAP Protocole d'accès aux objets simple est un protocole orienté objet dans lequel les 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, y compris 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 également appelé «enveloppe». Une enveloppe SOAP a un élément «Corps» et un élément «En-tête» facultatif. Le «corps» enveloppe ou littéralement «enveloppe» un autre document XML. Une requête SOAP indique également l'opération ou l'action appelée. Différentes opérations acceptent et renvoient différents types de documents.
REST Transfert d'état de représentation. 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 identifié conceptuellement 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 identificateurs. 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

SOAP Les opérations SOAP offrent un degré plus élevé de flexibilité car elles ne se limitent pas à CRUD et ne doivent pas être structurées 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 identificateur.
REST Les opérations REST offrent un plus haut degré de simplicité. Un URI est utilisé pour identifier la ressource, découplée de la représentation de la ressource échangée. En outre, les opérations doivent être sans état, ce qui signifie que les opérations 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

SOAP Les services SOAP peuvent 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 avoir d'incidence sur le panier d'un autre client. Le service suit l'état de chaque client séparément.
REST Les API REST sont plus restreintes que SOAP en ayant des opérations limitées à CRUD. De plus, les clients ont le fardeau de suivre leur propre état. Dans l'exemple de la librairie, le client a besoin de 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 effectuer un PUT sur ce même URI pour mettre à jour son panier avec une représentation mise à jour.

Représentation des données

La messagerie SOAP implique l'échange de documents XML appelés enveloppes SOAP. Une enveloppe SOAP contient un élément «Corps» et un élément «En-tête» facultatif. 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 «text / xml» ou «application / soap + xml» selon que SOAP version 1.1 ou SOAP version 1.2 est suivie. Les éléments XML dans 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 d'avoir à coder en base64 les données binaires directement dans des balises XML.

La messagerie de l'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

SOAP 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».
REST 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

SOAP 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.
REST 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

SOAP 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).

REST 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

SOAP 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.
REST 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 un  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 un  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 SOAP a été conçu dans un souci d'interopérabilité. Les spécifications SOAP du W3C sont principalement créé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 REST suivent le principe KISS («Keep it simple, stupid»), suivant les principes généraux de conception de l'architecture logicielle REST. Étant simples à appeler, 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 SOAP a une myriade d'extensions souvent appelées WS- *. Il existe 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 chiffrement XML et SOAP et à 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 REST ne doivent pas nécessairement suivre des normes ouvertes. Bien que JSON soit très populaire, il n'existe pas de format standard d'échange de données. 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.

Sécurité

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 SOAP a une grande 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 REST peut tirer parti des mécanismes existants dans HTTP pour la sécurité, y compris les schémas d'authentification SSL et HTTP. Il existe également des normes ouvertes pour l'autorisation, notamment Connexion OpenID (OIDC), qui s'appuie sur OAuth et quelques autres spécifications ouvertes comme Jeton Web JSON (JWT).

Comparaison critique

SOAP 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?
REST 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

SOAP 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.
REST Il existe différents formats de définition de service pour les API REST. Ceux-ci inclus OpenAPIRAMLPlan directeur de l'APIet 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

SOAP 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.
REST 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

SOAP 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 .
REST 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

SOAP Les services SOAP peuvent être mis en œuvre à 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, grâce à une prise en charge complète de SOAP et des protocoles associés.
REST Les 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. Pourtant, 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-t-elle encore? Laissez Parasoft vous aider. Réduisez le coût, le temps et la complexité des tests des interfaces de service avec la solution complète de test API de bout en bout, Parasoft SOAtest. Qu'il s'agisse de SOAP, REST ou d'autres interfaces ou technologies de service, SOAtest est là pour vous. Demander une démo aujourd'hui!

Vous cherchez au-delà de SOAP et REST? Consultez notre livre blanc sur les microservices de test pour en savoir plus sur les approches modernes des architectures orientées services et tests de microservices.

Test des microservices: obtenez le livre blanc

De Joseph Benken

Joseph est ingénieur logiciel senior chez Parasoft. Il a contribué au développement de nombreuses fonctionnalités et technologies de base utilisées dans divers produits, notamment SOAtest, Virtualize et Selenic. Il travaille chez Parasoft depuis 2006.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.