Kepiye carane ngrancang error response sing konsisten lan nglaporake error validasi?

Question

IT Interview Practice · Accepted Answer

Error response sing apik nindakake rong perkara: nganggo **HTTP status code sing bener** (sinyal sing bisa diwaca mesin), lan mbalekake **body sing terstruktur lan konsisten** sing bisa ditindakake pangembang. Wangun error sing ora konsisten iku salah siji sumber lara paling gedhe ing sisih client.

## Nganggo format error standar: RFC 7807 (problem+json)

RFC 7807 nemtokake body "problem details" standar kanthi media type khusus, saengga saben error ing saindenging API-mu katon padha:

```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` — URI sing ngidentifikasi kategori error (bisa di-dereference menyang dokumentasi).
- `title` — ringkesan cendhak sing bisa diwaca manungsa (stabil saben `type`).
- `status` — status HTTP, dibalekake maneh kanggo penak.
- `detail` — panjelasan spesifik kanggo kedadeyan *iki*.
- `instance` — request/resource endi sing ngalami.

## Error validasi: laporke kabeh bebarengan

Kanggo validasi form/field, balekake `422` (utawa `400`) lan **array error saben field** supaya client bisa nyorot saben field sing salah ing sepisanan — dudu siji error saben wektu:

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

## Prinsip

```text
✓ Wangun body sing padha kanggo saben error (siji jalur kode ing client)
✓ Kode sing bisa diwaca mesin lan stabil (type/code) — client mbranchi miturut iki, dudu miturut prosa
✓ Pesen sing bisa diwaca manungsa kanggo pangembang/log
✗ Aja tau mbocorake stack trace, SQL, utawa path internal menyang client
```

## Kenapa iki penting

Desain error iku papan API kanthi meneng sukses utawa gagal ing donya nyata: happy path iku gampang, nanging konsumen ngentekake sapérangan gedhe wektu debug ing jalur error, lan kontrak error sing ora konsisten utawa kabur ndadekake integrasi sengsara. Pewawancara nganggo iki kanggo mriksa rong perkara. Kapisan, **status code plus body terstruktur kerja bareng** — status iku sinyal kasar kanggo tooling lan retry, body nggawa detail sing bisa ditindakake — tinimbang anti-pola `200 OK` kanthi error ing njero. Kapindho, **kode error sing stabil, bisa diwaca mesin** (liwat `type` RFC 7807 utawa field `code`) supaya client bisa mbranchi miturut `"insufficient_funds"` tinimbang nyocogake string pesen basa Inggris sing bisa diowahi tembunge utawa dilokalisasi. Mbalekake kabeh error validasi bebarengan, lan ora tau mbocorake detail internal kaya stack trace, nyampurnakake jawaban sing nuduhake yen kowe wis mbangun API sing tim liya pancen kudu nganggo.

Nganggo format error standar: RFC 7807 (problem+json)

Error validasi: laporke kabeh bebarengan

Prinsip

Kenapa iki penting

Pitakon sing gegandhengan