Hvordan designer du konsistente feilresponser og rapporterer valideringsfeil?

Question

IT Interview Practice · Accepted Answer

En god feilrespons gjør to ting: den bruker **riktig HTTP-statuskode** (det maskinlesbare signalet), og den returnerer en **konsistent, strukturert body** som en utvikler kan handle på. Inkonsistente feilformer er en av de største kildene til smerte på klientsiden.

## Bruk et standard feilformat: RFC 7807 (problem+json)

RFC 7807 definerer en standard "problem details"-body med en dedikert media type, så hver feil på tvers av API-et ditt ser lik ut:

```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 som identifiserer feilkategorien (kan dereferereres til dokumentasjon).
- `title` — et kort, menneskelesbart sammendrag (stabilt per `type`).
- `status` — HTTP-statusen, speilet for bekvemmelighet.
- `detail` — en spesifikk forklaring for *denne* forekomsten.
- `instance` — hvilken request/ressurs det skjedde på.

## Valideringsfeil: rapportér alle på én gang

For skjema-/feltvalidering, returner `422` (eller `400`) og et **array av feltfeil** slik at klienten kan fremheve hvert dårlige felt i én omgang — ikke én feil om 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" }
  ]
}
```

## Prinsipper

```text
✓ Samme body-form for hver feil (én kodesti på klienten)
✓ En stabil maskinlesbar kode (type/code) — klienter forgrener på denne, ikke på prosa
✓ Menneskelesbar melding for utviklere/logger
✗ Aldri lekk stack traces, SQL eller interne stier til klienter
```

## Hvorfor det er viktig

Feildesign er der API-er stille lykkes eller feiler i den virkelige verden: happy path er enkel, men konsumenter bruker mesteparten av feilsøkingstiden sin i feilstien, og en inkonsistent eller vag feilkontrakt gjør integrasjon elendig. Intervjuere bruker dette til å sjekke to ting. For det første **statuskode pluss strukturert body som samvirker** — statusen er det grove signalet for verktøy og retries, body-en bærer den handlingsrettede detaljen — snarere enn anti-mønsteret med `200 OK` med en feil inni. For det andre en **stabil, maskinlesbar feilkode** (via RFC 7807 sin `type` eller et `code`-felt) slik at klienter kan forgrene på `"insufficient_funds"` i stedet for å strengmatche en engelsk melding som kan bli omformulert eller lokalisert. Å returnere alle valideringsfeil på én gang, og aldri lekke interne detaljer som stack traces, fullfører et svar som viser at du har bygget API-er andre team faktisk måtte bruke.

Bruk et standard feilformat: RFC 7807 (problem+json)

Valideringsfeil: rapportér alle på én gang

Prinsipper

Hvorfor det er viktig

Relaterte spørsmål