Bagaimana Anda mendesain error response yang konsisten dan melaporkan error validasi?

Question

IT Interview Practice · Accepted Answer

Sebuah error response yang baik melakukan dua hal: ia menggunakan **HTTP status code yang tepat** (sinyal yang dapat dibaca mesin), dan mengembalikan **body terstruktur yang konsisten** yang bisa ditindaklanjuti developer. Bentuk error yang tidak konsisten adalah salah satu sumber terbesar kesengsaraan di sisi client.

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

RFC 7807 mendefinisikan sebuah body "problem details" standar dengan media type khusus, sehingga setiap error di seluruh API Anda terlihat sama:

```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` — sebuah URI yang mengidentifikasi kategori error (dapat di-dereference ke dokumentasi).
- `title` — ringkasan singkat yang dapat dibaca manusia (stabil per `type`).
- `status` — status HTTP, dicerminkan demi kenyamanan.
- `detail` — penjelasan spesifik untuk kejadian *ini*.
- `instance` — request/resource mana yang mengalaminya.

## Error validasi: laporkan semuanya sekaligus

Untuk validasi form/field, kembalikan `422` (atau `400`) dan sebuah **array error per field** agar client bisa menyorot setiap field yang buruk dalam satu kali jalan — bukan satu error setiap kali:

```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
✓ 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
```

## Mengapa ini penting

Desain error adalah tempat API diam-diam berhasil atau gagal di dunia nyata: happy path itu mudah, tetapi konsumen menghabiskan sebagian besar waktu debugging mereka di jalur error, dan kontrak error yang tidak konsisten atau kabur membuat integrasi menyengsarakan. Pewawancara memakai ini untuk memeriksa dua hal. Pertama, **status code plus body terstruktur bekerja bersama** — status adalah sinyal kasar untuk tooling dan retry, body membawa detail yang dapat ditindaklanjuti — alih-alih anti-pattern `200 OK` dengan error di dalamnya. Kedua, sebuah **error code yang stabil dan dapat dibaca mesin** (melalui `type` milik RFC 7807 atau sebuah field `code`) agar client bisa bercabang pada `"insufficient_funds"` alih-alih mencocokkan string sebuah pesan bahasa Inggris yang mungkin ditulis ulang atau dilokalkan. Mengembalikan semua error validasi sekaligus, dan tidak pernah membocorkan detail internal seperti stack trace, melengkapi jawaban yang menunjukkan Anda telah membangun API yang benar-benar harus dikonsumsi tim lain.

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

Error validasi: laporkan semuanya sekaligus

Prinsip

Mengapa ini penting

Pertanyaan terkait