Introduction à l’architecture REST

Bienvenue dans les concepts fondamentaux des services web modernes. Representational State Transfer, universellement connu sous le nom de REST, est un style architectural qui définit un ensemble de contraintes à utiliser pour créer des services web. Développé par Roy Fielding dans sa thèse de doctorat, REST n’est ni une norme ni un protocole, mais plutôt une philosophie de conception de haut niveau. Il fournit une manière standardisée pour les systèmes informatiques de communiquer sur Internet, en permettant à différentes applications de se comprendre de manière fluide. En respectant les principes REST, les développeurs peuvent créer des systèmes évolutifs, résilients et faciles à maintenir au fil du temps.

Au cœur de ce style architectural se trouve le principe selon lequel tout est une ressource. Une ressource peut être n’importe quelle information ou entité de données avec laquelle un client pourrait vouloir interagir, comme une fiche client, un article de blog ou une transaction financière. REST impose que les systèmes communiquent sans état, en s’appuyant sur l’infrastructure robuste et éprouvée du web. Cela signifie qu’ils exploitent les protocoles Internet standard, presque exclusivement le Hypertext Transfer Protocol, pour transmettre des données entre le client qui demande l’information et le serveur qui l’héberge.

Comprendre REST nécessite de changer de perspective : il faut passer d’une réflexion centrée sur les actions à une réflexion centrée sur les objets. Dans les anciennes architectures d’appel de procédures distantes, les systèmes communiquaient en s’indiquant mutuellement quelles fonctions exécuter. Dans une architecture RESTful, les systèmes communiquent en transférant des représentations de l’état actuel d’une ressource. Lorsqu’un client demande une ressource, le serveur répond avec une charge utile représentant cette ressource à cet instant précis, dans un format universellement compris tel que JavaScript Object Notation ou Extensible Markup Language.

Le concept des ressources et des URI

Comme REST s’articule autour des ressources, il est essentiel de les identifier avec précision et de manière cohérente. Dans l’architecture REST, chaque ressource se voit attribuer un Uniform Resource Identifier, qui sert d’adresse unique sur le web. Cet identifiant doit être logique, hiérarchique et facile à comprendre pour les développeurs. Une structure d’adresses bien conçue permet aux utilisateurs de votre interface de programmation d’application de prévoir où trouver les données associées sans devoir mémoriser une documentation complexe.

La bonne pratique standard du secteur consiste à utiliser des noms au pluriel pour nommer ces ressources. Au lieu d’utiliser des verbes dans l’adresse pour décrire une action, l’adresse doit uniquement décrire l’entité elle-même. Par exemple, si vous construisez une interface destinée à gérer les fiches des employés, votre adresse de base doit simplement être /employees. Cette approche fondée sur les noms conserve une adresse claire et met entièrement l’accent sur le sujet des données plutôt que sur l’opération effectuée. L’utilisation de verbes comme /get-employees ou /create-employee constitue une violation fondamentale des principes de conception REST.

Lorsqu’un client doit interagir avec une ressource unique et spécifique plutôt qu’avec une collection de ressources, des identifiants uniques sont ajoutés au chemin de l’adresse. Si le client souhaite accéder à la fiche d’un employé dont le numéro d’identification dans la base de données est 42, l’adresse appropriée devient /employees/42. Cette structure hiérarchique peut être étendue pour représenter les relations entre différents types de ressources. Si vous devez consulter les relevés de paie de cet employé précis, l’adresse devient logiquement /employees/42/payrolls.

Les méthodes HTTP standard dans REST

Alors que l’identifiant uniforme de ressource fournit l’adresse des données, la méthode HTTP fournit l’action. REST exploite les méthodes standard intégrées au protocole de transfert hypertexte pour indiquer au serveur quelle opération exécuter sur la ressource ciblée. Cette séparation entre l’adresse et l’action rend les interfaces RESTful particulièrement prévisibles. Les quatre méthodes les plus courantes que vous utiliserez au quotidien sont GET, POST, PUT et DELETE.

La méthode GET est conçue exclusivement pour récupérer des informations. Lorsqu’un client envoie une requête GET, il demande au serveur de renvoyer une représentation de la ressource sans la modifier de quelque manière que ce soit. Cette méthode est définie comme étant à la fois sûre et idempotente. Une méthode sûre ne modifie pas l’état du serveur, tandis qu’une méthode idempotente garantit que l’envoi exactement identique d’une requête dix fois produira exactement le même résultat sur le serveur que son envoi une seule fois. Vous pouvez considérer une requête GET comme une simple lecture de document.

La méthode POST est utilisée pour créer de nouvelles ressources sur le serveur. Lorsqu’un client envoie une requête POST à l’adresse d’une collection, celle-ci contient une charge utile avec les données de la nouvelle entité. Contrairement à la méthode GET, POST n’est ni sûre ni idempotente. Envoyer plusieurs fois une requête POST identique entraînera la création de plusieurs ressources distinctes sur le serveur. Le serveur traite la charge utile, génère un identifiant unique pour la nouvelle ressource et l’enregistre dans la base de données.

Pour modifier des ressources existantes, les développeurs s’appuient sur les méthodes PUT et DELETE. La méthode PUT met à jour une ressource en remplaçant complètement son état actuel par le nouvel état fourni dans la charge utile de la requête. Si la ressource n’existe pas, une requête PUT peut éventuellement la créer, même si cette méthode est généralement utilisée pour les mises à jour complètes. La méthode DELETE, comme son nom l’indique, demande au serveur de supprimer définitivement la ressource spécifiée. PUT et DELETE sont toutes deux conçues pour être idempotentes : l’envoi de plusieurs requêtes identiques visant à mettre à jour ou à supprimer une même ressource spécifique doit laisser le système exactement dans le même état qu’après la première requête.

Mise en correspondance des opérations avec la logique métier

En ingénierie logicielle, les opérations fondamentales nécessaires au stockage persistant sont Create, Read, Update et Delete. REST établit une correspondance directe entre ces opérations de base de données et les méthodes HTTP que nous venons d’étudier. Create correspond parfaitement à POST, Read se mappe exactement sur GET, Update est associé à PUT et Delete correspond à la méthode DELETE. Cette correspondance standardisée signifie qu’une fois qu’un développeur comprend le modèle de données sous-jacent, il sait intuitivement comment interagir avec l’interface.

Prenons un scénario métier concret dans lequel vous développez un système de gestion des stocks pour une librairie. La ressource centrale de ce système est un livre. Lorsqu’un éditeur publie un nouveau roman, le gestionnaire des stocks doit l’ajouter au système. L’application cliente rassemble les informations du livre, telles que le titre, l’auteur et le prix, puis les envoie dans une requête POST ciblant l’adresse /books. Le serveur reçoit ces données, crée l’enregistrement et renvoie généralement le numéro d’identification nouvellement attribué.

Plus tard, un employé remarque que le prix d’un livre donné a été saisi incorrectement. Pour corriger cette erreur, l’application cliente envoie une requête PUT à l’adresse de la ressource concernée, par exemple /books/892. La charge utile de cette requête contient l’ensemble des informations corrigées du livre. Le serveur localise le livre correspondant à cet identifiant et remplace ses données existantes par les données corrigées. Si le livre est épuisé et doit être entièrement retiré du catalogue actif, le client envoie une requête DELETE à cette même adresse spécifique.

Absence d’état et réponses du serveur

L’une des contraintes les plus importantes de REST est que toutes les interactions entre le client et le serveur doivent être complètement dépourvues d’état. Cela signifie que le serveur n’est pas autorisé à conserver d’informations sur la session du client entre deux requêtes. Chaque requête initiée par le client doit contenir tout le contexte, les identifiants d’authentification et les données nécessaires au serveur pour comprendre l’opération et y répondre. Le serveur traite chaque requête entrante comme une transaction entièrement indépendante, sans avoir connaissance des requêtes qui l’ont précédée.

Cette absence d’état stricte confère aux architectures REST leur très grande capacité de mise à l’échelle. Comme le serveur n’a pas besoin d’allouer de la mémoire pour suivre les sessions utilisateur, il libère d’importantes ressources de calcul. En outre, dans les grands systèmes distribués placés derrière un équilibreur de charge, n’importe quel serveur d’un vaste cluster peut traiter n’importe quelle requête provenant de n’importe quel client. Si un serveur tombe en panne, un autre peut immédiatement prendre le relais sans que l’utilisateur perde les données de sa session, puisque celles-ci résident entièrement côté client.

Pour communiquer le résultat de ces transactions indépendantes, le serveur utilise les codes d’état HTTP standard. Ces nombres à trois chiffres indiquent immédiatement au client si l’opération a réussi ou échoué. Les codes de la série deux cents indiquent une réussite, comme deux cents OK ou deux cent un Created. Les codes de la série quatre cents indiquent une erreur du client, ce qui signifie que la requête était mal formée ou que le client a demandé une ressource qui n’existe pas. Enfin, les codes de la série cinq cents signalent que le serveur a rencontré une erreur inattendue en tentant de traiter une requête client parfaitement valide.

Erreurs courantes dans la conception REST

Malgré l’adoption généralisée de REST, les développeurs commettent fréquemment des erreurs de conception qui enfreignent ses principes fondamentaux. L’erreur la plus courante consiste à retomber dans les habitudes des appels de procédure distants en injectant des verbes dans les adresses des ressources. Des adresses telles que /add-book ou /update-user détruisent l’uniformité de l’interface. La méthode HTTP décrit déjà l’action ; ajouter un verbe à l’adresse crée donc une redondance et de la confusion. L’adresse doit strictement identifier le nom, tandis que la méthode HTTP prend en charge le verbe.

Une autre erreur grave consiste à utiliser à mauvais escient la méthode GET pour modifier ou supprimer des données. Il arrive que des développeurs créent des adresses telles que /users/5/delete et demandent aux clients d’y accéder via une requête GET. C’est extrêmement dangereux, car l’infrastructure web standard considère les requêtes GET comme des opérations sans effet de bord. Les navigateurs web les préchargent, les serveurs de mise en cache les dupliquent et les robots des moteurs de recherche les indexent automatiquement. Si une requête GET déclenche une suppression, un simple robot explorant votre site pourrait accidentellement effacer l’intégralité de votre base de données.

Enfin, une pluralisation incohérente crée des difficultés pour les développeurs qui utilisent l’interface. Si l’adresse permettant de récupérer tous les utilisateurs est au pluriel, /users, mais que celle permettant de récupérer un compte est au singulier, /account, l’utilisateur doit constamment consulter la documentation pour se rappeler l’orthographe. La norme communément admise dans le secteur consiste à utiliser exclusivement des noms pluriels pour toutes les collections et toutes les ressources individuelles. La cohérence est la marque d’une interface REST bien conçue, qui reste ainsi intuitive et facile à intégrer sur le long terme.