status-code4xxerrorMenengah4 mnt baca

Status 4xx: Kesalahan di Pihak Client

Memahami 400, 401, 403, 404, 422, dan 429, plus cara menampilkan pesan error yang ramah ke user.

Salah pesan di restoran

Kamu memesan "kopi tubruk", pelayan menjawab "menu itu tidak ada." Atau kamu mau bayar tapi lupa bawa dompet. Dua-duanya salah di pihakmu (klien), bukan dapurnya (server). Keluarga status 4xx berarti persis itu: request-mu yang bermasalah, perbaiki request-nya, bukan servernya.

Kenapa 4xx harus dibedakan dari 5xx

Pemisahan ini menghemat waktu debugging luar biasa. Melihat 4xx, kamu langsung tahu: yang salah adalah request yang dikirim, jadi periksa URL, parameter, atau token. Melihat 5xx, kamu tahu servernya yang bermasalah. Tanpa pemisahan ini, setiap error harus ditebak-tebak sumbernya.

Contoh 1: 404 dan 400

http

GET /api/produk/99999 HTTP/1.1
Host: toko.contoh.id

http

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "Produk dengan id 99999 tidak ditemukan"}

404 berarti alamatnya tidak ada. Contoh kedua, data yang dikirim tidak valid:

http

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

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

http

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

{"error": "Nama wajib diisi", "field": "nama"}

400 berarti request-nya rusak atau tidak valid. Perhatikan API yang baik selalu menjelaskan apa yang salah di body, bukan sekadar angka.

Contoh 2: 401 vs 403, si kembar yang membingungkan

http

GET /api/profil HTTP/1.1
Host: toko.contoh.id

Tanpa token:

http

HTTP/1.1 401 Unauthorized

401 berarti "kamu belum memperkenalkan diri." Solusinya: login dan kirim token. Dengan token tapi bukan admin mengakses halaman admin:

http

HTTP/1.1 403 Forbidden

403 berarti "saya tahu siapa kamu, tapi kamu tidak boleh masuk." Solusinya bukan login ulang, melainkan minta akses yang sesuai. Cara mengingat: 401 soal identitas, 403 soal izin.

Kesalahan umum

Salah: mengira 404 selalu salah frontend. Bisa juga backend belum membuat endpoint-nya atau salah deploy. Yang benar: konfirmasi ke dokumentasi API sebelum menyalahkan kode sendiri.

Salah: mengabaikan body error. Body 4xx biasanya berisi penjelasan persis apa yang salah. Yang benar: selalu baca error di body, tampilkan pesan yang ramah ke user, dan log detailnya untuk developer.

Salah: menampilkan pesan teknis mentah ke user. "Validation failed on field email" membingungkan orang awam. Yang benar: terjemahkan menjadi "Email yang kamu masukkan tidak valid" di UI.

Catatan teknis: Ada juga 405 Method Not Allowed (method salah untuk endpoint itu) dan 429 Too Many Requests (kebanyakan request, dibahas di modul rate limit). Saat membuat API sendiri, pilih 4xx yang paling spesifik agar klien tidak menebak-nebak.

Tantangan

Tangani 404 dengan anggun

Buat fungsi ambilProduk(id) yang:

Fetch ke https://jsonplaceholder.typicode.com/posts/{id}.
Jika status 404, kembalikan object { error: "Produk tidak ditemukan" } (jangan throw!).
Jika sukses, kembalikan datanya.
Untuk status error lain, throw Error dengan pesan yang jelas.

Uji dengan id 1 (ada) dan id 999999 (tidak ada). Jelaskan kenapa 404 ditangani khusus, bukan dilempar sebagai error generik.

<!doctype html>
<html>
<head>
<meta charset="utf-8" />

</head>
<body>
<h1>Halo JS</h1>
<p>Buka console preview untuk melihat output.</p>
<script src="index.js"></script>
</body>
</html>

Open Sandbox