API REST

Style d'interface web qui expose des ressources identifiées par des URL, manipulées via les verbes HTTP (GET, POST, PUT, DELETE) et des représentations comme JSON.

En clair

REST est un style d'architecture pour les interfaces web. L'idée centrale : tout est une ressource (un utilisateur, une commande, un produit) identifiée par une URL. On agit dessus avec les verbes HTTP standard : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. Les échanges utilisent en général le format JSON, et chaque requête est autonome : le serveur ne conserve pas d'état de session entre deux appels (principe « stateless »). Les URL suivent une logique hiérarchique et lisible, par exemple une collection au pluriel (« /commandes ») et une ressource précise par son identifiant (« /commandes/42 »), ce qui rend l'API explorable presque sans documentation.

Pourquoi c'est utilisé

REST s'appuie sur HTTP, donc sur une infrastructure universelle et bien outillée : caches, proxys, codes de statut, authentification. Les conventions sont largement partagées, ce qui rend les API prévisibles et faciles à intégrer pour n'importe quel client (navigateur, mobile, autre service). La simplicité et l'ubiquité en font le choix par défaut pour exposer une fonctionnalité au reste du système d'information. L'absence d'état côté serveur facilite aussi la mise à l'échelle horizontale : n'importe quelle instance peut traiter n'importe quelle requête, sans session partagée. Les verbes HTTP portent enfin une sémantique utile, GET et PUT étant idempotents, ce qui simplifie les reprises sur erreur.

En mission / dans la pratique

Un consultant consomme et expose des API REST en permanence : il intègre un service partenaire, construit une API pour un front, ou connecte deux applications internes. Le quotidien tourne autour de la définition des routes, de la gestion des codes de statut, de la pagination, de la documentation (souvent OpenAPI) et de l'authentification par jeton. Respecter les conventions de l'écosystème client est essentiel pour une intégration durable. Une bonne partie du travail consiste aussi à lire et interpréter la documentation d'une API tierce, puis à gérer proprement ses erreurs, ses quotas et ses limites de débit. Disposer d'une spécification OpenAPI à jour permet de générer du code client et d'aligner front et back sur un contrat unique.

Pièges & bonnes pratiques

Évitez les verbes dans les URL (« /getUser ») : l'URL nomme la ressource, le verbe HTTP exprime l'action. Renvoyez des codes de statut justes, paginez les listes, versionnez l'API et documentez-la. Attention au « chatty client » qui multiplie les appels : prévoyez les bons niveaux de granularité et un cache côté client ou serveur. Distinguez bien les familles de codes de statut (succès, erreur du client, erreur du serveur) pour que l'appelant sache s'il doit corriger sa requête ou réessayer plus tard. Prévoyez enfin une stratégie de compatibilité ascendante : ajouter un champ ne doit pas casser les clients existants.

À ne pas confondre

À distinguer de GraphQL, qui interroge un schéma unique plutôt que des ressources multiples. À ne pas confondre non plus avec le webhook, où c'est le serveur qui appelle le client. Une API se livre avec un SDK pour en faciliter la consommation.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté