HTTP Status 300 - Multiple Choices

Der HTTP-Status-Code 300 Multiple Choices signalisiert, dass die angefragte Resource multiple Representations hat und der Client eine bevorzugte Variante wählen soll. Response enthält Liste von verfügbaren Optionen mit URIs. Selten verwendet, da automatische Content Negotiation bevorzugt wird.

Typ

Response-Status-Code

Syntax

Der Status Code wird mit Liste von verfügbaren Resource-URIs zurückgegeben.

http 
HTTP/1.1 300 Multiple Choices
Location: /preferred-variant

Direktiven

Der 300 Multiple Choices Status Code wird für explizite Content Negotiation verwendet.

Multiple Representations
Resource existiert in mehreren Varianten (verschiedene Formate, Sprachen, Encodings). Response enthält Liste im Body, typischerweise HTML mit Links zu jeder Variante.
Location Header
Optional kann Location Header auf bevorzugte Variante zeigen. Client kann dieser Empfehlung folgen oder andere Variante aus Liste wählen.
User Choice
Im Gegensatz zu 301/302 Redirects erfolgt keine automatische Weiterleitung. User Agent sollte User Choice ermöglichen (z.B. Browser zeigt Link-Liste).

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für Status 300.

Beispiel 1 Multiple Format Options

http 
GET /api/report HTTP/1.1
Host: api.example.com

HTTP/1.1 300 Multiple Choices
Location: /api/report.pdf
Content-Type: text/html

<html>
<body>
  <h1>Available Formats</h1>
  <ul>
    <li><a href="/api/report.pdf">PDF (recommended)</a></li>
    <li><a href="/api/report.xlsx">Excel</a></li>
    <li><a href="/api/report.csv">CSV</a></li>
  </ul>
</body>
</html>

Beispiel 2 Language Selection

http 
GET /docs/manual HTTP/1.1
Host: help.example.com

HTTP/1.1 300 Multiple Choices
Location: /docs/manual/en
Vary: Accept-Language
Content-Type: application/json

{
  "available_languages": [
    {"lang": "en", "url": "/docs/manual/en", "name": "English"},
    {"lang": "de", "url": "/docs/manual/de", "name": "Deutsch"},
    {"lang": "fr", "url": "/docs/manual/fr", "name": "Français"}
  ]
}

Beispiel 3 API Version Selection

http 
GET /api/data HTTP/1.1
Host: api.example.com

HTTP/1.1 300 Multiple Choices
Content-Type: application/json

{
  "message": "Multiple API versions available",
  "versions": [
    {"version": "v2", "url": "/api/v2/data", "status": "stable"},
    {"version": "v3", "url": "/api/v3/data", "status": "beta"}
  ],
  "deprecated": [
    {"version": "v1", "url": "/api/v1/data", "sunset": "2026-01-01"}
  ]
}

Multiple Choices Selection Flow

Client erhält 300 Multiple Choices und wählt Resource Variant

Vorteile für die Systemarchitektur

  • Explicit User Choice: Gibt User explizite Kontrolle über Resource-Variante statt automatischer Content Negotiation. Nützlich wenn keine klare Präferenz ableitbar (Accept Headers fehlen/ambiguous).
  • API Versioning Transparency: Kann für API-Versioning genutzt werden, um Clients auf verfügbare Versionen hinzuweisen. Besonders bei Breaking Changes mit Migration-Pfaden.
  • Format Discovery: Client erfährt, welche Representations verfügbar sind. Kann für API-Dokumentation und Capability Discovery verwendet werden (HATEOAS-Prinzip).

Spezifikation

RFC 9110, Section 15.4.1 – HTTP Semantics https://www.rfc-editor.org/rfc/rfc9110.html#name-300-multiple-choices

Weitere Spezifikationen

Location Header, HTTP Status 301 - Moved Permanently