Programmation
.jpg)
Radzivon Alkhovik
Passionné d'automatisation low-code
.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 communiquent entre elles, alors les requêtes HTTP sont les phrases. Et tout comme les phrases, nous pouvons les diviser en groupes en fonction du but de la phrase, voulons-nous demander quelque chose ou transmettre 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 comprendre 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 renvoyer systématiquement les mêmes résultats si 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 un élément fondamental 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 requête GET est effectuée, le serveur répond avec des codes d'état différents selon le résultat :
Ces réponses sont essentielles pour que les développeurs comprennent comment leurs requêtes sont traitées et font partie de l'apprentissage des méthodes HTTP, notamment GET, POST et PUT.
Regardons 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, telles que 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 lorsqu'on discute de ce qu'est une demande de publication et de la manière d'envoyer une demande de publication.
Dans le contexte des services RESTful, POST est principalement utilisé pour introduire une nouvelle entité dans une collection de ressources, un processus essentiel 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 à Les 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, distinguant 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 de publication identiques entraînera la création de plusieurs ressources uniques, mettant 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 (Créé). Cette réponse doit détailler le résultat de la demande, référencer la nouvelle ressource et inclure un en-tête d'emplacement, fournissant une application concrète d'exemples de demandes de publication et d'informations sur les réponses de publication HTTP.
Il y a des cas lorsqu'une action POST ne conduit pas à une ressource identifiable de manière unique. Dans de tels cas, le serveur peut renvoyer un 200 (d'accord) ou statut 204 (pas de contenu), réfléchissant sur les différences nuancées entre les requêtes post et put, get et post, et le cadre global des méthodes de requête.
Pour illustrer, considérons ces exemples d’URI qui incarnent les pratiques de publication sur URL et de méthode POST :
Utilisez 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'URI de demande identifie une ou plusieurs entités actuellement mises en cache, ces entrées DEVRAIT être traité comme périmé. Les réponses à la méthode PUT ne peuvent pas être mises en cache.
Les requêtes HTTP PUT sont essentielles pour peaufiner le contenu en ligne existant ou ajouter de nouveaux éléments s'ils n'existent pas déjà. Cette méthode est particulièrement utile lorsque vous mettez à jour les détails d'une page Web ou soumettez de nouvelles entrées, à cheval entre ce qu'est une requête put et les décisions put vs post. C'est un outil fondamental dans le kit du développeur, en particulier lors du débat sur l'utilisation de post et put ou lors de l'exploration des nuances des actions put et post.
Si une requête PUT passe par un emplacement de stockage numérique (cache) et découvre qu'elle s'adresse à un contenu déjà stocké, elle signale ce contenu comme étant obsolète. 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 distingue de la manière dont les requêtes get et post sont traitées. Cette distinction est essentielle pour différencier get et post, ainsi que pour comprendre le déploiement stratégique des opérations get post put dans le développement Web.
Voyons comment PUT fait son travail :
Méthode DELETE
Comment DELETE fonctionne avec les API Web
La fonction DELETE dans les API Web est simple : elle supprime les ressources vers lesquelles vous pointez avec leurs adresses Web (URI).
Voici quelque chose d'intéressant à propos de DELETE : c'est censé fonctionner de la même manière à chaque fois. Si vous supprimez quelque chose, il doit rester supprimé. Mais certaines personnes soutiennent que, puisque l'élément n'existe plus, essayer de le supprimer à nouveau n'a pas vraiment le même effet, ce qui pourrait vous faire réfléchir à deux fois sur le fait que DELETE fonctionne toujours de la même manière. C'est un sujet que certaines personnes aiment aborder et voir différemment.
Si votre demande DELETE passe par un endroit où les informations Web sont enregistrées (comme un cache) et qu'elle trouve des éléments sous la même adresse, ces éléments doivent être marqués comme anciens. Et juste pour que vous le sachiez, les réponses que vous obtenez après une SUPPRESSION ne sont pas enregistrées dans ce cache.
Que se passe-t-il après avoir SUPPRIMÉ
Ce qui se passe après avoir appuyé sur SUPPRIMER peut varier légèrement :
Si vous essayez de supprimer deux fois la même chose, la deuxième fois n'apportera rien de nouveau, car l'élément a déjà été supprimé la première fois. Vous obtiendrez donc probablement un 404 (NON TROUVÉ) parce que, aux yeux du serveur, il n'y a plus rien à supprimer.
Les requêtes 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 d'y penser : utilisez PATCH lorsque vous souhaitez mettre à jour juste une partie de la ressource, et optez pour PUT lorsque vous prévoyez de remplacer le tout.
Gardez toutefois à l’esprit que l’utilisation de PATCH dans votre application peut entraîner 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 claire : utilisez des outils sans code/à faible code pour cela ! Latenode est un choix parfait, car il dispose d'un nœud de requête HTTP où vous pouvez utiliser n'importe laquelle de ces méthodes pour vous intégrer à TOUTE application dotée d'une API.
Vous pouvez utiliser ce gabarit qui utilise seulement quelques-unes des capacités de requête HTTP,
Maintenant que vous disposez de connaissances sur les méthodes de requête HTTP telles que GET, POST, PUT, DELETE et PATCH, vous êtes prêt à faire passer votre compréhension des API au niveau supérieur.
Mais notre exploration ne s'arrête pas là. Nous vous invitons à vous plonger dans notre dernier article - En-têtes et corps de l'API REST, pour affiner davantage votre maîtrise des API.
Si vous avez des questions ou souhaitez une discussion plus approfondie, nous vous invitons à nous rejoindre. Communauté discorde. Là, nous nous engageons à partager des idées et à vous fournir un soutien pendant que vous poursuivez votre voyage dans le monde de l'automatisation.
Articles Liés:
Première demande + Deuxième demande
