Qu'est-ce qu'un Payload dans une API ? JSON, XML, Exemples
Payload API : les données portées dans un body HTTP request ou response — séparé des headers et de la metadata. Typiquement JSON, parfois XML ou binaire.
Qu'est-ce qu'un payload dans une API ?
En terminologie API, le payload est les données réelles portées dans un body HTTP request ou response — séparé de la metadata qui l'entoure (URL, méthode, headers, status code). Le terme vient du networking et décrivait à l'origine la portion "cargo" d'un paquet, la distinguant des headers de routing/control. La même métaphore s'applique aux APIs : les headers disent au serveur comment interpréter la requête ; le payload est la requête.
Pour une POST requête créant un nouvel utilisateur, le payload est le body JSON contenant des champs name, email, password. Pour une GET response retournant un produit, le payload est le body JSON décrivant ce produit.
Où vivent les payloads en HTTP
Les HTTP requests et responses ont une structure stricte : une start line, des headers, une ligne vide, puis le body. Le body est où vit le payload.
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 76
Authorization: Bearer xyz123
{
"name": "Alice",
"email": "alice@example.com",
"role": "admin"
}Les premières lignes sont la metadata. Après la ligne vide, l'objet JSON est le payload. Différentes méthodes HTTP portent les payloads différemment :
- POST, PUT, PATCH — ont typiquement un request body payload.
- GET, HEAD, DELETE — n'ont typiquement pas de request body. Les paramètres vont dans l'URL ou query string.
- Tous les response bodies — contiennent typiquement un payload.
Formats de payload courants
JSON (le plus courant)
JavaScript Object Notation. Human-readable, natif à JavaScript. Dominant pour REST APIs.
{
"id": 42,
"name": "Widget",
"price": 29.99,
"tags": ["new", "featured"]
}XML
Plus ancien, plus verbeux, toujours courant dans les APIs enterprise (SOAP, APIs financières).
Form-encoded
Les forms HTML navigateur postent dans ce format. Paires key=value séparées par esperluettes.
Multipart
Pour les uploads de fichiers + champs de form ensemble.
Binary
Données binaires raw — uploads de fichiers, response d'images, archives téléchargées.
Protocol Buffers, Avro, MessagePack
Données structurées binary-encoded pour APIs high-performance (gRPC utilise protobuf).
Payload vs autres parties de requête API
| Partie | Où elle vit | Exemple |
|---|---|---|
| Path URL | Request line | /api/users/42 |
| Query string | URL après ? | ?page=2&limit=20 |
| Headers | Entre start line et body | Authorization: Bearer ... |
| Payload (body) | Après ligne vide | {"name": "Alice"} |
| Status code | Response start line | 200 OK |
Considérations de taille de payload
- Bande passante. Payloads plus grands = transfer plus lent = coûts mobile plus élevés.
- Limites serveur. NGINX défaut 1 MB ; AWS API Gateway 10 MB ; Cloudflare 100 MB Pro. Limite atteinte → 413 Payload Too Large.
- Mémoire. Les serveurs bufferisent typiquement le body entier.
- Pagination. Au lieu de retourner un array 50 MB de tous les users, retourner 100 à la fois.
- Compression. gzip/brotli coupe la taille JSON ~70%.
- Streaming. Pour les responses très grandes server-sent events ou chunked transfer encoding.
Validation du payload
- Validation de schema. JSON Schema, Pydantic, Zod etc.
- Limites de taille.
- Validation de type.
- Sanitization. Stripper ou escaper le HTML fourni par l'utilisateur.
- Champs allow-list. Rejeter les champs inconnus pour prévenir les vulnérabilités mass-assignment.
Payloads en REST vs GraphQL vs gRPC
- REST utilise bodies HTTP request/response comme payloads, typiquement JSON.
- GraphQL utilise un endpoint unique où le client envoie un payload de query.
- gRPC utilise Protocol Buffers comme format de payload — binaire, schema-validated.
- WebSockets échangent des payloads sur connexion persistante.
Pièges courants avec les payloads
- Header Content-Type manquant.
- Charset incorrect.
- JSON non-échappé à l'intérieur de JSON.
- Faire confiance aux IDs fournis par client dans le payload. Toujours dériver l'identity de l'auth, pas du payload.
- Logger les payloads complets. Passwords, tokens, PII finissent dans les log aggregators.
- Oublier la compression.
Tester les payloads API at scale
- Utiliser des tailles de payload réalistes.
- Varier les contenus de payload par VU.
- Tester les tailles boundary. Juste sous et juste au-dessus de la max payload limit du serveur.
- Valider les response payloads.
FAQ : Payloads API
L'URL fait-elle partie du payload ?
Non. L'URL est de la metadata. Le payload est dans le request body.
Les requêtes GET ont-elles des payloads ?
Techniquement permis, pratiquement non — la plupart des frameworks ignorent les GET request bodies.
Quelle est la taille maximale de payload ?
Dépend du serveur. NGINX défaut : 1 MB. AWS API Gateway : 10 MB. Cloudflare : 100 MB Pro.
Une response peut-elle ne pas avoir de payload ?
Oui. Les responses 204 No Content et 304 Not Modified n'ont pas de body.
Quelle est la différence entre payload et body ?
Principalement synonymes en HTTP. "Body" est le terme spec HTTP ; "payload" est le terme application-level.
Comment tester les payloads API sous charge ?
Utiliser un outil de load testing qui permet de paramétrer les payloads par VU/itération (LoadFocus avec k6 ou JMeter).
Testez les payloads API at scale avec LoadFocus
Si vous load-testez des APIs et avez besoin d'envoyer des payloads réalistes et paramétrés depuis plusieurs régions, LoadFocus exécute des scripts JMeter et k6 depuis 25+ régions cloud avec jusqu'à 12 500 VUs. Inscrivez-vous sur loadfocus.com/signup — pas de carte de crédit — et lancez votre premier load test de payload en moins de 5 minutes.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus — la plateforme même qui propulse tout ce que vous venez de lire.