Programmation
.jpg)
Radzivon Alkhovik
Adepte de l'automatisation en code bas
%20(1)%20(1).png)
.png)
.svg){kind=icon}
Dans cet article, nous allons décomposer les méthodes de requête HTTP les plus populaires pour l'API REST, découvrir quelle est la différence entre les méthodes Post, Get, Put, Delete et Patch et comment les utiliser toutes !
Si l'API est la façon dont les applications parlent entre elles, les requêtes HTTP sont les phrases. Et tout comme les phrases, nous pouvons les diviser en groupes en fonction de l'objectif de la phrase, c'est-à-dire si nous voulons demander quelque chose ou délivrer un message.
Ainsi, dans l'API REST, les requêtes HTTP sont divisées en méthodes en fonction de leur objectif.
Voici les méthodes les plus utilisables :
Découvrons étape par étape quelles sont ces méthodes !
Les requêtes HTTP GET sont conçues pour récupérer des informations à partir d'une ressource spécifiée sur Internet sans modifier les données. Cette méthode est sûre car elle ne modifie pas l'état des données. Il est essentiel de saisir ce concept pour distinguer ce qu'est une requête get des autres types de requêtes HTTP, comme POST ou PUT, qui sont utilisées pour modifier ou ajouter des données sur le serveur.
Les requêtes GET doivent systématiquement renvoyer les mêmes résultats si elles sont effectuées plusieurs fois, à moins que les données n'aient été mises à jour par une requête POST ou PUT. Cette caractéristique est fondamentale 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.
Lorsqu'une demande GET est faite, le serveur répond avec différents codes d'état en fonction du résultat :
Ces réponses sont cruciales pour que les développeurs comprennent comment leurs demandes sont traitées et font partie de l'apprentissage des méthodes HTTP, notamment GET, POST et PUT.
Voyons quelques exemples pratiques pour comprendre comment les requêtes GET sont utilisées :
Les requêtes HTTP POST sont essentielles dans le développement web pour créer de nouvelles ressources subordonnées, comme l'ajout d'un fichier à un répertoire ou d'une nouvelle ligne à une table de base de données. Cette méthode est particulièrement pertinente lorsque nous discutons de ce qu'est une requête post et de la façon d'envoyer une requête post.
Dans le contexte des services RESTful, POST est principalement utilisé pour introduire une nouvelle entité dans un ensemble de ressources, un processus central pour comprendre la différence entre get et post, ainsi que les interactions get post put.
Il est important de noter que les réponses aux méthodes POST ne peuvent pas être mises en cache sauf si elles sont spécifiées par les champs d'en-tête Cache-Control ou Expires, ce qui distingue les requêtes POST des requêtes get en termes de comportement du cache.
Contrairement aux requêtes GET, POST n'est ni sûr ni idempotent. Cela signifie que l'exécution consécutive de requêtes post identiques entraînera la création de plusieurs ressources uniques, ce qui met en évidence les implications pratiques de post et get, post et put, ainsi que le paysage plus large des méthodes de requête.
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 demande, référencer la nouvelle ressource et inclure un en-tête Location, fournissant ainsi une application réelle des exemples de post-requête et des idées de réponse HTTP post.
Il y a des cas où une action POST ne mène pas à une ressource identifiable de façon unique. Dans ce cas, le serveur peut renvoyer un état 200 (OK) ou 204 (Pas de contenu), reflétant les différences nuancées entre post et put request, get et post, et le cadre général des méthodes de requête.
Pour illustrer cela, considère ces exemples d'URI qui incarnent les pratiques post to url et la méthode POST :
Utilise les API PUT principalement pour mettre à jour une ressource existante (si la ressource n'existe pas, l'API peut décider de créer une nouvelle ressource ou non).
Si la demande passe par un cache et que l'URL de la demande identifie une ou plusieurs entités actuellement mises en cache, ces entrées DEVRAIENT être traitées comme périmées. Les réponses à la méthode PUT ne peuvent pas être mises en cache.
Les requêtes HTTP PUT sont essentielles pour modifier le contenu en ligne existant ou ajouter de nouveaux éléments s'ils n'existent pas encore. Cette méthode brille lorsque tu mets à jour les détails d'une page Web ou que tu soumets de nouvelles entrées, en chevauchant la ligne entre ce qu'est une requête put et les décisions put vs post. C'est un outil fondamental dans la trousse du développeur, en particulier lorsqu'il s'agit de débattre de l'utilisation de post et de put ou d'explorer les nuances des actions de put et de post.
Si une demande PUT passe par un point de stockage numérique (cache) et découvre qu'elle s'adresse à un contenu déjà stocké, elle signale ce contenu comme étant ancien. Ce qui est intéressant ici, c'est que les résultats de ces actions PUT ne restent pas dans le cache, ce qui les différencie de la façon dont les demandes get et post sont traitées. Cette distinction est essentielle pour comprendre la différence entre get et post, ainsi que pour comprendre le déploiement stratégique des opérations get post put dans le développement Web.
Regardons PUT faire son travail :
Méthode DELETE
Comment DELETE fonctionne avec les API Web
La fonction DELETE des API web est simple : elle permet de se débarrasser des ressources que tu pointes avec leurs adresses web (URI).
Voici quelque chose d'intéressant à propos de DELETE : il est censé fonctionner de la même façon à chaque fois. Si tu supprimes quelque chose, cela doit rester supprimé. Mais certaines personnes affirment que puisque l'élément n'est plus là, essayer de le supprimer à nouveau ne fait pas vraiment la même chose, ce qui pourrait te faire réfléchir à deux fois sur le fait que DELETE fonctionne toujours de la même manière. C'est un sujet dont certaines personnes aiment discuter et qu'elles voient différemment.
Si ta demande DELETE passe par un endroit où les informations Web sont sauvegardées (comme un cache) et qu'elle trouve des choses sous la même adresse, ces choses devraient être marquées comme anciennes. Et pour ta gouverne, les réponses que tu obtiens en retour d'un DELETE ne sont pas sauvegardées dans ce cache.
Que se passe-t-il après l'effacement ?
Ce qui se passe après que tu aies appuyé sur DELETE peut varier un peu :
Si tu essaies de supprimer deux fois la même chose, la deuxième fois ne fera rien de nouveau car l'élément a déjà été supprimé la première fois. Tu obtiendras donc probablement un message 404 (NOT FOUND) parce que, aux yeux du serveur, il n'y a plus rien à supprimer.
Les demandes HTTP PATCH sont utilisées pour 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 voir les choses : utilise PATCH lorsque tu veux mettre à jour juste un morceau de la ressource, et opte pour PUT lorsque tu as l'intention de remplacer l'ensemble.
Garde cependant à l'esprit que l'utilisation de PATCH dans ton application peut poser quelques 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 claire : utilise des outils no-code/low-code pour cela ! Latenode est un choix parfait, parce qu'il a un nœud HTTP-request où tu peux utiliser n'importe laquelle de ces méthodes pour t'intégrer à N'IMPORTE QUELLE application qui a une API.
Tu peux utiliser ce modèle qui n'utilise qu'une partie des capacités de la requête HTTP,
Maintenant que tu as acquis des connaissances sur les méthodes de requête HTTP telles que GET, POST, PUT, DELETE et PATCH, tu es prêt à passer à l'étape suivante de ta compréhension des API.
Cependant, notre exploration ne s'arrête pas là. Nous t'invitons à te plonger dans notre dernier article - En-têtes et corps de l'API RESTpour affiner ta maîtrise des API.
Si tu as des questions ou si tu souhaites discuter davantage, nous t'invitons à rejoindre notre communauté Discord. Là, nous nous engageons à partager des idées et à t'apporter notre soutien pendant que tu poursuis ton voyage dans le monde de l'automatisation.
Articles connexes :
