Hur designar du konsekventa error responses och rapporterar valideringsfel?

Question

IT Interview Practice · Accepted Answer

En bra error response gör två saker: den använder **rätt HTTP status code** (den maskinläsbara signalen), och den returnerar en **konsekvent, strukturerad body** som en utvecklare kan agera på. Inkonsekventa error-former är en av de största källorna till smärta på client-sidan.

## Använd ett standard-error-format: RFC 7807 (problem+json)

RFC 7807 definierar en standard-"problem details"-body med en dedikerad media type, så att varje fel i hela ditt API ser likadant 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 identifierar felkategorin (dereferensbar till dokumentation).
- `title` — en kort, människoläsbar sammanfattning (stabil per `type`).
- `status` — HTTP-status, speglad för bekvämlighet.
- `detail` — en specifik förklaring för *denna* förekomst.
- `instance` — vilken request/resurs den hände på.

## Valideringsfel: rapportera dem alla på en gång

För form-/fältvalidering, returnera `422` (eller `400`) och en **array av fältfel** så att client:en kan markera varje dåligt fält i ett svep — inte ett fel i taget:

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

## Principer

```text
✓ Samma body-form för varje fel (en kodväg på client:en)
✓ En stabil maskinläsbar kod (type/code) — clients grenar på denna, inte på prosa
✓ Människoläsbart meddelande för utvecklare/loggar
✗ Läck aldrig stack traces, SQL, eller interna paths till clients
```

## Varför det är viktigt

Error-design är där API:er tyst lyckas eller misslyckas i verkligheten: the happy path är lätt, men konsumenter spenderar det mesta av sin felsökningstid i felvägen, och ett inkonsekvent eller vagt error-kontrakt gör integration eländig. Intervjuare använder detta för att kontrollera två saker. Först, **status code plus strukturerad body som fungerar tillsammans** — statusen är den grova signalen för verktyg och retries, body:n bär den handlingsbara detaljen — snarare än anti-mönstret `200 OK` med ett fel inuti. För det andra, en **stabil, maskinläsbar error-kod** (via RFC 7807:s `type` eller ett `code`-fält) så att clients kan grena på `"insufficient_funds"` snarare än att sträng-matcha ett engelskt meddelande som kan bli omformulerat eller lokaliserat. Att returnera alla valideringsfel på en gång, och att aldrig läcka interna detaljer som stack traces, avrundar ett svar som visar att du har byggt API:er som andra team faktiskt behövde konsumera.

Använd ett standard-error-format: RFC 7807 (problem+json)

Valideringsfel: rapportera dem alla på en gång

Principer

Varför det är viktigt

Relaterade frågor