status-code5xxerrorretryMenengah4 mnt baca

Status 5xx: Kesalahan di Pihak Server

Arti 500, 502, 503, 504, dan strategi retry yang benar saat server bermasalah.

Dapur restoran yang kebakaran

Kamu memesan dengan benar, pelayan mencatat dengan benar, tapi dari dapur terdengar bunyi ledakan. Bukan salahmu, bukan salah pelayan: dapurnya yang bermasalah. Keluarga status 5xx berarti persis itu: request-mu sudah benar, tapi server gagal memprosesnya.

Kenapa 5xx harus ada

Tanpa 5xx, klien tidak bisa membedakan "request saya salah" (4xx) dengan "servernya yang rusak". Pembedaan ini penting untuk frontend: saat menerima 5xx, aplikasi boleh mencoba lagi (retry) karena masalahnya mungkin sementara. Saat menerima 4xx, retry tidak ada gunanya karena request-nya memang salah.

Contoh 1: 500, si paling umum

http
GET /api/produk HTTP/1.1
Host: toko.contoh.id
http
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error": "Terjadi kesalahan di server"}

500 berarti ada bug atau crash di sisi server: database mati, kode error, atau konfigurasi salah. Sebagai frontend developer, kamu tidak bisa memperbaikinya, tapi kamu wajib menanganinya: tampilkan pesan ramah, bukan halaman putih.

Contoh 2: 502 dan 503

Server modern sering berlapis: Nginx di depan, aplikasi di belakang. Kalau aplikasi belakangnya mati:

http
HTTP/1.1 502 Bad Gateway

502 berarti "penjaga depan tidak bisa menghubungi dapur." Sedangkan saat server sengaja dimatikan untuk maintenance:

http
HTTP/1.1 503 Service Unavailable
Retry-After: 120

503 berarti "tutup sementara, coba lagi nanti." Header Retry-After bahkan memberitahu kapan boleh mencoba lagi (120 detik). API yang baik memakai 503 saat maintenance, bukan 500.

Kesalahan umum

Salah: menampilkan stack trace ke user. Pesan seperti "NullPointerException at line 42" membocorkan isi dapurmu ke publik dan bisa dimanfaatkan peretas. Yang benar: log detailnya di server, tampilkan pesan umum ke user.

Salah: retry membabi buta saat 500. Request yang sama dikirim puluhan kali dalam sedetik justru memperparah server yang sekarat. Yang benar: retry dengan jeda bertambah (exponential backoff) dan batas maksimal percobaan.

Salah: mengembalikan 200 dengan body error. Sebagian API "malas" selalu menjawab 200 lalu menaruh {"success": false} di body. Yang benar: pakai status code sebagaimana mestinya, agar klien, proxy, dan monitoring bisa bekerja otomatis.

Yang bisa dilakukan frontend saat server down

Frontend tidak bisa memperbaiki server, tapi bisa menjaga pengalaman:

  1. Simpan draf user ke localStorage sebelum request, pulihkan saat gagal.
  2. Tampilkan status sistem: banner "server bermasalah, kami sedang perbaiki" lebih baik dari halaman mati.
  3. Antrekan aksi penting: untuk aplikasi offline-first, simpan request gagal dan kirim ulang saat server pulih.
  4. Jangan spam retry: satu tombol "coba lagi" manual lebih baik dari 50 retry otomatis yang memperparah keadaan.

Aplikasi yang anggun saat gagal terasa lebih profesional daripada aplikasi yang sempurna hanya saat semua berjalan lancar.

Catatan teknis: Sebagai frontend developer, aturan praktisnya: 4xx tampilkan pesan sesuai masalahnya (minta user perbaiki input), 5xx tampilkan pesan "coba lagi nanti" plus tombol retry. Jangan pernah biarkan user menatap halaman kosong tanpa penjelasan.

Tantangan

Simulasikan retry dengan backoff

Buat fungsi fetchDenganRetry(url, percobaan) seperti contoh di materi, lalu uji dengan URL ini yang selalu gagal: https://httpbin.org/status/503.

  1. Catat jeda waktu antar percobaan (gunakan Date.now() sebelum tiap fetch dan hitung selisihnya).
  2. Pastikan totalnya 3 percobaan lalu melempar error.
  3. Jelaskan kenapa backoff exponential (1s, 2s, 4s) lebih baik daripada jeda tetap 1 detik untuk server yang sedang overload.
<!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 on CodeSandboxOpen Sandbox