Contraintes architecturales de l'API REST

Cette célèbre abréviation signifie « Representational State Transfer », un style d'architecture logicielle. Son utilisation la plus courante consiste à faciliter l'utilisation des services Web grâce à une approche standardisée et universelle.

Ces services Web proposent leurs ressources Web sous forme textuelle et permettent de les lire et de les traiter à l’aide d’un protocole sans état. Les opérations qu’un client peut effectuer sont prédéfinies et bien connues, généralement basées sur les protocoles HTTP.

Les API et les logiciels RESTful ne reposent pas sur une avancée technologique ou de programmation particulière. Ils ne sont même pas si récents, puisqu’ils ont été imaginés pour la première fois en 2000. L’idée derrière REST est d’imposer certaines règles à l’API afin d’obtenir plus de performances, d’évolutivité, de simplicité, de modifiabilité, de visibilité, de portabilité et de fiabilité.

Ce sont là de nombreux avantages, mais comment les API REST y parviennent-elles, vous demandez-vous peut-être ? C'est simple : en respectant six contraintes. En fait, ces règles constituent les caractéristiques les plus déterminantes du style architectural RESTful.

Le rôle d’une API est de connecter deux logiciels sans limiter leurs propres fonctionnalités. Cet objectif est l’une des contraintes fondamentales de REST : le client (qui effectue les requêtes) et le serveur (qui fournit les réponses) restent séparés et indépendants.

Lorsqu’elles sont correctement mises en œuvre, le client et le serveur peuvent évoluer dans des directions différentes sans que cela n’ait d’impact sur la qualité de leur échange de données. Ceci est particulièrement important dans divers cas où un serveur doit répondre aux besoins d’un grand nombre de clients différents. Prenons l’exemple des API météo : elles doivent envoyer des données à une multitude de clients différents (tous les types d’appareils mobiles en sont de bons exemples) à partir d’une seule base de données.

Pour qu'une API soit sans état, elle doit traiter les appels indépendamment les uns des autres. Chaque appel API doit contenir les données et les commandes nécessaires pour effectuer l'action souhaitée.

Un exemple d'API non sans état serait le cas où, au cours d'une session, seul le premier appel doit contenir la clé API, qui est ensuite stockée côté serveur. Les appels API suivants dépendent de ce premier appel, car il fournit les identifiants du client.

Dans le même cas, une API sans état garantira que chaque appel contient la clé API et que le serveur attendra une preuve d'accès à chaque fois.

Les API sans état présentent l'avantage qu'un appel incorrect ou ayant échoué n'entrave pas ceux qui suivent.

Alors que le client et le serveur évoluent de différentes manières, il est important que l'API puisse continuer à faciliter la communication. À cette fin, les API REST imposent une interface uniforme capable de s'adapter facilement à tous les logiciels connectés.

Dans la plupart des cas, cette interface repose sur les protocoles HTTP. Outre le fait qu'elle définit des règles quant à la manière dont les clients et le serveur peuvent interagir, elle présente également l'avantage d'être largement connue et utilisée sur Internet. Les données sont stockées et échangées via des fichiers JSON en raison de leur polyvalence.

Pour que l'API reste facile à comprendre et évolutive, l'architecture RESTful impose que la conception soit structurée en couches qui fonctionnent ensemble.

Grâce à une hiérarchie claire de ces couches, l'exécution d'une commande signifie que chaque couche remplit sa fonction puis transmet les données à la suivante. Les couches connectées communiquent entre elles, mais pas avec tous les composants du programme. De cette manière, la sécurité globale de l'API est également renforcée.

Si le périmètre de l'API change, des couches peuvent être ajoutées, modifiées ou supprimées sans compromettre les autres composants de l'interface.

Il n’est pas rare que les requêtes d’une API sans état génèrent une charge importante. Dans certains cas, cela est inévitable, mais pour les requêtes répétées nécessitant les mêmes données, la mise en cache de ces informations peut faire une énorme différence.

Le concept est simple : le client a la possibilité de stocker localement certaines données pendant une période prédéterminée. Lorsqu’il effectue une requête pour ces données, au lieu que le serveur les renvoie, il utilise la version stockée.

Le résultat est simple : au lieu d'envoyer plusieurs requêtes complexes ou coûteuses en peu de temps, le client n'a à le faire qu'une seule fois.

Contrairement aux autres contraintes dont nous avons parlé jusqu'à présent, la dernière est facultative. La raison pour laquelle le « code à la demande » est facultatif est simple : cela peut représenter un risque de sécurité important.

Le concept consiste à permettre l'envoi de code ou d'applets via l'API pour qu'ils soient utilisés par l'application. Comme vous pouvez l'imaginer, un code inconnu provenant d'une source douteuse pourrait causer des dommages ; il est donc préférable de réserver cette contrainte aux API internes, où vous avez moins à craindre des pirates informatiques et des personnes mal intentionnées. Un autre inconvénient est que le code doit être rédigé dans le langage de programmation approprié pour l'application, ce qui n'est pas toujours le cas.

L'avantage est que le « code à la demande » peut aider le client à implémenter ses propres fonctionnalités à la volée, avec moins de travail nécessaire sur l'API ou le serveur. En substance, cela permet à l'ensemble du système d'être beaucoup plus évolutif et agile.

La conception RESTful met l'accent sur l'efficacité et l'évolutivité dans un monde dominé par le Web. Comme vous pouvez l'imaginer, cela a rendu cette architecture très populaire, et nous la verrons très probablement se généraliser encore davantage dans les années à venir.

La principale préoccupation de nombreux développeurs et experts en sécurité est le risque d’exploitation des API Web si elles sont créées sans le soin nécessaire. Bien sûr, les pirates informatiques ont toujours été et continueront d’être un problème pour les API et les logiciels en général. Mais ce n’est pas pour autant que nous allons cesser de les utiliser. C’est plutôt aux experts en sécurité de trouver de nouveaux moyens de protéger nos programmes.

C'est cette façon de penser, associée à l'objectif de faciliter la vie des développeurs, qui nous a amenés à développer WebScrapingAPI, une API REST d'extraction de données qui gère tout, de la rotation des proxys au rendu Javascript en passant par la résolution des CAPTCHA. Découvrez-la pour voir ce qu'une API REST peut faire !