POST
Utilisation
Une requête POST soumet une entité à la ressource indiquée. Le serveur détermine comment traiter la représentation incluse en fonction de la sémantique propre à la ressource. Contrairement à PUT, qui cible un URI de ressource précis, POST délègue le traitement à la ressource identifiée par l’URI cible.
L’en-tête Content-Type indique le format du corps de la requête. Trois encodages sont courants dans les formulaires HTML et les API.
application/x-www-form-urlencoded
L’encodage par défaut des formulaires HTML. Les données sont structurées en paires clé-valeur séparées par des esperluettes (&), les clés et les valeurs étant reliées par des signes égal (=). Les caractères non alphanumériques utilisent le Percent-Encoding.
name=Alice&role=adminmultipart/form-data
Chaque champ occupe une partie distincte délimitée par une chaîne de séparation déclarée dans l’en-tête Content-Type. Cet encodage prend en charge les données binaires, comme les envois de fichiers. L’en-tête Content-Disposition présent dans chaque partie nomme le champ.
text/plain
Aucune structure imposée. Le serveur traite le corps brut selon sa propre logique.
Les requêtes POST répétées ne sont pas idempotentes. Soumettre deux fois le même formulaire crée deux ressources ou déclenche deux fois le traitement, contrairement à PUT où une requête répétée produit le même état serveur.
Les réponses POST ne sont mises en cache que lorsque la réponse inclut des informations de fraîcheur explicites et un en-tête Content-Location correspondant.
Soumission de formulaire
Un client soumet des données de formulaire au format URL-encoded. Le serveur crée une tâche et répond avec 201 Created.
Requête
POST /jobs HTTP/1.1
Host: api.example.re
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
name=backup&pri=2Réponse
HTTP/1.1 201 Created
Location: /jobs/47
Content-Type: application/json
Content-Length: 38
{"id":47,"name":"backup","priority":2}Envoi de fichier multipart
Un client envoie un fichier en utilisant l’encodage multipart. La chaîne de séparation ----Boundary sépare chaque partie. Le serveur accepte l’envoi et renvoie 202 Accepted.
Requête
POST /uploads HTTP/1.1
Host: api.example.re
Content-Type: multipart/form-data; boundary=----Boundary
Content-Length: 196
------Boundary
Content-Disposition: form-data; name="title"
Q4 Report
------Boundary
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf
<binary data>
------Boundary--Réponse
HTTP/1.1 202 Accepted
Location: /uploads/91
Content-Length: 0JSON API
Un client envoie une charge utile JSON pour créer un nouvel utilisateur. Le serveur renvoie la ressource créée avec un champ id.
Requête
POST /users HTTP/1.1
Host: api.example.re
Content-Type: application/json
Content-Length: 41
{"email":"alice@example.re","role":"ops"}Réponse
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 50
{"id":112,"email":"alice@example.re","role":"ops"}CORS
POST est une méthode figurant sur la liste sûre de CORS, mais uniquement lorsque le Content-Type est application/x-www-form-urlencoded, multipart/form-data ou text/plain. Un POST avec application/json ou tout autre type de contenu déclenche une requête préliminaire OPTIONS.
POST comparé à GET
POST transporte les données dans le corps de la requête plutôt que dans l’URL. Cela maintient les paramètres hors de l’historique du navigateur, des journaux serveur et des en-têtes Referer, ce qui rend POST mieux adapté aux données sensibles.
Les réponses POST ne sont pas mises en cache par défaut et ne peuvent pas être mises en favori. POST n’est ni sûre ni idempotente, si bien que des soumissions répétées créent des ressources en double ou déclenchent plusieurs fois le traitement.
POST n’a pas de limite pratique de taille de corps, alors que GET est contrainte par des limites de longueur d’URL situées autour de 2048 caractères.
Les cookies avec SameSite=Lax bloquent les requêtes POST intersites mais autorisent les GET intersites. Cela confère à POST un certain niveau de protection CSRF intégrée que GET n’a pas.
Sécurité
Les données POST n’apparaissent pas dans les URL, l’historique du navigateur ni les en-têtes Referer. Cela réduit le risque d’exposition accidentelle de données par rapport à GET.
POST reste vulnérable aux attaques CSRF en l’absence de jetons appropriés. Les formulaires présents sur des pages malveillantes soumettent automatiquement des requêtes POST vers d’autres origines. Les cookies SameSite=Lax offrent une protection partielle en bloquant la transmission de cookies sur les POST intersites, mais des jetons CSRF dédiés restent nécessaires.
Un POST en HTTP simple transmet les données en clair. HTTPS est indispensable pour protéger le corps de la requête pendant son transit.
POST comparé à PATCH
POST crée de nouvelles ressources à des URI choisis par le serveur. PATCH modifie des ressources existantes à des URI connus.
POST délègue entièrement la sémantique de traitement au serveur. PATCH dispose de formats de patch définis, tels que JSON Patch et JSON Merge Patch, qui décrivent les modifications précises à appliquer.
Lorsqu’un client doit mettre à jour des champs précis d’une ressource existante, PATCH est la méthode appropriée. POST sert à créer de nouvelles ressources ou à déclencher un traitement côté serveur.