🌐
developpement

REST

Style d'architecture pour les API web basees sur HTTP et les ressources.

Qu'est-ce que REST ?

REST (Representational State Transfer) est un style d'architecture pour la conception d'API web, defini par Roy Fielding dans sa these de doctorat en 2000. Ce n'est pas un protocole mais un ensemble de contraintes architecturales. Les API conformes a ces contraintes sont dites "RESTful". REST est devenu le standard de facto pour les API web, utilise par la majorite des services en ligne.

Les six contraintes REST

REST definit six contraintes : Client-serveur (separation des responsabilites front-end/back-end), Stateless (chaque requete contient toute l'information necessaire, le serveur ne garde pas d'etat de session), Cacheable (les reponses indiquent si elles peuvent etre mises en cache), Interface uniforme (identification des ressources par URI, manipulation via representations, messages auto-descriptifs, HATEOAS), Systeme en couches (le client ne sait pas s'il parle au serveur final ou a un intermediaire), et Code a la demande (optionnel, envoi de code executable).

Conception d'une API RESTful

Les ressources sont identifiees par des noms pluriels dans les URL : /users, /users/123, /users/123/orders. Les methodes HTTP definissent les actions : GET (lire), POST (creer), PUT (remplacer), PATCH (modifier partiellement), DELETE (supprimer). Les codes de statut HTTP communiquent le resultat : 200 (OK), 201 (Created), 204 (No Content), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 422 (Unprocessable Entity), 500 (Internal Server Error). Les reponses sont generalement en JSON.

Bonnes pratiques

Les bonnes pratiques incluent : la pagination des collections (cursor-based ou offset), le filtrage et le tri via les query parameters, le versioning de l'API (/v1/ ou via header), la documentation avec OpenAPI/Swagger, l'authentification par OAuth 2.0 ou JWT, le rate limiting avec les headers standards (X-RateLimit-*), et la gestion des erreurs avec un format standardise (RFC 7807 Problem Details).

REST vs alternatives

GraphQL resout le sur-fetching et sous-fetching de REST mais ajoute de la complexite. gRPC utilise Protocol Buffers pour des communications haute performance entre microservices. WebSocket fournit une communication bidirectionnelle en temps reel. En pratique, REST reste le choix par defaut pour les API publiques grace a sa simplicite, son ubiquite et l'excellent support du cache HTTP. Les architectures modernes combinent souvent plusieurs approches selon les besoins.

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

REST est-il encore pertinent avec GraphQL ?
Oui, REST reste le standard pour la majorite des API. GraphQL est plus adapte aux cas complexes avec des besoins de donnees variables.

Pages liees

Chaque semaine, le meilleur de la tech francaise

Tendances, salaires, outils et opportunites — directement dans votre boite mail.

Gratuit. Desabonnement en un clic. Pas de spam.