Hvordan designer du konsistente error-responses og rapporterer valideringsfejl?

Question

IT Interview Practice · Accepted Answer

Et godt error-response gør to ting: det bruger den **rigtige HTTP-status-kode** (det maskinlæsbare signal), og det returnerer en **konsistent, struktureret body**, som en udvikler kan handle på. Inkonsistente error-former er en af de største kilder til smerte på client-siden.

## Brug et standard-error-format: RFC 7807 (problem+json)

RFC 7807 definerer en standard-"problem details"-body med en dedikeret media type, så hver fejl på tværs af din API ser ens ud:

```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` — en URI, der identificerer fejlkategorien (kan dereferences til dokumentation).
- `title` — et kort, menneskelæsbart resumé (stabilt per `type`).
- `status` — HTTP-statussen, gengivet for nemheds skyld.
- `detail` — en specifik forklaring for *denne* forekomst.
- `instance` — hvilken request/resource det skete på.

## Valideringsfejl: rapportér dem alle på én gang

Ved form-/felt-validering, returnér `422` (eller `400`) og et **array af felt-fejl**, så clienten kan fremhæve hvert dårligt felt i én omgang — ikke én fejl ad gangen:

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

## Principper

```text
✓ Samme body-form for hver fejl (én kodesti på clienten)
✓ En stabil maskinlæsbar kode (type/code) — clients forgrener sig på denne, ikke på prosa
✓ Menneskelæsbar besked til udviklere/logs
✗ Læk aldrig stack traces, SQL eller interne stier til clients
```

## Hvorfor det betyder noget

Error-design er der, hvor APIs stille og roligt lykkes eller fejler i den virkelige verden: the happy path er let, men forbrugere bruger det meste af deres debugging-tid på error-stien, og en inkonsistent eller vag error-kontrakt gør integration elendig. Interviewere bruger dette til at tjekke to ting. For det første, **at status-kode plus struktureret body arbejder sammen** — statussen er det grove signal for tooling og retries, body'en bærer den handlingsrettede detalje — frem for anti-mønsteret med `200 OK` med en fejl indeni. For det andet, en **stabil, maskinlæsbar error-kode** (via RFC 7807's `type` eller et `code`-felt), så clients kan forgrene sig på `"insufficient_funds"` frem for streng-matching af en engelsk besked, der måske omformuleres eller lokaliseres. At returnere alle valideringsfejl på én gang, og aldrig lække interne detaljer som stack traces, fuldender et svar, der viser, at du har bygget APIs, andre teams faktisk skulle forbruge.

Brug et standard-error-format: RFC 7807 (problem+json)

Valideringsfejl: rapportér dem alle på én gang

Principper

Hvorfor det betyder noget

Relaterede spørgsmål