Les 5 styles d'API les plus populaires et ce qui les distingue

En ce qui concerne les cas d'utilisation, il convient de mentionner que les API peuvent être publiques, accessibles aux partenaires ou entièrement internes. Ce premier facteur de différenciation définit la norme pour bon nombre des caractéristiques et fonctionnalités qui devront être développées : comment les données sont stockées et partagées, comment les identifiants sont gérés, quel volume de trafic l'API doit supporter, etc.

Comme vous le verrez, les styles d'architecture suivants peuvent être utilisés dans n'importe lequel de ces trois cas, mais certaines combinaisons sont plus pertinentes que d'autres.

Ce sont de loin les API les plus courantes aujourd'hui, et c'est également le style que nous avons utilisé pour développer WebScrapingAPI. L'acronyme signifie REpresentational State Transfer, et ce style implique que si vous, en tant que client, effectuez une requête, l'API renverra une représentation de l'état de la ressource que vous avez demandée.

Les API RESTful s'appuient fortement sur l'infrastructure HTTP. Étant donné que le Web utilise principalement HTTP, les API REST ont déjà un avantage car elles sont faciles à comprendre, à intégrer et à utiliser.

Ce style est également défini par un ensemble de contraintes que l'API doit respecter. Bien que cela puisse sembler fastidieux au premier abord, ces contraintes garantissent que l'API se comporte de manière prévisible et utile. Il y en a six au total, et elles sont les suivantes :

• Interface uniforme
• Sans état
• Mémorisable
• Client-serveur
• Système en couches
• Code à la demande

Nous avons publié un article complet sur ces contraintes sur Medium, alors n'hésitez pas à le consulter pour en savoir plus sur les API REST.

Si une API respecte certaines de ces contraintes mais pas toutes, on peut la qualifier de « de type REST ». Dans certains cas d'utilisation, ces contraintes peuvent causer plus de problèmes qu'elles n'apportent d'avantages, ce qui explique pourquoi vous pourriez rencontrer des adoptions partielles de ce style.

SOAP, ou Simple Object Access Protocol, repose largement sur le XML. Pour l'utiliser, vous devez respecter des normes strictes concernant la structure des messages, les règles d'encodage et le traitement des requêtes et des réponses.

Bien que très précises et complètes, les API SOAP peuvent être plus difficiles à maîtriser en raison de leur langage de balisage. Les requêtes et les réponses peuvent devenir assez longues et complexes, ce qui rend leur saisie manuelle fastidieuse.

Du côté positif, ce style présente l'avantage d'une gestion des erreurs intégrée. Si vous rencontrez un problème avec la requête, la réponse contiendra de nombreuses informations précieuses qui vous aideront à identifier et à corriger l'erreur.

Ce style est utilisé pour interroger des bases de données à partir d'applications côté client via HTTP. Mais, au lieu d'envoyer plusieurs requêtes HTTP vers différents points de terminaison, vous pouvez envoyer une seule requête POST pour tout ce dont vous avez besoin. En substance, le client décrit ce dont il a besoin une seule fois, et l'API fait de son mieux pour récupérer ces données.

Un serveur fonctionnant sous l'architecture GraphLQ dispose d'un modèle (ou schéma) prédéfini pour les données pouvant être demandées. Ainsi, lorsque vous effectuez une requête, le schéma sert de ligne directrice sur ce que vous pouvez demander, comment les informations doivent être structurées et comment vous pouvez interagir avec le serveur.

L'avantage de ce système est que les utilisateurs savent clairement ce qu'ils peuvent obtenir, ce qui rend très improbable l'obtention de données erronées ou l'apparition d'une erreur. Le principe sous-jacent est de placer le client au premier plan et de lui offrir la meilleure expérience possible.

À l'instar de GraphLQ, les API Falcor créent un fichier JSON virtuel qui sert de conteneur pour les données qu'un client recevra après une requête. Ce fichier virtuel peut être enrichi à chaque nouvelle donnée dont le client a besoin. Bien que cela soit pratique, le fichier peut devenir assez volumineux avec le temps.

Heureusement, vous n’avez pas besoin de récupérer l’intégralité du fichier JSON à chaque requête. Vous pouvez plutôt spécifier les parties dont vous avez besoin à tout moment et les obtenir dans la réponse. Cela fonctionne car le fichier JSON est publié sous une URL et renvoie vers différentes ressources dans le backend. En substance, vous pouvez parcourir le fichier virtuel pour trouver les données que vous souhaitez.

Cette couche virtuelle entre le client et le serveur permet de relier les deux tout en conservant leurs architectures totalement indépendantes.

Lorsque vous avez peu de contraintes à prendre en compte, gRPC devrait être l’une de vos premières options lors de la conception d’une API. Il est indépendant du langage et de la plateforme, et assez rapide grâce à l’utilisation de Protocol Buffers (protobufs) pour sérialiser les données en flux binaires. Ces données sont ensuite transférées via HTTP/2.

gRPC est bien adapté aux systèmes distribués. L'aspect le plus important de ce style réside dans les procédures. Vous pouvez les exécuter sur la machine locale et sur des appareils distants. Dans les deux cas, l'appel d'une procédure est rapide et simple.

L'une des raisons pour lesquelles les API gagnent en popularité réside dans les avantages que présentent les microservices par rapport au modèle logiciel classique à service unique. Ainsi, chaque fonctionnalité/microservice peut être conçue, développée et mise à jour séparément sans compromettre les autres composants. En ce sens, gRPC est une excellente solution pour relier le tout.

De plus, comme vous pouvez lancer une procédure à distance, cette solution est également bien adaptée pour connecter des appareils mobiles à des services backend.

Bien que cet article vous ait donné un aperçu des styles d'architecture d'API les plus courants, cela ne suffit pas pour garantir que vous choisissiez la bonne. Il était essentiel pour nous, en tant qu'équipe, d'avoir une expérience concrète et directe avec autant d'exemples que possible.

Par expérience, j’entends à la fois en tant qu’utilisateur et en tant que développeur. Après tout, il existe peut-être un style qui vous est plus familier, et qui serait donc plus facile à mettre en œuvre, mais vous devez vous mettre à la place de l’utilisateur final et voir comment cela fonctionne pour lui.

Un style n’est pas quelque chose que l’on peut simplement choisir en cours de développement ou changer par la suite. C’est un ensemble de règles qui dicte la forme que prendra l’API. En tant que tel, c’est une décision importante.

Une première étape consiste à lire la documentation des API déjà disponibles sur le marché et, idéalement, à les tester. Une expérience préalable dans la création d'API serait également un atout majeur.

Si vous souhaitez découvrir comment nous avons fait de WebScrapingAPI la puissance de scraping web qu’elle est aujourd’hui, pourquoi ne pas consulter notre documentation ? Toutes ses fonctionnalités actuelles n’étaient d’ailleurs pas présentes lors de son lancement. Des options telles que le scraping des points de terminaison REST API ou des fichiers ont été ajoutées à la demande de nos utilisateurs. N’oubliez donc pas : le style architectural est là pour vous donner une direction, mais c’est à vous de façonner l’API pour en faire un outil que les utilisateurs adoreront.