La premiere fois que j'ai entendu parler d'API REST en cours, le concept m'a semble abstrait. Une interface qui expose des donnees via HTTP, avec des verbes comme GET, POST, PUT, DELETE. On nous a montre des exemples, on a fait des requetes avec Postman, on a consomme des endpoints. J'ai compris la mecanique assez rapidement.
Ce qui a pris plus de temps, c'est de comprendre pourquoi REST est concu comme il l'est. Le principe de statelessness, par exemple : chaque requete doit contenir toutes les informations necessaires a son traitement, sans que le serveur conserve un etat entre deux appels. En TP, on applique la regle sans necessairement en saisir l'implication en termes d'architecture.
La conception des routes, aussi, est quelque chose que les TP ont aborde de facon mecanique. GET /users pour lister, POST /users pour creer, GET /users/:id pour un seul. C'est logique, mais les questions plus subtiles, comme comment nommer des actions qui ne rentrent pas dans ce modele CRUD, sont rarement traitees en formation.
C'est en construisant la partie API de mon portfolio que ces questions sont devenues concretes. Comment exposer des donnees de maniere coherente ? Comment gerer la versioning d'une API si elle evolue ? Comment documenter les endpoints de facon utile ? Des problemes que Postman en TP ne pose pas, parce que tout est deja defini.
Les API REST m'ont aussi introduit a la notion de contrat entre un front-end et un back-end. Le format de la reponse JSON, les codes HTTP retournes, la gestion des erreurs : tout ca constitue une interface que d'autres developpeurs vont consommer. Ecrire une API, c'est ecrire de la documentation autant que du code.
Ce que je retiens de cette decouverte progressive : les TP donnent une base solide sur les mecanismes. C'est en construisant quelque chose de reel qu'on commence a se poser les questions de conception. Les deux etapes sont necessaires, et aucune ne remplace l'autre.