Comparaison entre REST et SOAP - Développement des applications modernes

Les développeurs ont l'embarras du choix pour créer des applications modernes. Les langages statiques ou dynamiques, les acteurs établis comme Java ou les nouveaux venus comme Golang, les frameworks monolithiques tout-en-un ou les bibliothèques modulaires, ou encore l'exécution de toute votre pile avec Javascript, ne sont en fait que la partie émergée de l'iceberg. Il faut ensuite ajouter à cette liste un choix déterminant, une décision qui appartient aux développeurs : REST ou SOAP.

En termes simples, REST et SOAP sont des méthodes de communication entre applications. Bien que l'objectif final soit le même, REST et SOAP ne peuvent pas être comparés directement. En effet, REST est un ensemble de directives que les développeurs peuvent choisir de mettre en œuvre différemment, selon le projet. Tandis que SOAP est un protocole bien défini et normalisé pour l'échange de données. Néanmoins, vous pouvez établir une comparaison basée sur leurs avantages et inconvénients respectifs. Les deux sont encore largement utilisés dans le secteur. Nous espérons faire ici même la lumière sur les raisons pour lesquelles vous pourrez ou devrez utiliser l'un plutôt que l'autre.

Representational State Transfer (REST) est un modèle d'architecture logicielle couramment utilisé pour développer des applications Web modernes, qu'il s'agisse de sites Web, d'applications mobiles, de jeux ou autres. Le développement d'une API basée sur REST permet d'exposer les fonctionnalités de votre service Web via HTTP et d'interagir avec elle sur le Web. En utilisant des verbes HTTP comme GET et POST, le client demande à l'API de récupérer ou de créer des ressources.

L'interopérabilité et la flexibilité des API RESTful sur le Web leur ont valu une évidente renommée. Les services Web construits avec cette architecture peuvent évoluer indépendamment des applications qui les utilisent. Les API basées sur REST ne disposent pas d'un protocole de sécurité clairement défini. Cependant, les jetons JSON Web Token (JWT) sont la méthode la plus courante pour authentifier et autoriser les demandes.

Avantages

• Sans état – Chaque appel au service Web contient toutes les données dont il a besoin pour traiter la demande. Il n'a pas besoin de stocker le contexte client-serveur.
• Flexible – Les API RESTful peuvent accepter et servir des données dans de nombreux formats différents, notamment JSON, XML, Atom et autres. JSON est de loin le format de données le plus populaire utilisé dans les API basées sur REST.
• Mise en mémoire cache possible – Les réponses peuvent être mises en cache, ce qui peut améliorer considérablement les performances du service Web en éliminant les appels inutiles au backend.

Inconvénients

• Normes – Aucune norme n'a été définie pour la création d'API basées sur REST. Plusieurs ressources et guides de qualité sont disponibles, tels que les normes RESTful API de la Maison-Blanche et le Tutoriel REST API, mais il existe de nombreuses permutations d'API basées sur REST.
• HTTP – Les applications RESTful sont limitées au protocole HTTP.

Simple Object Access Protocol (SOAP) d'autre part est un protocole conçu pour l'échange de données. Ses avantages sont liés à l'ensemble de règles et de normes qui doivent être respectées pour assurer la réussite des interactions client/serveur. Les demandes SOAP sont transmises par des enveloppes qui doivent contenir toutes les informations nécessaires au traitement de la demande.

Une enveloppe de demande SOAP contient généralement un en-tête facultatif et un attribut de corps obligatoire. L'attribut En-tête contient des informations telles que les informations d'identification de sécurité et d'autres métadonnées. L'attribut Corps est réservé au traitement des données réelles et des erreurs éventuelles. Ceci est évidemment une explication simplifiée de la gestion des échanges de données par SOAP. Pour des informations plus détaillées, consultez les Spécifications W3C. Si vous souhaitez écrire un service Web SOAP, essayez un tutoriel facile à suivre.

Avantages

• WSDL – Le Web Services Description Language (WSDL) décrit les méthodes des services Web, l'accès et d'autres paramètres, ce qui en fait un guichet unique pour apprendre à utiliser les API.
• Extensibilité – Les extensions WS-* telles que WS-Security, WS-Addressing, WS-Federation et autres peuvent considérablement améliorer les capacités de l'application.
• Protocole neutre – Accessible via HTTP, SMTP, TCP et d'autres protocoles applicatifs.

Inconvénients

• XML Infoset – SOAP utilise XML pour transférer les données des charges utiles, dont la sérialisation peut exiger beaucoup plus de temps, aboutissant à des problèmes de performances.
• Syntaxe complexe – SOAP fonctionne exclusivement avec XML. La lecture des enveloppes de données peut s'avérer difficile et chronophage.

Les API RESTful sont présentes partout. Depuis les applications Web monopages à l'Internet des objets (IoT), les services optimisés par des API basées sur REST sont la norme. Outre les avantages techniques décrits ci-dessus, les API REST conviennent parfaitement aux attentes de nombreuses entreprises, car elles sont généralement plus faciles à comprendre et à développer. REST est un excellent choix pour les startups, les applications mobiles et les développeurs qui créent des applications Web monopages (SPA) modernes.

De nombreuses entreprises sont basées sur la fourniture d'une API RESTful, qui résout un problème spécifique, pour s'intégrer à n'importe quelle application en toute transparence. Auth0 en est un exemple remarquable. Dans d'autres études de cas courants de REST, des entreprises proposent leur jeu de données, autorisant des tiers à développer des produits à partir de l'API exposée, telle que l'application Falcon basée sur l'API RESTful de Twitter.

De nombreux environnements d'entreprise utilisent des services Web basés sur SOAP. Des environnements de grandes entreprises, comme dans les secteurs de la banque et de la santé, ont choisi SOAP, car il offre une plus grande souplesse et un meilleur contrôle des interactions client/serveur. La mise en œuvre de méthodes complexes est généralement plus facile avec SOAP ainsi qu'avec des transactions compatibles ACID.

SOAP est mieux adapté aux besoins de l'entreprise, mais cela ne veut pas dire que ces services ne peuvent pas, ou ne doivent pas, être utilisés pour des projets de moindre envergure. Le seul bémol est que le développement d'une application SOAP nécessite généralement plus de temps. Alors, si vous ne faites qu'expérimenter une idée, vous avez le risque d'être submergé par la complexité, au lieu de produire du code. Dans le débat qui oppose REST à SOAP, un test décisif courant stipule que « si vous ne pouvez pas trouver une raison spécifique pour construire votre service Web avec SOAP, utilisez REST ».

Les API REST sont généralement authentifiées par des JSON Web Tokens (JWT). Lorsqu'un point terminal d'API doit être protégé, la stratégie consiste à exiger que le client ajoute dans l'API, faisant l'objet de sa demande, un en-tête Autorisation contenant un jeton qui vérifie l'identité du demandeur. Le serveur vérifie ensuite que le jeton est valide. Il pourra traiter la demande s'il est validé.

L'utilisation de l'authentification par jeton apporte de nombreux avantages, que vous pouvez découvrir ici. Les API REST ne sont pas limitées à l'authentification par jeton. Vous pouvez utiliser l'authentification par cookie ou par session, ou même créer votre propre mécanisme d'authentification.

Prenons un exemple pour expliquer comment vous pouvez protéger votre API RESTful avec JWT. Vous avez créé une application mobile qui affiche chaque jour une citation motivante. Cette citation quotidienne est récupérée par une demande GET envoyée à votre API RESTful à l'adresse /api/v1/quote Vous avez reçu d'excellents commentaires et vos utilisateurs se multiplient. Vous voulez leur donner la possibilité de proposer leurs propres citations à intégrer dans l'appli.

Un nouveau point terminal RESTful est créé pour recevoir une demande POST envoyée à /api/v1/quote, dont le corps contient les données requises. La citation proposée pourra alors être enregistrée dans la base de données, où vous pourrez l'évaluer. Vous ne voulez pas que n'importe qui puisse vous envoyer des citations. Seuls des utilisateurs enregistrés doivent être autorisés. La mise en œuvre de l'API est la suivante :

...

routes.post('/api/v1/quote', function(req, res){
    // getToken est une fonction d'aide qui recherche une clé
    // Autorisation dans l'en-tête qui contient la valeur 'Bearer {token}'
    // elle supprime alors le mot-clé Bearer et renvoie uniquement  {token}
    var token = getToken(req.headers.authorization);
    var quote = req.body.quote;

    jwt.verify(token, 'secret', function(err, decoded){
        if(err){
            res.json(err) // Renvoyer les détails de l'erreur
        } else {
            // Save the quote to a database
            res.json({'message':'Quote Successfully Submitted. Thank you!'}); 
        }
    });
});

...

Dans l'implémentation ci-dessus, lorsqu'un utilisateur envoie une requête POST au point terminal /api/v1/quote, nous extrayons son JWT et nous le stockons dans une variable appelée token. Si l'en-tête Autorisation n'existe pas, nous arrêtons simplement l'exécution, car nous pouvons supposer sans risque que l'utilisateur n'est pas authentifié. Si nous obtenons un jeton, nous vérifions qu'il est valide. Le jeton est vérifié par rapport à un code secret avec lequel il a été initialement signé. De plus, nous vérifions que ce jeton n'a pas expiré. L'objet decoded peut contenir des données supplémentaires, telles que les autorisations de l'utilisateur qui peuvent être ajoutées lors de la création du jeton. Mais cette démonstration doit rester simple.

POST vers API avec un JWT valide

POST vers API sans JWT valide

Si tout est confirmé et qu'aucune err n'apparaît, nous pouvons conclure que l'utilisateur est authentifié. Nous sauvegardons donc sa citation dans la base de données. Nous lui envoyons un message sympathique pour le remercier d'avoir utilisé notre application. Dans cet exemple, nous avons vérifié le jeton dans l'implémentation du point terminal. Dans un scénario réel, la vérification du jeton serait, de préférence, effectuée par un middleware situé plus haut dans la pile d'appels.

Auth0 peut facilement se charger de générer des JWT dans le workflow d'authentification. Lorsqu'un utilisateur est correctement connecté, Auth0 renvoie un JWT que vous stockez dans un stockage local ou un cookie. Ensuite, chaque fois qu'une demande est envoyée à l'API, vous ajoutez le jeton dans l'en-tête sous une clé Autorisation. Côté serveur, vous devrez valider ce jeton, ce qui est une tâche simple (comme nous l'avons déjà vu) si vous utilisez l'un des nombreux SDK d'Auth0.

SOAP est tout aussi flexible que REST pour protéger et authentifier un service Web. WS-Security est l'extension clé qui prend en charge de nombreux modèles d'authentification, notamment : les identifiants de base nom d'utilisateur/mot de passe, SAML, OAuth et plus encore.

L'authentification unique SAML (SSO - Single Sign On) est une méthode courante pour authentifier les API SOAP. SAML facilite l'échange d'informations d'authentification et d'autorisation entre les applications. Une fédération SAML combine trois parties : un utilisateur, un fournisseur d'identifiants et un fournisseur de service. L'utilisateur fait une demande avec le fournisseur de services destinée à un fournisseur d'identifiants. Si la demande aboutit, l'utilisateur est authentifié et peut accéder à l'application.

La mise en œuvre de l'authentification unique (SSO) SAML peut être une tâche décourageante, difficile et longue. Mais Auth0 est là pour vous faciliter la vie. Voyons comment nous pouvons rapidement configurer l'authentification unique (SSO) SAML avec SSOCircle. Auth0 sera le fournisseur de services, tandis que SSOCircle sera le fournisseur d'identifiants. Par conséquent, lorsqu'un utilisateur tente de se connecter, il sera dirigé vers SSOCircle pour vérifier son identité.

Une fois un compte SSOCircle créé, nous allons chercher les métadonnées publiques pour SSOCircle. Vous trouverez des informations utiles sur https://idp.ssocircle.com/. Ensuite, nous avons besoin de générer trois attributs : le certificat de signature X509 KeyDescriptor, l'emplacement de redirection SingleSignOnService et l'emplacement de redirection SingleLogoutService.

Nous commençons par créer un nouveau fichier .pem, pour stocker le certificat et en copiant le certificat X509. Nous devrons également ajouter les délimiteurs de début et de fin de certificat, comme indiqué ci-dessous.

-----DÉBUT DE CERTIFICAT-----
MIIDATCCAemgAwIBAgICCpgwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCREUx
EjAQBgNVBAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTkzNDEx
WhcNMjEwODE3MTkzNDExWjAuMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2ly
Y2xlMQswCQYDVQQDEwJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALm1xZq5goTh7NmdzZsZUJed9+7XauwuaNuGyZpIGRo4FsP1YPgs+40mYAoa9rDj
CEekixkfSI6nBUMdHuRIMHogyu/OVxskrL91SLO5m5u9JhgIhO/s9pnmnrnNUILf
RccE4+AEO1xsBQ/x1sY2zDZk+71Pfvifc9vVxedHpNAumbe1nb+CofUtAbF6PkHv
g3pqCoMPmC7m4NAr9h+zq3ekeWf8j5SOicupet9XhsO6zUr0Wga/Zs6J0khhYmFy
zpqoP2rLJ4a/9qduSGslOWsed6kD+zvhLMAUVcw3goli4VhepNzU5iGL9QdVj7m4
YQRMofBRYyL7tBWO6jzLpFcCAwEAAaMpMCcwFAYJYIZIAYb4QgEBAQH/BAQDAgD/
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKmOo8un97VFxNgo
iAzpU5fugKdAFFnKHTvUzDLQ81O455OyT6tcAsXHz6sy2c6GozqDV7xrXSqnues8
p9/w0KzVY9/YuxB90uiSJVh0zMxS+NwyfG1Od5Brloh9eBM4YulUI3V2ustcck17
2G4X4/QSK8uo0bjELUzSNAGj7uypsKKXjX++enfAJzLSsqk3Y8Tmon4R6GYBj4mo
1nL6ujeXqB/kH44XnEmU7ojyIC1kawFRdY4GDFIq3HOBFNzlNbJVL+jKdgTQJTET
rNTDjxXmxwpZ90+lPbEaLQeElwAQi7pMtcqD/f8Dqaifk9ZvpCB7NC+oLM5ej9nK
TawsVqs=
-----FIN DE CERTIFICAT-----

Enregistrez ce fichier sous le nom : SSOCircle.pem. Accédez au tableau de bord Auth0 et créez une nouvelle connexion SAMLP Identity Provider dans Connections. Dans le sous-menu Enterprise, cliquez sur l'icône + dans la section SAMLP Identity Provider. Les paramètres que nous pouvons configurer ici sont nombreux. Pour notre démonstration, nous allons d'abord définir un nom de connexion. Vous êtes totalement libre de choisir n'importe quel nom. Pour cette démonstration, nous pouvons ignorer les domaines de messagerie, qui servent normalement à définir les domaines qui fonctionneront automatiquement avec l'authentification unique (SSO). Il s'agit généralement du domaine de votre entreprise.

Nous avons les URL de connexion et de déconnexion qui proviennent des métadonnées publiques de SSOCircle. Nous pouvons les insérer ici. La dernière partie de la configuration consiste à télécharger le certificat .pem, que nous avons créé plus tôt. Une fois ces paramètres configurés, nous pouvons ignorer le reste et terminer cette étape en cliquant sur Enregistrer.

Après avoir enregistré les paramètres, le système vous invitera à poursuivre et vous devrez obtenir les métadonnées de votre connexion. Cela se présente comme ceci :

<EntityDescriptor entityID='urn:auth0:{ACCOUNT_NAME}:{CONNECTION_NAME}' xmlns='urn:oasis:names:tc:SAML:2.0:metadata'>
  <SPSSODescriptor WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'>

    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    <AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/login/callback?connection={CONNECTION_NAME}' index='0' isDefault='true'/>
  </SPSSODescriptor>
</EntityDescriptor>

Ces métadonnées de connexions vous appartiennent. Elles vous serviront à enregistrer un nouveau fournisseur de services, côté SSOCircle. Rendez-vous sur SSOCircle et accédez à la section Manage Metadata. Cliquez sur le bouton Add New Service Provider. Vous devez alors saisir le nom de domaine complet (FQDN), qui dans notre cas sera auth0.com. Sélectionnez EmailAddress dans les attributs envoyés dans la section Assertion. Pour terminer, collez les métadonnées XML dans la zone de texte prévue à cet effet. Cliquez sur Submit. Le fournisseur de service Auth0 (vous) sera enregistré.

Pour vérifier que la connexion a réussi, cliquez sur le bouton Manage sous la section SAMLP Identity Provider, puis sur Try (ou « Try » avec l'icône de lecture). Si tout s'est bien passé, un écran semblable à celui ci-dessous s'affiche. C'est terminé ! Vous avez maintenant intégré l'authentification unique (SSO) SAML à Auth0 en tant que fournisseur de service et SSOCircle en tant que fournisseur d'identifiants. Pour un guide plus complet sur la mise en œuvre d'une fédération SAML, consultez docs.

Que vous construisiez une appli mobile consommant des services RESTful, ou une appli SOAP d'entreprise, Auth0 vous offre tout ce dont vous avez besoin en matière d'authentification.

L'authentification JWT est le fer de lance de l'offre Auth0. Grâce à une vaste bibliothèque d'authentification et à des kits de développement de logiciels (SDK) pour de nombreux langages et frameworks de programmation, l'authentification est opérationnelle en quelques minutes. Grâce à la prise en charge de plus de 30 connexions aux réseaux sociaux, dont Facebook, Twitter et Google, avec la possibilité d'utiliser une base de données d'utilisateurs existante, le passage à Auth0 est un jeu d'enfant.

Auth0 peut faire office à la fois de fournisseur de services et de fournisseur d'identifiants dans une fédération basée sur SAML. Des applications, telles que Salesforce ou Box, peuvent utiliser Auth0 comme fournisseur d'identifiants et permettre à des utilisateurs de se connecter à ces services via Auth0. Lorsqu'il agit en tant que fournisseur de services, Auth0 envoie une demande d'autorisation à un fournisseur d'identifiants tel que SSOCircle, OneLogin ou tout autre fournisseur d'identifiants conforme à SAML.