SoapUI RESTful - Méthodes HTTP

Les méthodes HTTP les plus couramment utilisées sont POST, GET, PUT, PATCH et DELETE. Celles-ci correspondent respectivement aux opérations de création, de lecture, de mise à jour et de suppression (ou CRUD). Il existe également un certain nombre d'autres méthodes, mais elles sont moins utilisées. Parmi ces méthodes, OPTIONS et HEAD sont utilisées plus souvent que d'autres.

PUBLIER

La méthode POST est utilisée pour créer de nouvelles ressources. Il est utilisé pour créer des ressources subordonnées. C'est-à-dire subordonné à une autre ressource (par exemple parent).

En d'autres termes, lors de la création d'une nouvelle ressource, POST au parent et le service se charge d'associer la nouvelle ressource au parent, d'attribuer un ID (nouvel URI de ressource), etc.

En cas de création réussie, renvoyez l'état HTTP 201, en renvoyant un en-tête d'emplacement avec un lien vers la ressource nouvellement créée avec les états HTTP 201.

POST n'est ni sûr ni idempotent. Il est donc recommandé pour les demandes de ressources non idempotentes.

Faire deux requêtes POST identiques se traduira par deux ressources contenant les mêmes informations. Parfois, il lance un message d'erreur basé sur le type de services défini.

AVOIR

La méthode HTTP GET est utilisée pour lire ou récupérer une représentation d'une ressource. En cas de réponse réussie, GET renvoie une représentation en XML ou JSON et un code de réponse HTTP de 200 (OK). En cas d'erreur, il renvoie le plus souvent un 404 (NON TROUVÉ) ou un 400 (BAD REQUEST).

Selon la conception de la spécification HTTP, les requêtes GET (avec HEAD) sont utilisées uniquement pour lire les données et non pour les modifier. Par conséquent, GET est considéré comme sûr.

GET peut être appelé sans risque de modification ou de corruption des données - l'appeler une fois a le même effet que l'appel 10 fois. De plus, GET est idempotent, ce qui signifie que faire plusieurs demandes identiques conduit à avoir le même résultat qu'une seule demande.

Il est recommandé de ne pas exposer les opérations dangereuses via GET - il ne doit jamais modifier aucune ressource sur le serveur.

METTRE

PUT est utilisé pour mettre à jour les ressources existantes. PUT est utilisé comme URI de ressource connu avec le corps de la requête qui contient la représentation mise à jour de la ressource d'origine.

PUT peut également être utilisé pour créer une ressource dans laquelle l'ID de ressource est choisi par le client plutôt que par le serveur. En d'autres termes, si PUT est utilisé comme URI qui contient la valeur d'un ID de ressource inexistant.

POST est utilisé pour créer de nouvelles ressources et fournir l'ID défini par le client dans la représentation du corps. En cas de mise à jour réussie, il renvoie 200 (ou 204 s'il ne renvoie aucun contenu dans le corps) à partir d'un PUT.

Si PUT est utilisé pour la création, il renvoie l'état HTTP 201 lors de la création réussie. Un corps dans la réponse est facultatif.

PUT n'est pas une opération sûre, car il modifie (ou crée) l'état sur le serveur, mais il est idempotent. Si l'utilisateur crée ou met à jour une ressource à l'aide de PUT, puis effectue à nouveau le même appel, la ressource est toujours là et a le même état que lors du premier appel.

Il est recommandé de garder les requêtes PUT idempotentes. Il est fortement recommandé d'utiliser POST pour les requêtes non idempotentes.

PIÈCE

PATCH est utilisé pour modifier les capacités. La demande PATCH doit uniquement contenir les modifications apportées à la ressource, pas la ressource complète. Il ressemble à PUT, mais le corps contient un ensemble d'instructions décrivant comment une ressource résidant actuellement sur le serveur doit être modifiée pour produire une nouvelle version.

Cela signifie que le corps du PATCH ne doit pas être simplement une partie modifiée de la ressource, mais doit être dans une sorte de langage de patch tel que JSON Patch ou XML Patch.

PATCH n'est ni sûr ni idempotent. Une requête PATCH peut être émise de manière à être idempotente, ce qui permet également d'éviter les mauvais résultats de collisions entre deux requêtes PATCH sur la même ressource dans un laps de temps similaire.

Les collisions de plusieurs requêtes PATCH peuvent être plus dangereuses que les collisions PUT car certains formats de correctifs doivent fonctionner à partir d'un point de base connu, sinon ils corrompront la ressource.

Les clients utilisant ce type d'application de correctif doivent utiliser une demande conditionnelle de telle sorte que la demande échoue, si la ressource a été mise à jour, depuis le dernier accès du client à la ressource.

EFFACER

DELETE est utilisé pour supprimer une ressource identifiée par un URI. En cas de suppression réussie, il renvoie le statut HTTP 200 (OK) avec un corps de réponse, représentation de l'élément supprimé. Sinon, il renvoie l'état HTTP 204 (PAS DE CONTENU) sans corps de réponse.

En d'autres termes, un état 204 sans corps, ou la réponse de style JSEND et l'état HTTP 200 sont les réponses recommandées.

En ce qui concerne les spécifications HTTP, les opérations DELETE sont idempotentes. Si l'utilisateur supprime une ressource, elle est supprimée. L'appel répété de DELETE sur la même ressource aboutit au même résultat: la ressource a disparu.

Appeler DELETE sur une ressource une deuxième fois retournera souvent un 404 (NOT FOUND), car il a déjà été supprimé et n'est donc plus trouvable. Cela rend les opérations DELETE plus idempotentes, cependant, l'état final de la ressource est le même. Le retour d'un 404 est acceptable et communique avec précision le statut de l'appel.