¿Qué es un Payload en una API? JSON, XML, Ejemplos

Payload API: los datos llevados en un body HTTP request o response — separado de headers y metadata. Típicamente JSON, a veces XML o binario.

¿Qué es un payload en una API?

En terminología API, el payload son los datos reales llevados en un body HTTP request o response — separado de la metadata que lo rodea (URL, método, headers, status code). El término viene del networking y originalmente describía la porción "cargo" de un paquete, distinguiéndola de los headers de routing/control. La misma metáfora aplica a APIs: los headers le dicen al server cómo interpretar el request; el payload es el request.

Para un POST request creando un nuevo user, el payload es el body JSON conteniendo campos name, email, password. Para un GET response devolviendo un producto, el payload es el body JSON describiendo ese producto.

Dónde viven los payloads en HTTP

Los HTTP requests y responses tienen una estructura estricta: una start line, headers, una línea vacía, luego el body. El body es donde vive el 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"
}

Las primeras líneas son la metadata. Después de la línea en blanco, el objeto JSON es el payload. Diferentes métodos HTTP llevan payloads diferentemente:

  • POST, PUT, PATCH — típicamente tienen un request body payload.
  • GET, HEAD, DELETE — típicamente no tienen request body. Los parámetros van en la URL o query string.
  • Todos los response bodies — típicamente contienen un payload.

Formatos de payload comunes

JSON (más común)

JavaScript Object Notation. Human-readable, nativo a JavaScript. Dominante para REST APIs.

{
  "id": 42,
  "name": "Widget",
  "price": 29.99,
  "tags": ["new", "featured"]
}

XML

Más viejo, más verboso, todavía común en APIs enterprise (SOAP, APIs financieras).

Form-encoded

Forms HTML browser postean en este formato. Pares key=value separados por ampersands.

Multipart

Para uploads de archivos + campos de form juntos.

Binary

Datos binarios raw — uploads de archivos, response de imágenes, archivos descargados.

Protocol Buffers, Avro, MessagePack

Datos estructurados binary-encoded para APIs high-performance (gRPC usa protobuf).

Payload vs otras partes del request API

ParteDónde viveEjemplo
URL pathRequest line/api/users/42
Query stringURL después de ??page=2&limit=20
HeadersEntre start line y bodyAuthorization: Bearer ...
Payload (body)Después de línea vacía{"name": "Alice"}
Status codeResponse start line200 OK

Consideraciones de tamaño de payload

  • Ancho de banda. Payloads más grandes = transfer más lento = costos mobile más altos.
  • Límites del server. NGINX default 1 MB; AWS API Gateway 10 MB; Cloudflare 100 MB Pro. Hit el límite → 413 Payload Too Large.
  • Memoria. Servers típicamente bufferean el body completo.
  • Paginación. En vez de devolver array de 50 MB de todos los users, devuelve 100 a la vez con paginación cursor o offset.
  • Compresión. gzip/brotli corta el tamaño JSON ~70%.
  • Streaming. Para responses muy grandes server-sent events o chunked transfer encoding.

Validación de payload

  • Validación de schema. JSON Schema, Pydantic, Zod etc.
  • Límites de tamaño.
  • Validación de tipo.
  • Sanitización. Strippear o escapar HTML provisto por user.
  • Campos allow-list. Rechazar campos desconocidos para prevenir vulnerabilidades de mass-assignment.

Payloads en REST vs GraphQL vs gRPC

  • REST usa bodies HTTP request/response como payloads, típicamente JSON.
  • GraphQL usa un endpoint único donde el cliente envía un payload de query.
  • gRPC usa Protocol Buffers como formato de payload — binario, schema-validated.
  • WebSockets intercambian payloads sobre conexión persistente.

Pitfalls comunes con payloads

  • Header Content-Type faltante.
  • Charset incorrecto.
  • JSON sin escapar dentro de JSON.
  • Confiar en IDs provistos por cliente en payload. Siempre derivar identity de auth, no del payload.
  • Loggear payloads completos. Passwords, tokens, PII terminan en log aggregators.
  • Olvidar compresión.

Testing de payloads API at scale

  • Usar tamaños de payload realistas.
  • Variar contenidos de payload por VU.
  • Testear tamaños boundary. Justo debajo y justo arriba del max payload limit del server.
  • Validar response payloads.

FAQ: Payloads API

¿Es la URL parte del payload?

No. La URL es metadata. El payload está en el request body.

¿Tienen los GET requests payloads?

Técnicamente permitido, prácticamente no — la mayoría de frameworks ignoran GET request bodies.

¿Cuál es el tamaño máximo de payload?

Depende del server. NGINX default: 1 MB. AWS API Gateway: 10 MB. Cloudflare: 100 MB Pro.

¿Puede una response no tener payload?

Sí. Responses 204 No Content y 304 Not Modified no tienen body.

¿Cuál es la diferencia entre payload y body?

Mayormente sinónimos en HTTP. "Body" es el término spec HTTP; "payload" es el término application-level.

¿Cómo testeo payloads API bajo carga?

Usa una herramienta de load testing que permita parametrizar payloads por VU/iteración (LoadFocus con k6 o JMeter).

Testea payloads API at scale con LoadFocus

Si estás load-testeando APIs y necesitas enviar payloads realistas y parametrizados desde múltiples regiones, LoadFocus corre scripts JMeter y k6 desde 25+ regiones cloud con hasta 12.500 VUs. Regístrate en loadfocus.com/signup — sin tarjeta de crédito — y corre tu primer load test de payload en menos de 5 minutos.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.

×