Status 400: Bedah Validasi Input API

Formulir yang ditolak kasir

Kamu mengisi formulir pendaftaran, tapi kasir mengembalikannya: "nama kosong, tanggal lahir salah format." Kasir tidak memproses formulir rusak; ia menjelaskan apa yang salah agar kamu bisa perbaiki. Status 400 Bad Request adalah "pengembalian formulir" versi HTTP: server menolak request karena datanya tidak valid, dan memberitahu persis apa yang salah.

Kenapa format error validasi itu penting

Validasi buruk hanya menjawab "error" tanpa penjelasan, memaksa frontend menebak. Validasi baik menjawab dengan struktur yang bisa diproses kode: field mana yang salah, kenapa salah. Ini memisahkan API profesional dari API asal jadi, dan menghemat ratusan jam debugging lintas tim.

Contoh 1: error validasi per field

POST /api/daftar HTTP/1.1
Host: toko.contoh.id
Content-Type: application/json

{"nama": "", "email": "bukan-email", "umur": "tua"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Validasi gagal",
  "details": [
    {"field": "nama", "message": "Nama wajib diisi"},
    {"field": "email", "message": "Format email tidak valid"},
    {"field": "umur", "message": "Umur harus berupa angka"}
  ]
}

Frontend bisa langsung memetakan setiap pesan ke input yang sesuai dan menampilkannya di bawah field. Satu response, semua masalah terungkap sekaligus.

Contoh 2: format standar RFC 7807

Untuk konsistensi lintas API, ada standar bernama Problem Details:

{
  "type": "https://api.contoh.id/docs/validasi",
  "title": "Validasi gagal",
  "status": 400,
  "detail": "Field email tidak valid",
  "instance": "/api/daftar"
}

Setiap error punya type (link dokumentasi), title (ringkasan), dan detail (penjelasan spesifik). Klien generik bisa menangani semua error dengan satu pola tanpa tahu detail tiap endpoint.

Kesalahan umum

Salah: satu pesan generik untuk semua error. "Terjadi kesalahan" tidak membantu siapa pun. Yang benar: sebutkan field dan alasan spesifik.

Salah: memakai 400 untuk error autentikasi. Token hilang itu 401, bukan 400. Yang benar: 400 khusus untuk data tidak valid, bukan untuk masalah identitas.

Salah: validasi hanya di frontend. User bisa mematikan JavaScript atau memanggil API langsung. Yang benar: validasi di frontend untuk UX, validasi di backend untuk keamanan. Keduanya wajib.

Salah: membocorkan info sensitif di pesan error. "Email ini sudah terdaftar" memberi tahu peretas email mana yang punya akun. Yang benar: untuk kasus sensitif, pakai pesan netral seperti "jika email terdaftar, kami kirim instruksi".

Kapan 400, kapan 422?

Standar lama memakai 400 untuk semua validasi. Standar modern (misalnya Rails, banyak API baru) memakai 422 Unprocessable Entity khusus untuk "format benar tapi isi tidak valid", sementara 400 untuk "format request rusak" (JSON tidak valid, sintaks salah).

POST /api/daftar
Content-Type: application/json

{bukan json valid}
// -> 400: body bahkan tidak bisa di-parse

{"email": "bukan-email"}
// -> 422: JSON valid, tapi isi tidak lolos validasi

Pilih satu konvensi dan konsisten. Yang penting: frontend tahu cara membedakan "request rusak" vs "data ditolak".

Catatan teknis: Di frontend, pola terbaik adalah memetakan details menjadi objek {nama: "pesan", email: "pesan"} lalu render di bawah masing-masing input. Jangan tampilkan semua error dalam satu alert.