API Response Simulator
API Response Simulator
Simuliere HTTP-API-Antworten mit Status-Codes, Headern und JSON-Body. Mit Latenz-Simulation, Presets und Syntax-Highlighting.
Hinweis: Dieser Simulator erzeugt realistische API-Antworten zur Veranschaulichung. Es werden keine echten HTTP-Requests gesendet. Alle Daten dienen der Demonstration.
Inhaltsverzeichnis
Schnellübersicht
- HTTP-Methoden: GET, POST, PUT, PATCH, DELETE
- Status-Codes: 2xx, 3xx, 4xx, 5xx
- Response-Body: Realistisches JSON mit Syntax-Highlighting
- Header-Analyse: Content-Type, Cache-Control, etc.
- Latenz-Simulation: Realistische Response-Zeiten
- Presets: Typische API-Szenarien
- Theorie: Über REST, HTTP und Status-Codes
- FAQ: Häufige Fragen zu APIs
1. API Response Simulator
Wähle eine Methode, einen Status-Code und einen Endpunkt – die Antwort wird generiert.
2. Theorie – REST APIs
Verstehe die Grundlagen von HTTP APIs und Status-Codes.
Was ist eine REST API?
REST (Representational State Transfer) ist ein Architekturstil:
- Stateless: Jede Anfrage ist unabhängig
- Ressourcen: Daten als URL-Pfade
- HTTP-Methoden: GET, POST, PUT, DELETE
- JSON: Standard-Datenformat
- Status-Codes: Standardisierte Antworten
Status-Code-Klassen
HTTP-Status-Codes sind in 5 Klassen aufgeteilt:
- 1xx: Informationen (selten)
- 2xx: Erfolg (200, 201, 204)
- 3xx: Umleitung (301, 304)
- 4xx: Client-Fehler (400, 404)
- 5xx: Server-Fehler (500, 503)
HTTP-Methoden
Jede Methode hat eine spezifische Bedeutung:
- GET: Daten lesen (idempotent)
- POST: Neue Ressource erstellen
- PUT: Ressource ersetzen (idempotent)
- PATCH: Teilweise ändern
- DELETE: Ressource löschen
Best Practices
- Korrekte Status-Codes: Nicht alles 200
- Aussagekräftige Fehler: Klare Messages
- Versionierung: /api/v1/, /api/v2/
- Rate Limiting: Header mit X-RateLimit
- HATEOAS: Links zu verwandten Ressourcen
- Pagination: Bei großen Listen
Wussten Sie schon? Die HTTP-Status-Codes wurden 1999 in RFC 2616 standardisiert und 2014 in RFC 7231 aktualisiert. Es gibt etwa 60 verschiedene Codes – aber in der Praxis werden meist nur 15-20 verwendet. Der berühmteste ist wohl 404 Not Found – er wurde so populär, dass viele Websites eigene 404-Seiten mit Spielen und Illustrationen gestalten. Google zeigt bei 404 einen Roboter, GitHub eine Katze.
3. Geschichte der HTTP-APIs
Von HTTP/1.0 zu REST und modernen APIs.
HTTP/0.9
Tim Berners-Lee entwickelt HTTP am CERN. Einzige Methode: GET. Antworten sind nur HTML – keine Header, keine Status-Codes.
HTTP/1.0 (RFC 1945)
HTTP/1.0 wird standardisiert. Erste Status-Codes, Header und Methoden. Jede Anfrage öffnet eine neue TCP-Verbindung.
HTTP/1.1 (RFC 2068)
HTTP/1.1 mit persistenten Verbindungen, Chunked Encoding und Host-Header. Wird 15 Jahre lang Standard.
REST-Architektur
Roy Fielding beschreibt REST in seiner Dissertation. Stateless APIs mit HTTP-Methoden und Ressourcen-URLs werden populär.
JSON wird Standard
JSON (RFC 4627) ersetzt XML als Standard-Datenformat für APIs. Einfacher und schneller zu parsen.
HTTP/2 (RFC 7540)
HTTP/2 mit Multiplexing, Server Push und Header-Komprimierung. Deutlich schneller als HTTP/1.1.
GraphQL
Facebook veröffentlicht GraphQL. Alternative zu REST mit flexiblen Queries. Client bestimmt die Antwort-Struktur.
HTTP/3 (RFC 9114)
HTTP/3 basiert auf QUIC (UDP). Schnellere Verbindungen, weniger Latenz. Wird zunehmend von großen Websites verwendet.
4. FAQ – Häufige Fragen
Häufige Fragen zu APIs
| Merkmal | PUT | PATCH |
|---|---|---|
| Zweck | Vollständig ersetzen | Teilweise ändern |
| Request-Body | Alle Felder | Nur geänderte Felder |
| Idempotent | Ja | Nein (oft) |
| Beispiel | User mit allen Daten | Nur E-Mail ändern |
Faustregel:
- PUT: Alles überschreiben
- PATCH: Nur das Nötigste ändern
Empfehlungen nach Situation:
| Situation | Status-Code |
|---|---|
| Erfolgreiches GET | 200 OK |
| Neue Ressource erstellt | 201 Created |
| Erfolgreiches DELETE | 204 No Content |
| Ressource verschoben | 301 Moved Permanently |
| Ungültige Anfrage | 400 Bad Request |
| Nicht authentifiziert | 401 Unauthorized |
| Keine Berechtigung | 403 Forbidden |
| Nicht gefunden | 404 Not Found |
| Validierungsfehler | 422 Unprocessable Entity |
| Rate Limit überschritten | 429 Too Many Requests |
| Serverfehler | 500 Internal Server Error |
| Service nicht verfügbar | 503 Service Unavailable |
- 401 Unauthorized: Nicht eingeloggt / ungültiger Token
- 403 Forbidden: Eingeloggt, aber keine Berechtigung
Beispiele:
- 401: Kein Auth-Header, Token abgelaufen
- 403: Eingeloggt als User, versucht Admin-Endpoint
Merksatz:
- 401: "Wer bist du?"
- 403: "Ich kenne dich, aber du darfst nicht!"
Request-Header:
- Content-Type: Format des Bodys (application/json)
- Accept: Erwartetes Format
- Authorization: Bearer Token, API Key
- User-Agent: Client-Information
Response-Header:
- Content-Type: Format der Antwort
- Cache-Control: Caching-Regeln
- X-RateLimit-Limit: Max. Requests
- X-RateLimit-Remaining: Verbleibende
- Location: Bei 201 Created
- ETag: Cache-Validierung
Idempotent bedeutet: Gleiche Anfrage = gleiches Ergebnis, auch bei mehrfacher Ausführung:
| Methode | Idempotent |
|---|---|
| GET | ✓ Ja |
| PUT | ✓ Ja |
| DELETE | ✓ Ja |
| POST | ✗ Nein |
| PATCH | ✗ Oft nein |
Warum wichtig?
- Retry-Sicherheit: Bei Netzwerkfehler wiederholen
- Caching: GET kann gecacht werden
- Verständnis: Klare Semantik
| Merkmal | REST | GraphQL | gRPC |
|---|---|---|---|
| Format | JSON | JSON | Protobuf |
| Protokoll | HTTP/1.1 | HTTP/1.1 | HTTP/2 |
| Flexibilität | Fest | Sehr flexibel | Fest |
| Performance | Gut | Gut | Sehr gut |
| Verwendung | Standard Web | Moderne SPAs | Microservices |
Empfehlung:
- REST: Standard für Public APIs
- GraphQL: Bei komplexen Datenstrukturen
- gRPC: Bei internen Microservices
Versionierung ist wichtig, um Breaking Changes zu vermeiden:
3 Haupt-Strategien:
- URL-Pfad:
/api/v1/users(empfohlen) - Header:
Accept: application/vnd.api+json;version=1 - Query-Param:
/api/users?version=1
Best Practices:
- Semantic Versioning: Major.Minor.Patch
- Breaking Changes: Nur in Major-Version
- Deprecation: Alte Versionen 6-12 Monate unterstützen
- Dokumentation: Changelog führen
- Sunset-Header: Ablaufdatum kommunizieren
HATEOAS (Hypermedia as the Engine of Application State) ist ein REST-Prinzip:
- Idee: API-Antworten enthalten Links zu verwandten Aktionen
- Selbst-entdeckend: Client muss URLs nicht kennen
- Level 3 REST: Höchste Reife-Stufe
Beispiel:
{
"id": 42,
"name": "Max",
"_links": {
"self": { "href": "/users/42" },
"orders": { "href": "/users/42/orders" },
"delete": { "href": "/users/42", "method": "DELETE" }
}
}
Vorteil: Lose Kopplung, flexiblere Clients.
Nachteil: Komplexer, weniger verbreitet.
Zusammenfassung
Die wichtigsten Punkte
- REST: Architekturstil für APIs (stateless)
- HTTP-Methoden: GET, POST, PUT, PATCH, DELETE
- Status-Codes: 2xx Erfolg, 3xx Umleitung, 4xx Client, 5xx Server
- Wichtige Codes: 200, 201, 400, 401, 403, 404, 500
- 401 vs. 403: Nicht authentifiziert vs. keine Berechtigung
- PUT vs. PATCH: Vollständig ersetzen vs. teilweise ändern
- Idempotent: GET, PUT, DELETE
- JSON: Standard-Datenformat für APIs
- Versionierung: /api/v1/, /api/v2/
- Unser Tool: API-Simulator mit Status-Codes und Headern