Wie gestaltest du konsistente Error-Responses und meldest Validierungsfehler?

Question

IT Interview Practice · Accepted Answer

Eine gute Error-Response tut zwei Dinge: sie verwendet den **richtigen HTTP-Statuscode** (das maschinenlesbare Signal) und gibt einen **konsistenten, strukturierten Body** zurück, mit dem ein Entwickler etwas anfangen kann. Inkonsistente Error-Formen sind eine der größten Quellen für clientseitigen Schmerz.

## Verwende ein Standard-Error-Format: RFC 7807 (problem+json)

RFC 7807 definiert einen Standard-"Problem Details"-Body mit einem dedizierten Media-Type, sodass jeder Fehler in deiner API gleich aussieht:

```http
HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/not-found",
  "title": "Resource not found",
  "status": 404,
  "detail": "No user exists with id 999",
  "instance": "/users/999"
}
```

- `type` — ein URI, der die Fehlerkategorie identifiziert (auf Docs dereferenzierbar).
- `title` — eine kurze, menschenlesbare Zusammenfassung (stabil pro `type`).
- `status` — der HTTP-Status, zur Bequemlichkeit gespiegelt.
- `detail` — eine spezifische Erklärung für *dieses* Vorkommnis.
- `instance` — bei welchem Request/welcher Ressource es passiert ist.

## Validierungsfehler: alle auf einmal melden

Für Formular-/Feldvalidierung gib `422` (oder `400`) und ein **Array von Feldfehlern** zurück, damit der Client jedes fehlerhafte Feld in einem Durchgang hervorheben kann — nicht einen Fehler nach dem anderen:

```http
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation failed",
  "status": 422,
  "errors": [
    { "field": "email", "code": "invalid_format", "message": "must be a valid email" },
    { "field": "age",   "code": "out_of_range",   "message": "must be >= 18" }
  ]
}
```

## Prinzipien

```text
✓ Same body shape for every error (one code path on the client)
✓ A stable machine-readable code (type/code) — clients branch on this, not on prose
✓ Human-readable message for developers/logs
✗ Never leak stack traces, SQL, or internal paths to clients
```

## Warum es wichtig ist

Error-Design ist der Punkt, an dem APIs in der realen Welt leise gelingen oder scheitern: der Happy Path ist einfach, aber Konsumenten verbringen die meiste ihrer Debugging-Zeit im Fehlerpfad, und ein inkonsistenter oder vager Fehler-Contract macht die Integration miserabel. Interviewer prüfen damit zwei Dinge. Erstens, **Statuscode plus strukturierter Body im Zusammenspiel** — der Status ist das grobe Signal für Tooling und Retries, der Body trägt das handlungsrelevante Detail — statt des Anti-Patterns `200 OK` mit einem Fehler darin. Zweitens, ein **stabiler, maschinenlesbarer Error-Code** (über RFC 7807's `type` oder ein `code`-Feld), damit Clients auf `"insufficient_funds"` verzweigen können, statt eine englische Nachricht per String-Matching abzugleichen, die umformuliert oder lokalisiert werden könnte. Alle Validierungsfehler auf einmal zurückzugeben und niemals interne Details wie Stack Traces preiszugeben, rundet eine Antwort ab, die zeigt, dass du APIs gebaut hast, die andere Teams tatsächlich konsumieren mussten.

Verwende ein Standard-Error-Format: RFC 7807 (problem+json)

Validierungsfehler: alle auf einmal melden

Prinzipien

Warum es wichtig ist

Ähnliche Fragen