Was ist ein Payload in einer API? JSON, XML, Beispiele

Was ist ein Payload in einer API?

In API-Terminologie ist der Payload die tatsächlichen Daten, die in einem HTTP-Request- oder Response-Body transportiert werden — separat von den Metadaten drumherum (URL, Method, Headers, Status-Code). Der Begriff kommt aus dem Networking und beschrieb ursprünglich den "Cargo"-Teil eines Pakets, im Unterschied zu Routing/Control-Headers. Dieselbe Metapher gilt für APIs: Headers sagen dem Server wie der Request zu interpretieren ist; der Payload ist der Request.

Für einen POST-Request, der einen neuen User erstellt, ist der Payload der JSON-Body mit Name-, Email- und Password-Feldern. Für eine GET-Response, die ein Produkt zurückgibt, ist der Payload der JSON-Body, der das Produkt beschreibt.

Wo Payloads in HTTP leben

HTTP-Requests und Responses haben eine strikte Struktur: eine Start-Line, Headers, eine leere Zeile, dann der Body. Der Body ist, wo der Payload lebt.

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"
}

Die ersten Zeilen sind die Metadaten. Nach der leeren Zeile ist das JSON-Objekt der Payload. Verschiedene HTTP-Methoden tragen Payloads unterschiedlich:

• POST, PUT, PATCH — haben typischerweise einen Request-Body-Payload.
• GET, HEAD, DELETE — haben typischerweise keinen Request-Body. Parameter gehen stattdessen in die URL oder Query-String.
• Alle Response-Bodies — enthalten typischerweise einen Payload (JSON, XML, HTML, File-Bytes etc.).

Häufige Payload-Formate

JSON (am häufigsten)

JavaScript Object Notation. Human-readable, native zu JavaScript. Dominant für REST APIs.

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

XML

Älter, verbose, immer noch häufig in Enterprise-APIs (SOAP, Finanz-APIs).

Form-encoded (application/x-www-form-urlencoded)

Browser-HTML-Forms posten in diesem Format. Key=Value-Paare durch Ampersands getrennt.

Multipart (multipart/form-data)

Für File-Uploads + Form-Felder zusammen.

Binary (application/octet-stream, image/png etc.)

Raw Binary-Daten — File-Uploads, Image-Responses, Downloaded Archives.

Protocol Buffers, Avro, MessagePack

Binary-encoded strukturierte Daten für High-Performance-APIs (gRPC nutzt protobuf).

Payload vs andere API-Request-Teile

Payload-Größen-Überlegungen

• Bandbreite. Größere Payloads = langsamer Transfer = höhere Mobile-Data-Kosten.
• Server-Limits. NGINX default 1 MB; AWS API Gateway 10 MB; Cloudflare 100 MB Pro. Limit hit → 413 Payload Too Large.
• Memory. Server bufferen typischerweise den ganzen Body — große Payloads belasten Server-Memory.
• Pagination. Statt 50 MB Array aller User zu returnen, 100 zur Zeit mit Cursor- oder Offset-Pagination.
• Kompression. gzip/brotli schneidet JSON-Größe um ~70%.
• Streaming. Für sehr große Responses Server-Sent Events oder Chunked Transfer Encoding.

Payload-Validierung

• Schema-Validierung. JSON Schema, Pydantic, Zod etc.
• Size-Limits. Payloads über konfiguriertem Max ablehnen.
• Type-Validierung.
• Sanitization. User-bereitgestelltes HTML strippen oder escapen.
• Allow-List Felder. Unbekannte Felder ablehnen, um Mass-Assignment-Vulnerabilities zu verhindern.

Payloads in REST vs GraphQL vs gRPC

• REST nutzt HTTP-Request/Response-Bodies als Payloads, typischerweise JSON.
• GraphQL nutzt einen einzigen Endpoint mit Query-Payload, der genau beschreibt, welche Daten zu returnen sind.
• gRPC nutzt Protocol Buffers als Payload-Format — binär, schema-validiert.
• WebSockets tauschen Payloads über eine persistente Connection aus.

Häufige Payload-Fallstricke

• Fehlender Content-Type-Header. Server weiß nicht, wie der Body zu parsen ist.
• Falsches Charset. UTF-8-Mismatches verursachen unleserliche Zeichen.
• Unescaped JSON in JSON.
• Client-bereitgestellten IDs im Payload trauen. Identity immer aus Auth ableiten, nicht aus Payload.
• Volle Payloads loggen. Passwörter, Tokens, PII landen in Log-Aggregatoren.
• Kompression vergessen.

API-Payloads at Scale testen

• Realistische Payload-Größen nutzen.
• Payload-Inhalte pro VU variieren.
• Boundary-Größen testen. Knapp unter und knapp über Server-Max-Payload-Limit.
• Response-Payloads validieren.

FAQ: API-Payloads

Ist die URL Teil des Payloads?

Nein. Die URL ist Metadaten. Der Payload ist im Request-Body.

Haben GET-Requests Payloads?

Technisch erlaubt, praktisch nein — die meisten Frameworks ignorieren GET-Request-Bodies.

Was ist die maximale Payload-Größe?

Hängt vom Server ab. NGINX-Default: 1 MB. AWS API Gateway: 10 MB. Cloudflare: 100 MB Pro.

Kann eine Response keinen Payload haben?

Ja. 204 No Content und 304 Not Modified haben keinen Body.

Was ist der Unterschied zwischen Payload und Body?

Meist Synonyme in HTTP. "Body" ist der HTTP-Spec-Term; "Payload" ist der Application-Level-Term.

Wie teste ich API-Payloads unter Last?

Tool nutzen, das Payloads pro VU/Iteration parametrisieren lässt (LoadFocus mit k6 oder JMeter).

API-Payloads at Scale mit LoadFocus testen

Wenn Sie APIs load-testen und realistische, parametrisierte Payloads aus mehreren Regionen senden müssen, läuft LoadFocus JMeter- und k6-Scripts aus 25+ Cloud-Regionen mit bis zu 12.500 VUs. Registrieren bei loadfocus.com/signup — keine Kreditkarte — und führen Sie Ihren ersten Payload-Lasttest in unter 5 Minuten aus.