REST en langage simple
Une API REST expose des donnees et des actions sous forme de ressources accessibles via des URLs. Le verbe HTTP choisit (GET, POST, PATCH, DELETE) indique ce que l'on veut faire. L'idee est d'utiliser les regles du web plutot que d'inventer un protocole.
Cette approche rend l'API plus facile a comprendre et a integrer. Les developpeurs peuvent souvent deviner le comportement d'un endpoint car il suit les conventions du web.
Les ressources sont le modele de base
En REST, tout objet significatif devient une ressource : utilisateur, appareil, commande, log. Chaque ressource a une URL stable, par exemple `/users/123`.
Une ressource n'est pas forcement une ligne de base de donnees. Elle peut etre un rapport, une vue, un etat. L'important est son identite claire.
Les verbes HTTP donnent l'action
REST utilise les verbes HTTP : GET lit, POST cree, PUT remplace, PATCH modifie, DELETE supprime. Ces verbes sont compris par les caches, proxies et outils.
Evitez d'inclure l'action dans l'URL (`/users/123/delete`). L'action est le verbe : `DELETE /users/123`.
Stateless : des requetes autonomes
Le stateless signifie que le serveur ne garde pas de session cachee. Chaque requete contient ce qu'il faut pour etre traitee. Cela facilite le scaling et evite les incoherences.
Le client peut garder un etat (tokens, cache), mais le serveur ne doit pas en dependre.
Representation et ressource
Une ressource peut avoir plusieurs representations. Aujourd'hui JSON, demain un autre format. L'identite reste stable.
Une bonne API ne reflète pas directement la base de donnees. Elle expose une representation pensee pour l'usage.
La coherence prime
REST est puissant car il est coherent. Si chaque ressource suit la meme logique, l'integration devient rapide et fiable.
Evitez les exceptions. Quelques exceptions deviennent vite un systeme confus.
REST dans la vraie vie
Beaucoup d'APIs sont pragmatiques. Elles utilisent parfois POST pour des recherches ou des actions complexes. C'est acceptable si c'est documente.
Le point cle est la clarte : un utilisateur doit comprendre ce qu'il se passe sans deviner.
Exemple rapide
Imaginez une API domotique : `/devices`, `/devices/42`, `/devices/42/state`. GET lit, PATCH modifie. Simple et intuitif.
C'est cela l'interet de REST : permettre a un client de deviner les endpoints sans doc interminable.
Quand REST n'est pas ideal
Certaines situations se pretent mal a REST : streaming temps reel, commandes complexes, collaboration live. Dans ce cas, WebSockets, event streaming ou RPC sont plus adaptes.
REST est un excellent default, mais pas une regle absolue.
Checklist mentale simple
Si vous pouvez nommer clairement les objets et les traiter comme des ressources, REST est un bon choix. Si votre API ressemble a une suite de commandes, RPC est peut-etre plus naturel.
Beaucoup d'equipes commencent par REST et ajoutent d'autres styles plus tard.