POST

Méthode HTTP

Spécification de la méthode HTTP POST

  • fournir un bloc de données, tel que les champs saisis dans un formulaire HTML, à un processus de traitement des données;
  • envoyer un message à un tableau d'affichage, un groupe de discussion, une liste de diffusion, un blog ou un groupe d'articles similaire;
  • créer une nouvelle ressource qui n'a pas encore été identifiée par le serveur d'origine ; et
  • appliquer des données à la (aux) représentation(s) existante(s) d'une ressource.

Un serveur d'origine indique la sémantique de la réponse en choisissant un code d'état approprié en fonction du résultat du traitement de la demande POST ; presque tous les codes d'état définis par la présente spécification peuvent être reçus en réponse à POST (les exceptions étant 206 (contenu partiel), 304 (non modifié) et 416 (plage non satisfaisable)).

Si une ou plusieurs ressources ont été créées sur le serveur d'origine à la suite du traitement réussi d'une demande POST, le serveur d'origine SHOULD envoie une réponse 201 (Created) contenant un champ d'en-tête Location qui fournit un identifiant pour la ressource primaire créée (Section 7.1.2) et une représentation qui décrit l'état de la demande tout en faisant référence à la (aux) nouvelle(s) ressource(s).

Les réponses aux demandes POST ne peuvent être mises en cache que si elles contiennent des informations explicites sur la fraîcheur (voir la section 4.2.1 de [RFC7234]). Cependant, la mise en cache POST n'est pas très répandue. Dans les cas où un serveur d'origine souhaite que le client puisse mettre en cache le résultat d'un POST de manière à ce qu'il puisse être réutilisé par un GET ultérieur, le serveur d'origine MAY envoie une réponse 200 (OK) contenant le résultat et un champ d'en-tête Content-Location qui a la même valeur que l'URI de la requête effective du POST (Section 3.1.4.2).

Si le résultat du traitement d'un POST est équivalent à une représentation d'une ressource existante, un serveur d'origine MAY redirige l'agent utilisateur vers cette ressource en envoyant une réponse 303 (See Other) avec l'identificateur de la ressource existante dans le champ Location. Cela présente l'avantage de fournir à l'agent utilisateur un identificateur de ressource et de transférer la représentation par une méthode qui se prête mieux à la mise en cache partagée, mais au prix d'une demande supplémentaire si l'agent utilisateur n'a pas déjà la représentation en cache.

La méthode HTTP POST a été spécifiée dans la section 4.3.3 du document RFC 7231 par l'Internet Engineering Task Force (IETF) et le World Wide Web Consortium (W3C).

Description de la méthode POST

travaux en cours

Exemple de la méthode HTTP POST

Request header:
POST /data HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537
Accept: application/json
Accept-Language: de-DE,de;q=0.5
Content-Type: application/json
Content-Length: 100
Connection: keep-alive
Request body:
{
  "key": "value",
  "foo": "bar"
}
Response header:
Content-Type: application/json
Date: Mon, 31 July 2023 14:58:12 GMT
Server: Apache/2.4.7 (Ubuntu)
Cache-Control: no-cache
Location: http://api.example.com/data/123
Response body:
{
  "status": "success",
  "id": 123
}