REST

Le protocole qui a révolutionné les APIs ! 🚀

🎧 Écoutez l’histoire
⏳ Chargement...

Si t’es dev depuis un moment, t’as forcément déjà bossé avec REST. Et si c’est pas le cas… ben, t’as quand même bossé avec REST, t’en as juste pas conscience. 😅

Début des années 2000, un gars du nom de Roy Fielding balance une idée qui va transformer le monde des API : pourquoi se prendre la tête avec des protocoles complexes (coucou SOAP et XML-RPC), alors qu’on a déjà tout ce qu’il faut avec HTTP ? 🌍

Le principe est simple, REST c’est pas une technologie à proprement parler, c’est un style d’architecture. L’idée ? Utiliser les méthodes HTTP qu’on connaît déjà : GET, POST, PUT, DELETE, et les associer à des ressources (des URLs). En gros, t’as des “endpoints” qui représentent des objets ou des actions, et tu interagis avec eux via des requêtes HTTP. Rien de plus simple. Tu veux récupérer un user ? Tu fais un GET sur /users/1. Modifier un produit ? Un PUT sur /products/42. 🎯

C’est la révolution pour une raison : c’est léger. Pas besoin de fichiers XML énormes, tu passes des JSON simples et efficaces. Et surtout, REST s’adapte à tout : que ce soit pour de la data brute, une interface mobile, ou même des services web. C’est devenu le couteau suisse des API. 🛠️

Les irritants qu’on avait avant ? SOAP te demandait de définir chaque échange dans des fichiers WSDL (aka des pavés XML incompréhensibles), XML-RPC t’envoyait balader si t’avais une structure trop complexe… REST arrive et balaie tout ça avec un seul mot : simplicité.

Et c’est là que ça devient cool. T’as plus besoin de connaître un protocole farfelu, t’utilises juste ce bon vieux HTTP. Chaque action a son verbe (GET pour lire, POST pour créer, etc.), et le reste c’est juste des URLs et des datas bien propres. 🌐

Mais attention, REST, c’est aussi un peu la porte ouverte à l’anarchie. Vu que c’est un style et pas une norme, t’as autant de façons d’implémenter une API REST qu’il y a de devs sur Stack Overflow. Chacun fait à sa sauce : /api/v1/products ou juste /products, POST avec ou sans ID ? Bref, faut poser des règles pour pas finir avec une API REST qui ressemble à un plat de spaghettis. 🍝

REST a surtout permis aux microservices de décoller. Chaque petit service peut exposer une API REST, c’est facile à tester, facile à maintenir, et ça scale sans souci. 🏗️

Alors oui, REST c’est loin d’être parfait. Ça peut vite devenir un bazar à documenter si t’as une API complexe, et y’a toujours des débats sur la gestion des erreurs, mais comparé à ce qu’on avait avant, c’est un souffle d’air frais.

T’as une API REST sous la main qui te fait kiffer ou c’est plus galère qu’autre chose ? Partage tes tips, que ça tourne bien chez tout le monde ! 🚀

36 / 109
Retour aux histoires Réagir sur LinkedIn