Qu’est-ce qu’une API REST ?

Défini en 2000 par l'informaticien Roy Fielding dans sa thèse de doctorat, REST offre aux développeurs un niveau relativement élevé de flexibilité, de cohérence, d'évolutivité et d'efficacité. Les API REST constituent un moyen léger de créer des API web et sont couramment utilisées pour faciliter l'échange de données entre les applications, les services web et les bases de données, ainsi que pour connecter les composants dans les architectures microservices.

Au niveau le plus élémentaire, une API est un mécanisme qui permet à une application ou à un service d’accéder à une ressource au sein d’une autre application, d’un autre service ou d’une autre base de données. L’application ou le service qui accède aux ressources est le client, et l’application ou le service qui contient la ressource est le serveur. Certaines API, telles que SOAP ou XML-RPC, imposent un cadre d’exigences strict aux développeurs. Mais les développeurs peuvent mettre au point des API REST en utilisant pratiquement n’importe quel langage de programmation, ces API pouvant prendre en charge une grande variété de formats de données. La seule exigence est de respecter les six principes de conception REST suivants, également appelés contraintes architecturales.

Toutes les demandes d’API pour une même ressource doivent avoir la même apparence, quelle que soit la provenance de la demande. L’API REST doit garantir que le même élément de données, tel que le nom ou l’adresse e-mail d’un utilisateur, n’appartient qu’à un seul identifiant de ressource uniforme (URI). Les ressources ne doivent pas être trop volumineuses, mais doivent contenir toutes les informations dont le client pourrait avoir besoin.

Dans la conception d’API REST, les applications client et serveur doivent être complètement distinctes. La seule information que l’application cliente doit connaître est l’URI de la ressource demandée ; elle ne peut pas interagir avec l’application serveur d’une autre manière. De même, une application serveur ne doit pas modifier l’application cliente autrement qu’en lui transmettant les données demandées via HTTP.

Les API REST sont apatrides, ce qui signifie que chaque requête doit inclure toutes les informations nécessaires à son traitement. En d’autres termes, les API REST ne nécessitent aucune session côté serveur. Les applications serveur ne sont pas autorisées à stocker des données liées à une demande client.

Dans la mesure du possible, les ressources doivent pouvoir être mises en cache côté client ou serveur. Les réponses du serveur doivent également contenir des informations indiquant si la mise en cache est autorisée pour la ressource fournie. L’objectif est d’améliorer les performances côté client, tout en augmentant l’évolutivité côté serveur.

Dans les API REST, les appels et les réponses passent par différentes couches. En règle générale, il ne faut pas supposer que les applications client et serveur se connectent directement l’une à l’autre. Il peut y avoir un certain nombre d’intermédiaires différents dans la boucle de communication. Les API REST doivent être conçues de manière à ce que ni le client ni le serveur ne puissent dire s’ils communiquent avec l’application finale ou avec un intermédiaire.

Les API REST envoient généralement des ressources statiques, mais dans certains cas, les réponses peuvent également contenir du code exécutable (comme les applets Java). Dans ce cas, le code ne doit être exécuté qu’à la demande.

Les API REST communiquent via des requêtes HTTP pour exécuter des fonctions de base de données standard telles que la création, la lecture, la mise à jour et la suppression d’enregistrements (également appelées CRUD) au sein d’une ressource.

Par exemple, une API REST utilise une requête GET pour récupérer un enregistrement. Une requête POST crée un nouvel enregistrement. Une requête PUT met à jour un enregistrement et une requête DELETE en supprime un. Toutes les méthodes HTTP peuvent être utilisées dans les appels API. Une API REST bien conçue est similaire à un site Web exécuté dans un navigateur Web avec une fonctionnalité HTTP intégrée.

L’état d’une ressource à un instant donné, ou horodatage, est connu sous le nom de représentation de la ressource. Ces informations peuvent être fournies à un client dans pratiquement n’importe quel format, y compris JavaScript Object Notation (JSON), HTML, XLT, Python, PHP ou texte brut. JSON est populaire, car il est lisible à la fois par les humains et les machines, et il ne dépend pas d’un langage de programmation.

Les en-têtes et paramètres de requête sont également importants dans les appels d’API REST, car ils contiennent des informations d’identification importantes telles que les métadonnées, les autorisations, les identifiants de ressources uniformes (URI), la mise en cache, les cookies, etc. Les en-têtes de requête et de réponse, ainsi que les codes d’état HTTP conventionnels, sont utilisés dans des API REST bien conçues.

GraphQL et API REST : quelle est la différence ?

Bien que la flexibilité soit un grand avantage de la conception d’API REST, cette même flexibilité facilite la conception d’une API défaillante ou peu performante. C’est pourquoi les développeurs professionnels partagent les bonnes pratiques en matière de spécifications d’API REST.

La spécification OpenAPI (OAS) établit une interface pour décrire une API de manière à permettre à tout développeur ou à toute application de la découvrir et de comprendre pleinement ses paramètres et ses capacités. Ces informations comprennent les points de terminaison disponibles, les opérations autorisées sur chaque point de terminaison, les paramètres d’opération, les méthodes d’authentification, etc. La dernière version, OAS3, comprend des outils pratiques, tels que le générateur OpenAPI, qui permettent de générer des clients API et des stubs de serveur dans différents langages de programmation.

La sécurisation d’une API REST commence également par le respect des bonnes pratiques du secteur. Utilisez des algorithmes de hachage pour sécuriser les mots de passe et le protocole HTTPS pour sécuriser la transmission des données. Un cadre d’autorisation comme OAuth 2.0peut permettre de limiter les privilèges des applications tierces.

En utilisant un horodatage dans l’en-tête HTTP, une API peut également rejeter toute requête arrivant après un certain laps de temps. La validation des paramètres et les jetons Web JSON sont d’autres moyens de s’assurer que seuls les clients autorisés peuvent accéder à l’API.