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

Vous connaissez peut-être déjà SOAP et REST. Après tout, SOAP et REST sont bien établis avec des définitions et des spécifications remontant à des décennies. Vous cherchez à approfondir vos connaissances ou à acquérir une nouvelle perspective ? Ou peut-être avez-vous entendu parler des deux et souhaitez-vous mieux comprendre?

Permettez-moi de décrire les différences SOAP et REST, de les comparer et de faire la lumière sur ces deux approches importantes de la conception de services Web et d'API Web. Je soulignerai également 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

Le 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 cet article de blog, vous savez peut-être que vous lisez un document HTML à l'URL indiquée 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 cet article de blog peuvent faciliter la communication entre les systèmes logiciels. En particulier, le W3C a défini les "services Web", ce qui a conduit à la création de nombreuses autres normes et technologies au fil des ans. Jetons un coup d'œil à ce qu'ils sont.

Comprendre le savon

SOAP est l'acronyme de Simple Object Access Protocol. C'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, 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.

Avant de commencer à détailler les différentes qualités de SOAP et comment elles se comparent à REST, commençons par expliquer comment SOAP est né en premier lieu. L'histoire de SOAP commence vraiment avec l'histoire de XML et du Web lui-même. XML a été développé pour le Web suite au succès du HTML, le format de données utilisé pour les documents affichés dans les navigateurs Web.

Comme HTML, XML était destiné à être à la fois lisible par l'homme et consommable par la machine et servi sur le Web. XML a été développé comme un moyen de regrouper et d'envoyer des données structurées arbitraires, ce que HTML n'était pas fait pour accomplir. Il s'avère que XML n'a résolu que quelques problèmes, ce qui a conduit à l'introduction de SOAP.

La communication entre les applications sur le Web pose divers problèmes d'interopérabilité, en particulier avec les applications développées dans différents langages ayant différents types de données. Par exemple, une application Web peut être construite avec PHP, une autre avec .NET et une autre avec Java. Pour relever les défis de l'interopérabilité, une approche consiste à utiliser XML comme format d'échange de données.

XML fournit un moyen standardisé de décrire des données arbitraires et structurées. D'autres spécifications telles que le schéma XML définissent un système de type commun indépendant des langages de programmation utilisés. Cependant, l'utilisation de XML pose un autre défi : il n'y a pas de méthode standard pour décrire comment les données doivent être organisées dans le XML ni comment elles doivent être traitées. SOAP a été développé en tant que framework indépendant du langage de programmation pour les appels de procédure à distance basés sur XML et le schéma XML.

SOAP définit un ensemble de règles pour la structure et la communication des messages. 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. L'en-tête contient des détails facultatifs tels que l'authentification ou les métadonnées, tandis que le corps porte le contenu réel du message.

L'un des principaux avantages de SOAP est son indépendance vis-à-vis de la plate-forme et du langage, ce qui signifie que les systèmes développés sur différentes technologies peuvent communiquer de manière transparente en utilisant SOAP comme protocole de messagerie. De plus, SOAP est hautement extensible et prend en charge de nombreux styles de communication, y compris la requête/réponse et la messagerie unidirectionnelle. Il est souvent utilisé dans les systèmes d'entreprise qui nécessitent des opérations complexes et des contrats de message stricts.

Comprendre REST

REST est l'acronyme de REpresentational State Transfer. 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.

Comme SOAP, les API REST exploitent l'infrastructure HTTP existante et l'utilisation des normes Web existantes pour permettre l'interopérabilité. REST fournit également une approche légère et évolutive de la communication entre les clients et les services. Les services RESTful sont construits autour des ressources. Une ressource est tout type d'entité abstraite qui est identifiée par un URI (Uniform Resource Identifier).

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. Les clients interagissent avec ces ressources en envoyant des requêtes HTTP, à l'aide d'opérations CRUD standard : créer, lire, mettre à jour et supprimer. REST exploite les verbes du protocole HTTP (GET, POST, PUT, PATCH, DELETE) et les codes d'état pour effectuer des opérations sur les ressources et transmettre des informations sur la réponse.

REST utilise principalement JavaScript Object Notation (JSON) pour la représentation des données. JSON est un format léger et lisible par l'homme, ce qui facilite son utilisation et sa compréhension. Il s'aligne également bien avec les technologies de développement Web modernes et les frameworks basés sur JavaScript.

Une caractéristique notable de REST est son apatridie. Chaque demande d'un client à un service RESTful contient toutes les informations nécessaires pour traiter cette demande. Le serveur ne maintient aucune session ou état client, ce qui le rend hautement évolutif et permet l'équilibrage de charge sur plusieurs serveurs.

Maintenant, approfondissons quelques détails sur les différences entre SOAP et REST, 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 en ce sens qu'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 possède une collection d'opérations pour chaque ressource. Les opérations disponibles sont limitées à CRUD (créer, lire, mettre à jour et supprimer). Les opérations sont mappées sur 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. Le W3C a défini des optimisations appelées "XOP" et "MTOM" qui 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), ou Apache Euro. 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 d'échange de données standard pour les API REST. Ainsi, vous aurez peut-être besoin d'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. Il peut être asynchrone, à sens unique ou à feu et à oublier. SOAP est utilisé dans l'architecture orientée services (SOA) où les services sont faiblement couplés, poussant ou réagissant 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 comme RabbitMQ et la MQTT, où l'identificateur de ressource et l'opération CRUD peuvent potentiellement être mappés sur des destinations ou des rubriques de message.

Interopérabilité

SOAP a été conçu dans un souci d'interopérabilité, en suivant des normes ouvertes, et non lié à une implémentation, une plate-forme ou un langage de programmation spécifique. Cependant, certaines choses dans la spécification ont été laissées ouvertes à interprétation. Certaines parties peuvent prêter à confusion ou contenir des erreurs, des fautes de frappe ou de mauvais exemples. Les problèmes proviennent 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), est venu 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 « Tu devrais faire ceci » et « Tu ne devrais pas faire cela ».

Fait amusant! Parasoft a contribué au document WS-I Basic Profile 1.1 Test Assertions Document (TAD).

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 la 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 qui sont généralement utilisées pour les API REST en dehors de HTTP, y compris les formats de message ouverts comme JSON. Les API REST peuvent également implémenter diverses normes ouvertes pour la sécurité et l'autorisation. Plus sur cela 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 existe WS-Addressing, WS-Policy, WS-Discovery, WS-MetadataExchange, WS-SecureConversation, WS-SecurityPolicy, WS-Trust et 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 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 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 d'autres spécifications WS-* posent des défis aux clients du bâtiment.

• De quels magasins de clés ai-je besoin ?
• Dois-je également signer le message ou le chiffrer ?
• 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, WADL. Ils fournissent tous différentes manières de décrire des éléments communs aux API REST, tels que les chemins d'accès aux 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 documentation. Cela signifie que vous devez utiliser un ensemble d'outils différent en fonction de l'implémentation du service. Cependant, des convertisseurs existent pour que vous puissiez convertir un document OpenAPI en RAML ou vice versa.

Cas d'utilisation et exemples

SOAP et REST peuvent satisfaire des cas d'utilisation similaires mais varient dans la manière dont ils traitent les demandes et les réponses. Voici quelques exemples.

Cas d'utilisation SOAP

Voici quelques cas d'utilisation de services Web basés sur SOAP.

1. Service de conversion de devises

Un service Web qui permet aux clients de convertir entre différentes devises. Le client envoie une requête SOAP contenant la devise source, la devise cible et le montant à convertir. Le serveur traite la requête et renvoie une réponse SOAP contenant le montant converti.

2. Système de réservation de vols

Un service Web qui permet aux clients de réserver des vols. Le client envoie une demande SOAP avec les détails de vol nécessaires comme la ville de départ, la destination, la date et les informations sur les passagers. Le serveur traite la demande et renvoie une réponse SOAP confirmant la réservation.

3. Service d'information météorologique

Un service Web qui fournit des informations météorologiques pour un lieu donné. Le client envoie une requête SOAP avec l'emplacement souhaité et le serveur répond par un message SOAP contenant des détails tels que la température, l'humidité et les prévisions.

4. Système de gestion client

Un service Web qui gère les informations client pour une plate-forme de commerce électronique. Le client peut envoyer des requêtes SOAP pour créer, mettre à jour ou récupérer des données client. Le serveur traite les demandes et envoie des réponses SOAP avec le statut approprié ou les informations client demandées.

Dans chaque cas d'utilisation, les requêtes et réponses SOAP sont des messages XML structurés échangés entre le client et le serveur. L'exemple ci-dessous l'explique mieux.

Exemple de savon

Voici un exemple d'extrait de code d'une application bancaire qui utilise SOAP pour interagir avec un serveur pour la gestion de compte.

Dans cet exemple, la demande SOAP concerne une opération de transfert de fonds. La demande comprend le compte source, le compte de destination et le montant du transfert. La réponse SOAP inclut l'ID de transaction et l'état du transfert.

Cas d'utilisation REST

Voici quelques cas d'utilisation d'API REST qui exploitent HTTP et JSON.

1. Plateforme de médias sociaux

L'API REST pour une plate-forme de médias sociaux permet aux utilisateurs de créer, de récupérer, de mettre à jour et de supprimer des publications, des commentaires et des profils d'utilisateurs. Les clients peuvent utiliser des méthodes HTTP telles que POST, GET, PUT et DELETE pour interagir avec les points de terminaison de l'API. Par exemple, un client peut envoyer une requête POST pour créer une nouvelle publication, une requête GET pour récupérer une liste de publications ou une requête PUT pour mettre à jour les informations de profil d'un utilisateur.

2. Boutique de commerce électronique

L'utilisation d'une API RESTful pour une boutique de commerce électronique permet aux clients de parcourir les produits, d'ajouter des articles à un panier, de passer des commandes et de récupérer l'historique des commandes. Les clients peuvent utiliser des méthodes HTTP pour effectuer des actions telles que GET pour récupérer des informations sur le produit, POST pour ajouter des articles au panier et PUT ou DELETE pour mettre à jour ou supprimer des articles du panier.

3. Services financiers

Une API RESTful pour un service financier permet aux clients d'effectuer diverses opérations telles que les demandes de solde de compte, les transferts de fonds et la récupération de l'historique des transactions. Les clients peuvent utiliser des méthodes HTTP telles que GET pour récupérer les informations de compte, POST pour initier un transfert de fonds et GET pour récupérer l'historique des transactions.

4. Service de cartographie et de géolocalisation

Lorsqu'elle est utilisée pour les services de cartographie et de géolocalisation, une API REST peut fournir des fonctionnalités de recherche d'adresse, de géocodage et de routage. Les clients peuvent envoyer des demandes aux points de terminaison de l'API avec des paramètres tels que des adresses, des coordonnées ou des itinéraires spécifiques pour obtenir les informations souhaitées. L'API répond avec les données correspondantes dans un format tel que JSON ou XML.

Exemple REST

Considérons maintenant une API de base de données de films qui utilise REST pour récupérer les informations sur les films.

Dans l'exemple ci-dessus, la requête REST consiste à récupérer des informations sur un film spécifique avec l'ID "123456". La réponse REST a un code d'état de 200 (OK) et est au format JSON, fournissant des détails tels que le titre du film, l'année, le réalisateur, le genre et la classification.

Les exemples ci-dessus mettent en évidence les différences dans la manière dont les demandes et les réponses sont échangées, mais ils peuvent également satisfaire les mêmes cas d'utilisation. En d'autres termes, les API REST ci-dessus pourraient être implémentées en tant que services SOAP et vice versa.

Pour une API REST donnée, une opération SOAP peut être définie pour chaque opération CRUD et tous les paramètres de ressource peuvent être traduits en éléments XML dans le corps SOAP. Les exemples SOAP ci-dessus peuvent également être implémentés en tant qu'API REST. Une approche consiste à mapper différentes opérations SOAP sur différents verbes HTTP. L'exemple du système de gestion des clients fonctionne bien pour cela, avec des opérations SOAP basées sur CRUD qui seraient proprement mappées aux verbes HTTP correspondants.

L'autre approche consiste à mapper différentes opérations SOAP sur différents chemins de ressources. L'exemple de conversion de devise pourrait être rendu RESTful en ayant le type de devise représenté dans l'URI de la ressource. Ensuite, vous pouvez littéralement "OBTENIR" la représentation de la devise souhaitée où les paramètres de conversion sont soumis en tant que paramètres de requête tels que "/conversion/dollar?fromAmount=5&fromType=pesos" qui pourrait renvoyer le résultat sous la forme d'un numéro JSON.

Comparaison de SOAP et REST pour les tests d'API

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 d'afficher et de valider la sortie renvoyée. Pour établir une comparaison complète entre les deux, examinons d'abord SOAP et REST pour les tests d'API selon les lignes suivantes.

Testabilité

Les API SOAP sont plus complexes et nécessitent des outils spécialisés qui comprennent le protocole SOAP. Le test des services basés sur SOAP implique l'analyse XML, l'interprétation des spécifications WSDL et WS-* et la gestion des structures d'enveloppe SOAP. Heureusement, un outil de test SOAP sophistiqué comme Parasoft SOAtest fournit des fonctionnalités telles que la génération automatisée de tests, simplifiant ces complexités et rendant les tests d'API SOAP plus rapides et plus efficaces.

D'autre part, les API REST suivent une conception plus simple, tirant parti des méthodes HTTP standard et des formats de données tels que JSON. Cette simplicité rend les API REST plus accessibles pour les tests. Parasoft SOAtest offre également un excellent support pour les tests d'API REST, permettant aux testeurs de construire facilement des requêtes HTTP, de valider les réponses et d'effectuer des tests fonctionnels et d'intégration.

Exécution des tests

Les tests d'API SOAP impliquent l'exécution de scénarios de test qui interagissent avec l'API via des enveloppes SOAP. Cela nécessite de gérer l'analyse XML, les en-têtes SOAP et le respect du protocole SOAP et de diverses normes WS-*. Les services SOAP peuvent également être implémentés sur des protocoles de transport autres que HTTP. Bien que cela puisse sembler trop complexe, les fonctionnalités étendues fournies par SOAtest, avec une prise en charge complète de nombreux protocoles de transport et des spécifications SOAP WS-* complexes, permettent d'automatiser ces processus.

Les tests d'API REST, avec leur nature simplifiée, offrent une exécution plus rapide des tests, ce qui facilite la vérification du comportement et de la réponse de l'API. Les API REST se prêtent également bien à l'automatisation, car les frameworks de test populaires fournissent souvent des bibliothèques robustes pour effectuer des requêtes et des assertions HTTP. Cela permet la création de suites de tests automatisées qui peuvent être facilement intégrées dans des pipelines d'intégration continue (CI/CD).

Génération de cas de test

Les API SOAP s'appuient sur les spécifications WSDL (Web Service Description Language) pour définir leurs opérations, types de données et structures de message. Cette spécification formelle facilite la génération de cas de test basés sur le contrat défini. Alors que certains outils peuvent aider à la génération de cas de test, Parasoft SOAtest construit des clients sophistiqués qui adhèrent correctement aux types de schéma XML et aux exigences WS-* décrites par le WSDL, réduisant ainsi l'effort manuel requis pour créer des scénarios de test.

Les API REST sont souvent décrites par un document formel comme une définition OpenAPI. Les documents de définition de service peuvent être volumineux ou complexes, selon le nombre de ressources, de paramètres et de types de schéma JSON. Parasoft SOAtest construit des clients sophistiqués qui adhèrent correctement aux types de paramètres et de schémas JSON attendus par chaque ressource et méthode HTTP. Cependant, les API REST manquent parfois d'une spécification formelle comme OpenAPI, ce qui peut rendre la génération de cas de test plus difficile.

Les testeurs s'appuient souvent sur des messages de trafic préenregistrés pour définir leurs scénarios de test. Bien que cela implique normalement un degré plus élevé d'effort manuel, le générateur de test d'API intelligent de Parasoft SOAtest automatise la création de test en surveillant les appels d'API et en tirant parti de l'intelligence artificielle (IA) pour construire et configurer automatiquement des scénarios de test.

Cela dit, il est crucial de noter que le choix entre SOAP et REST pour les tests d'API dépend des exigences spécifiques du projet. Les fonctions de contrat et de validation strictes de SOAP conviennent aux applications d'entreprise qui exigent la normalisation et l'interopérabilité. D'autre part, REST excelle dans la simplicité, la flexibilité et la facilité de test, ce qui en fait un choix préféré pour de nombreux services Web modernes. Néanmoins, l'option la plus adaptée à votre projet bénéficiera de l'automatisation des tests d'API offerte par Parasoft SOAtest.

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'IA pour construire 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.