Dans cet article, nous allons détailler les méthodes de requêtes HTTP les plus populaires pour les API REST, découvrir les différences entre les méthodes POST, GET, PUT, DELETE et PATCH, et voir comment les utiliser toutes !
Qu’est-ce qu’une requête HTTP ?
Si une API est le moyen par lequel les applications communiquent entre elles, les requêtes HTTP sont leurs phrases. Et comme les phrases, nous pouvons les classer selon leur objectif : voulons-nous poser une question ou transmettre un message ?
Dans une API REST, les requêtes HTTP sont donc divisées en méthodes selon leur objectif.
Voici les méthodes les plus utilisées :
- GET
- POST
- PUT
- DELETE
- PATCH
Découvrons ces méthodes étape par étape !
Créez un nombre illimité d’intégrations avec des branchements, plusieurs déclencheurs convergeant vers un même nœud, utilisez le low-code ou écrivez votre propre code avec AI Copilot.
Méthode GET
Comprendre les requêtes HTTP GET
Les requêtes HTTP GET sont conçues pour récupérer des informations depuis une ressource spécifiée sur Internet sans modifier les données. Cette méthode est sûre, car elle ne change pas l’état des données. Il est essentiel de comprendre ce concept afin de distinguer une requête GET d’autres types de requêtes HTTP, comme POST ou PUT, qui servent à modifier ou ajouter des données sur le serveur.
Les requêtes GET doivent systématiquement renvoyer les mêmes résultats lorsqu’elles sont effectuées plusieurs fois, sauf si les données ont été mises à jour par une requête POST ou PUT. Cette caractéristique est essentielle pour comprendre la différence entre les requêtes GET et POST, ainsi que le rôle des requêtes PUT dans le développement web.
Codes de réponse pour les requêtes GET
Lorsqu’une requête GET est effectuée, le serveur répond avec différents codes d’état selon le résultat :
- Un code d’état 200 (OK) signifie que la requête a réussi et que le serveur renvoie les informations demandées ; c’est un exemple direct de requête GET réussie.
- Un code d’état 404 (NOT FOUND) indique que la ressource demandée est introuvable sur le serveur, ce qui illustre un résultat courant d’une requête GET.
- Un code d’état 400 (BAD REQUEST) est renvoyé lorsque la requête est mal formée, soulignant l’importance de structurer correctement les requêtes HTTP.
Ces réponses sont essentielles pour permettre aux développeurs de comprendre comment leurs requêtes sont traitées et font partie de l’apprentissage des méthodes HTTP, notamment GET, POST et PUT.
Exemples pratiques de requêtes GET
Examinons quelques exemples pratiques pour comprendre comment les requêtes GET sont utilisées :
- Récupérer une liste de comptes utilisateur : HTTP GET http://www.exampledomain.com/accounts
- Récupérer un sous-ensemble de comptes utilisateur avec des paramètres spécifiques : HTTP GET http://www.exampledomain.com/accounts?limit=20&offset=5
- Accéder aux détails d’un compte utilisateur spécifique : HTTP GET http://www.exampledomain.com/accounts/123
- Obtenir des informations détaillées sur l’adresse d’un utilisateur : HTTP GET http://www.exampledomain.com/accounts/123/details
Méthode POST
Les requêtes HTTP POST sont essentielles en développement web pour créer de nouvelles ressources subordonnées, par exemple ajouter un fichier à un répertoire ou une nouvelle ligne à une table de base de données. Cette méthode est particulièrement pertinente lorsqu’il s’agit de comprendre ce qu’est une requête POST et comment en envoyer une.
Dans le contexte des services RESTful, POST est principalement utilisé pour introduire une nouvelle entité dans une collection de ressources, un processus central pour comprendre la différence entre GET et POST, ainsi que les interactions entre GET, POST et PUT.
Il est important de noter que les réponses aux méthodes POST ne peuvent pas être mises en cache, sauf indication contraire dans les champs d’en-tête Cache-Control ou Expires, ce qui distingue POST des requêtes GET en matière de comportement de cache.
Contrairement aux requêtes GET, POST n’est ni sûre ni idempotente. Cela signifie que l’exécution consécutive de requêtes POST identiques entraînera la création de plusieurs ressources uniques, mettant en évidence les implications pratiques de POST et GET, de POST et PUT, ainsi que du paysage plus large des méthodes de requête.
Quels sont les codes de réponse d’une API POST ?
Lorsqu’une opération POST génère avec succès une nouvelle ressource sur le serveur, la réponse appropriée est un code d’état 201 (Created). Cette réponse doit détailler le résultat de la requête, faire référence à la nouvelle ressource et inclure un en-tête Location, offrant une application concrète des exemples de requêtes POST et des réponses HTTP POST.
Il existe des cas où une action POST ne mène pas à une ressource identifiable de manière unique. Dans ces situations, le serveur peut renvoyer un état 200 (OK) ou 204 (No Content), reflétant les différences nuancées entre les requêtes POST et PUT, GET et POST, ainsi que le cadre global des méthodes de requête.
Illustration des requêtes POST avec des exemples
À titre d’illustration, considérez ces exemples d’URI qui représentent les pratiques de POST vers une URL et de la méthode POST :
- Créer un nouveau profil utilisateur : HTTP POST http://www.exampledomain.com/accounts
- Ajouter des informations spécifiques à un profil utilisateur : HTTP POST http://www.exampledomain.com/accounts/123/details
Méthode PUT
Utilisez principalement les API PUT pour mettre à jour une ressource existante (si la ressource n’existe pas, l’API peut décider de créer ou non une nouvelle ressource).
Si la requête passe par un cache et que l’URI de requête identifie une ou plusieurs entités actuellement mises en cache, ces entrées DOIVENT être considérées comme obsolètes. Les réponses à la méthode PUT ne peuvent pas être mises en cache.
3.1. Codes de réponse d’une API PUT
Les requêtes HTTP PUT sont essentielles pour modifier du contenu en ligne existant ou ajouter de nouveaux éléments s’ils n’existent pas encore. Cette méthode est particulièrement utile lorsque vous mettez à jour des informations sur une page web ou soumettez de nouvelles entrées, à la frontière entre ce qu’est une requête PUT et les choix entre PUT et POST. C’est un outil fondamental dans la boîte à outils des développeurs, notamment lorsqu’il s’agit de déterminer quand utiliser POST ou PUT, ou d’explorer les nuances de ces actions.
Si une requête PUT passe par un espace de stockage numérique (cache) et constate qu’elle cible du contenu déjà stocké, ce contenu est considéré comme obsolète. Il est intéressant de noter que les résultats de ces actions PUT ne restent pas dans le cache, ce qui les distingue de la manière dont les requêtes GET et POST sont traitées. Cette distinction est essentielle pour comprendre la différence entre GET et POST, ainsi que le déploiement stratégique des opérations GET, POST et PUT dans le développement web.
Points clés concernant les réponses PUT
- Si PUT crée quelque chose de nouveau, le serveur web vous l’indiquera avec un message 201 (Created). Cela clarifie certains points concernant les réponses HTTP POST et le moment où utiliser POST vers une URL.
- La modification d’un élément existant renverra un 200 (OK) ou un simple message 204 (No Content). C’est une manière concise de distinguer les actions de la méthode PUT des débats entre PUT et POST.
Exemples d’utilisation de PUT
Voyons PUT en action :
- Pour mettre à jour les informations d’un utilisateur, utilisez : HTTP PUT http://www.exampledomain.com/accounts/123
- Modifier les détails d’un compte ? Essayez : HTTP PUT http://www.exampledomain.com/accounts/123/details
Méthode DELETE
Fonctionnement de DELETE avec les API web
La fonction DELETE dans les API web est simple : elle supprime les ressources que vous désignez par leurs adresses web (URI).
Voici un point intéressant concernant DELETE : elle est censée fonctionner de la même manière à chaque fois. Si vous supprimez quelque chose, cet élément doit rester supprimé. Toutefois, certaines personnes estiment que, puisque l’élément n’existe plus, tenter de le supprimer une seconde fois ne produit pas réellement le même effet. Cela peut amener à s’interroger sur le caractère systématiquement identique de DELETE. C’est un sujet qui fait débat et peut être interprété différemment.
Si votre requête DELETE passe par un espace où les informations web sont stockées, comme un cache, et qu’elle y trouve des ressources à la même adresse, ces ressources doivent être marquées comme obsolètes. Et les réponses renvoyées par DELETE ne sont pas stockées dans ce cache.
Ce qui se passe après une requête DELETE
Le résultat après l’exécution de DELETE peut varier :
- Vous pouvez recevoir un état 200 (OK) si le serveur vous indique le résultat de la suppression.
- Si le serveur traite encore votre demande et que votre requête de suppression est en attente, vous verrez un état 202 (Accepted).
- Parfois, le serveur a exécuté votre demande sans vous renvoyer de détails. Dans ce cas, vous verrez un état 204 (No Content).
Si vous essayez de supprimer deux fois le même élément, la seconde tentative ne produira rien de nouveau, car l’élément a déjà été supprimé lors de la première. Vous recevrez donc probablement un 404 (NOT FOUND) car, du point de vue du serveur, il n’y a plus rien à supprimer.
Exemples d’URI avec des liens mis à jour
- Pour supprimer un profil utilisateur : HTTP DELETE http://www.exampledomain.com/accounts/123
- Pour supprimer les détails spécifiques du compte d’un utilisateur : HTTP DELETE http://www.exampledomain.com/accounts/123/details
Méthode PATCH
Les requêtes HTTP PATCH servent à mettre à jour une partie d’une ressource.
Comme PATCH, les requêtes PUT peuvent également modifier une ressource. Mais voici une façon plus claire de l’envisager : utilisez PATCH lorsque vous souhaitez mettre à jour uniquement une partie de la ressource, et choisissez PUT lorsque vous prévoyez de remplacer l’ensemble.
Gardez toutefois à l’esprit que l’utilisation de PATCH dans votre application peut poser certains problèmes :
Tous les navigateurs web, serveurs et frameworks ne prennent pas entièrement en charge PATCH. Par exemple, Internet Explorer 8, PHP, Tomcat, Django et bien d’autres ne prennent pas du tout en charge PATCH ou ne le gèrent pas correctement.
Comment utiliser les méthodes GET/POST/PUT/DELETE sans code ?
La réponse est simple : utilisez des outils no-code/low-code ! Latenode est un excellent choix, car il propose un nœud de requête HTTP dans lequel vous pouvez utiliser n’importe laquelle de ces méthodes pour vous intégrer à TOUTE application disposant d’une API.
Vous pouvez utiliser ce modèle, qui exploite seulement certaines fonctionnalités des requêtes HTTP,
Conclusion
Maintenant que vous maîtrisez les méthodes de requêtes HTTP telles que GET, POST, PUT, DELETE et PATCH, vous êtes prêt à faire passer votre compréhension des API au niveau supérieur.
Cependant, notre exploration ne s’arrête pas là. Nous vous invitons à consulter notre dernier article — En-têtes et corps REST API — afin d’approfondir votre maîtrise des API.
Si vous avez des questions ou souhaitez poursuivre la discussion, nous vous invitons à rejoindre notre communauté Discord. Vous y trouverez des informations utiles et du soutien pour poursuivre votre parcours dans le monde de l’automatisation.
Optimisez vos processus métier sur Latenode — la meilleure plateforme d’automatisation pour vous
