REST (Representational State Transfer) est un style architectural pour les applications en réseau, défini par Roy Fielding. Ce n'est pas un protocole ni un standard — c'est un ensemble de contraintes qui, lorsqu'on les respecte, rendent une API scalable, cacheable, et facile à faire évoluer. Une API « RESTful » modélise tout sous forme de ressources (users, orders, products) identifiées par des URI, et les manipule à l'aide des méthodes HTTP standard.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
L'URI /users/42 nomme la ressource ; GET est l'action ; JSON est la représentation. Cette combinaison — des noms dans le chemin, des verbes en tant que méthodes HTTP — est le cœur de REST.
REST est le style dominant pour les API web, donc les recruteurs utilisent cette question pour vérifier que vous comprenez pourquoi ça marche, pas seulement que vous savez l'épeler. Les deux contraintes qui comptent le plus en pratique sont le statelessness (chaque requête est autonome, vous pouvez donc placer un nombre quelconque de serveurs derrière un load balancer et scaler horizontalement sans sticky sessions) et l'uniform interface (des URL prévisibles et orientées ressource plus des méthodes HTTP et des status codes standard, ce qui signifie que les clients n'ont pas besoin de logique spécifique par endpoint). Une bonne réponse relie les contraintes à des bénéfices concrets — le statelessness permet le scaling, la cacheabilité réduit la charge, le layered system permet d'insérer des CDN et des gateways — et note que la plupart des API « REST » sont pragmatiques plutôt que pleinement RESTful (peu implémentent HATEOAS). Comprendre ces contraintes est le fondement de toute autre décision de conception REST, du choix des status codes au versioning.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don