Introduction à l’architecture REST

REST est un acronyme pour Representational State Transfer. Il s’agit d’un style d’architecture inventé par Roy Fielding en 2000 et qui est désormais très répendu dans le monde des API web.

Une des propriété de cette architecture est qu’elle est stateless (sans état), ce qui signifie que la réponse du serveur à une requête ne dépend pas d’un contexte conservé par le serveur. Autrement dit, la même requête envoyée par différents clients retournera toujours la même réponse, indépendamment du client. Ceci implique donc que chaque requête doit contenir toutes les informations. Prenons par exemple le cas d’une API retournant les informations de son propre utilisateur sur une application web. Dans une architecture non-REST on pourrait avoir:

 GET /users

Les informations retournées dépenderait de la session de l’utilisateur. On est par conséquent pas stateless, on dépent d’une session enregistrée sur le serveur. Pour être REST, il faudrait plutôt avoir:

 GET /users/42

où 42 correspond à notre ID utilisateur. Dans ce cas, notre requête ne dépend plus de la session de l’utilisateur courrant. A noter, que cela n’exempt pas le serveur de refuser l’accès à un utilisateur n’ayant pas les droits d’accéder à la ressource.

L’aspect sémantique et représentationnelle de REST sont également des points très important de cette architecture. En effet, l’API doit utiliser les méchanismes, tels que HTTP verbs et des HTTP Status Codes, offerts par le protocol HTTP et utilisé afin de renforcer la sémantique des échanges client-serveur. La manipulation des ressources, quant à elle, doit se faire à travers des représentations bien définies. Voici un exemple d’une API web pour accéder et manipuler les utilisateurs d’une application web:

HTTP Verb

Path

Description

Status Code

GET

/users

Liste tous les utilisateurs

200 – Succès

404 – Ressource n’existe pas

GET

/users/{id}

Récupère l’utilisateur ayant un certain ID

200 – Succès

404 – L’utilisateur avec cet ID n’existe pas

POST

/users

Créé un nouvel utilisateur

201 – Créé avec succès

400 – Les données fournies sont invalides

409 – Conflit (e.g. duplication)

PUT

/users/{id}

Met à jour un utilisateur ayant un certain ID.

200 – Succès

400 – Les données fournies sont invalides

404 – L’utilisateur avec cet ID n’existe pas

409 – Conflit (données dans un état invalide)

DELETE

/users/{id}

Supprime un utilisateur ayant un certain id.

200 – Succès

404 – L’utilisateur avec cet ID n’existe pas

Comme on peut le voir dans le tableau ci-dessus, le verbe HTTP utilisé défini l’opération à effectuer sur notre ressource « users », alors que le chemin (path) identifie la ressource.

Bien entendu, il ne s’agit que d’une API possible. Les statuts d’erreurs peuvent varier ou il peut aussi y avoir d’autres méthodes comme PATCH pour mettre à jour une partie de l’objet et non tout l’objet comme avec PUT.

Laisser un commentaire