Panduan Lengkap Kode Status HTTP
Kode status HTTP menunjukkan hasil pemrosesan permintaan server web. Mereka dikelompokkan ke dalam lima kelas, masing-masing mewakili kategori respons yang berbeda. Memahami kode-kode ini sangat penting bagi pengembang web, perancang API, administrator sistem, dan siapa pun yang bekerja dengan teknologi web. Kode status memungkinkan klien — apakah browser, aplikasi seluler, atau server lain — untuk memahami apa yang terjadi dengan permintaan mereka dan bagaimana melanjutkannya.
Cara Kerja Kode Status HTTP
Ketika klien mengirim permintaan HTTP ke server, server merespons dengan kode status tiga digit diikuti oleh frase alasan yang dapat dibaca manusia. Digit pertama dari kode status mendefinisikan kelas respons. Dua digit sisanya tidak memiliki peran kategorisasi khusus tetapi memberikan granularitas dalam setiap kelas. Kode status ditentukan oleh Internet Assigned Numbers Authority (IANA) berdasarkan spesifikasi yang diterbitkan dalam dokumen RFC. Pada tahun 2025, ada lebih dari 70 kode status HTTP yang terdaftar secara resmi, meskipun hanya sekitar 30-40 yang umum digunakan.
Referensi Cepat
| Kelas | Kategori | Arti |
|---|---|---|
| 1xx | Informasional | Permintaan diterima, melanjutkan pemrosesan |
| 2xx | Sukses | Permintaan diterima, dipahami, dan diterima |
| 3xx | Pengalihan | Tindakan lebih lanjut diperlukan untuk menyelesaikan permintaan |
| 4xx | Kesalahan Klien | Permintaan memiliki sintaks buruk atau tidak dapat dipenuhi |
| 5xx | Kesalahan Server | Server gagal memenuhi permintaan yang valid |
1xx - Informasional
Kode ini menunjukkan bahwa server telah menerima header permintaan dan klien harus melanjutkan mengirim body, atau bahwa server beralih ke protokol yang berbeda. Ini adalah respons sementara tanpa konten body yang sebenarnya.
| Kode | Nama | Deskripsi |
|---|---|---|
| 100 | Lanjutkan | Server menerima header, klien harus melanjutkan mengirim body |
| 101 | Beralih Protokol | Server beralih protokol (misalnya, upgrade ke WebSocket) |
| 102 | Memproses | Server sedang memproses permintaan tetapi belum ada respons (WebDAV) |
| 103 | Petunjuk Awal | Preload sumber daya sementara server menyiapkan respons, digunakan untuk optimasi kinerja |
Status 100 Continue sering digunakan bersama dengan header permintaan Expect: 100-continue. Ketika klien mengirim header ini, ia menunggu konfirmasi sebelum mengirim payload besar. Ini mencegah pemborosan bandwidth ketika server akan menolak permintaan berdasarkan header saja.
101 Switching Protocols adalah landasan koneksi WebSocket. Ketika klien mengirim header Upgrade: websocket, server merespons dengan 101 untuk mengonfirmasi peralihan protokol dari HTTP ke WebSocket, memungkinkan komunikasi dua arah waktu nyata.
103 Early Hints adalah tambahan yang relatif baru (RFC 8297) yang memungkinkan server mengirim petunjuk ke browser tentang sumber daya kritis (CSS, JavaScript, font) yang akan dibutuhkan oleh respons akhir. Ini memungkinkan browser untuk mulai memuat sumber daya ini sebelum respons penuh siap, meningkatkan kinerja yang dirasakan.
2xx - Sukses
Kode ini menunjukkan bahwa permintaan klien berhasil diterima, dipahami, dan diterima. Ini adalah kategori yang setiap pengembang harapkan untuk dilihat.
| Kode | Nama | Deskripsi |
|---|---|---|
| 200 | OK | Respons sukses standar untuk permintaan GET, POST, PUT |
| 201 | Dibuat | Sumber daya berhasil dibuat, biasanya sebagai respons terhadap POST |
| 202 | Diterima | Permintaan diterima untuk diproses tetapi belum selesai |
| 203 | Info Non-Otoritatif | Respons dari sumber pihak ketiga, bukan server asal |
| 204 | Tidak Ada Konten | Sukses, tetapi tidak ada body respons untuk dikembalikan |
| 205 | Atur Ulang Konten | Memberi tahu browser untuk membersihkan formulir/dokumen saat ini |
| 206 | Konten Sebagian | Sumber daya sebagian dikembalikan, digunakan untuk permintaan rentang dan unduhan yang dapat dilanjutkan |
| 207 | Multi-Status | Beberapa kode status untuk beberapa sumber daya (WebDAV) |
| 208 | Sudah Dilaporkan | Sumber daya sudah dilaporkan (WebDAV) |
200 OK adalah kode status yang paling umum. Ini menunjukkan bahwa permintaan berhasil dan body respons berisi data yang diminta. Untuk permintaan GET, body berisi representasi sumber daya. Untuk permintaan POST, body berisi hasil dari tindakan.
201 Created harus dikembalikan ketika sumber daya baru dibuat sebagai hasil dari permintaan POST atau PUT. Respons harus menyertakan header Location yang menunjuk ke URL sumber daya yang baru dibuat. Misalnya, setelah membuat pengguna baru, kembalikan 201 Created dengan URL profil pengguna di header Location.
204 No Content berguna untuk permintaan DELETE atau pembaruan PUT di mana body respons kosong. Ini memberi tahu klien bahwa operasi berhasil tetapi tidak ada yang perlu dikembalikan. Browser tidak boleh mengubah tampilan dokumen saat ini.
3xx - Pengalihan
Kode ini menunjukkan bahwa klien perlu mengambil tindakan tambahan untuk menyelesaikan permintaan, biasanya dengan mengikuti pengalihan ke URL yang berbeda.
| Kode | Nama | Deskripsi |
|---|---|---|
| 300 | Banyak Pilihan | Beberapa kemungkinan representasi, klien harus memilih |
| 301 | Dipindahkan Permanen | Sumber daya memiliki URL permanen baru, perbarui bookmark |
| 302 | Ditemukan | Pengalihan sementara, tetap gunakan URL asli di masa depan |
| 303 | Lihat Lainnya | Pengalihan ke URL berbeda menggunakan metode GET |
| 304 | Tidak Dimodifikasi | Sumber daya tidak dimodifikasi, gunakan versi cache |
| 307 | Pengalihan Sementara | Pengalihan sementara yang mempertahankan metode HTTP |
| 308 | Pengalihan Permanen | Pengalihan permanen yang mempertahankan metode HTTP |
Perbedaan antara 301 dan 302 sangat penting untuk SEO. Mesin pencari memperlakukan pengalihan 301 sebagai permanen, mentransfer kekuatan peringkat URL asli ke URL baru. Pengalihan 302 tidak mentransfer nilai SEO karena URL asli diharapkan kembali.
304 Not Modified digunakan bersama dengan header permintaan kondisional seperti If-Modified-Since atau If-None-Match (ETag). Ketika klien memiliki versi cache dari sumber daya, ia dapat bertanya kepada server apakah sumber daya telah berubah. Jika belum, server mengembalikan 304 tanpa body, menghemat bandwidth di kedua sisi.
307 dan 308 mempertahankan metode HTTP yang digunakan dalam permintaan asli, tidak seperti 302 dan 301 yang dapat mengubah POST menjadi GET. Perbedaan ini penting untuk endpoint API di mana mempertahankan metode permintaan sangat penting.
4xx - Kesalahan Klien
Kode ini menunjukkan bahwa klien mengirim permintaan yang bermasalah. Kesalahan ada di sisi klien — server bekerja dengan benar.
| Kode | Nama | Deskripsi |
|---|---|---|
| 400 | Permintaan Buruk | Sintaks atau parameter permintaan tidak valid |
| 401 | Tidak Diotorisasi | Autentikasi diperlukan atau telah gagal |
| 402 | Pembayaran Diperlukan | Dicadangkan untuk penggunaan di masa depan, jarang diimplementasikan |
| 403 | Dilarang | Klien terautentikasi tetapi tidak memiliki izin |
| 404 | Tidak Ditemukan | Sumber daya yang diminta tidak ada |
| 405 | Metode Tidak Diizinkan | Metode HTTP tidak didukung untuk URL ini |
| 406 | Tidak Dapat Diterima | Tidak dapat menghasilkan respons yang cocok dengan header Accept |
| 407 | Autentikasi Proksi | Harus mengautentikasi dengan proksi terlebih dahulu |
| 408 | Waktu Permintaan Habis | Server kehabisan waktu menunggu permintaan |
| 409 | Konflik | Permintaan bertentangan dengan status server saat ini |
| 410 | Hilang | Sumber daya dihapus secara permanen, tidak ada alamat penerusan |
| 411 | Panjang Diperlukan | Header Content-Length diperlukan |
| 412 | Prasyarat Gagal | Header permintaan kondisional bernilai false |
| 413 | Payload Terlalu Besar | Body permintaan melebihi batas server |
| 414 | URI Terlalu Panjang | URL melebihi panjang maksimum yang diizinkan server |
| 415 | Tipe Media Tidak Didukung | Content-Type tidak didukung oleh server |
| 416 | Rentang Tidak Memuaskan | Header Range tidak dapat dipenuhi |
| 417 | Ekspektasi Gagal | Header Expect tidak dapat dipenuhi |
| 422 | Entitas Tidak Dapat Diproses | Body permintaan benar secara sintaks tetapi tidak valid secara semantik |
| 423 | Terkunci | Sumber daya terkunci (WebDAV) |
| 424 | Dependensi Gagal | Permintaan gagal karena permintaan lain gagal (WebDAV) |
| 426 | Upgrade Diperlukan | Klien harus beralih ke protokol yang berbeda |
| 428 | Prasyarat Diperlukan | Server asal memerlukan permintaan bersyarat |
| 429 | Terlalu Banyak Permintaan | Klien telah melebihi batas tingkat |
| 431 | Header Permintaan Terlalu Besar | Header melebihi ukuran maksimum |
| 451 | Tidak Tersedia Karena Alasan Hukum | Sumber daya diblokir karena tuntutan hukum |
400 Bad Request adalah tangkapan semua untuk kesalahan klien. Gunakan ketika server tidak dapat memproses permintaan karena sintaks yang salah, parameter query tidak valid, atau body permintaan yang salah bentuk. Selalu sertakan pesan kesalahan deskriptif dalam body respons untuk membantu klien memperbaiki masalah.
401 Unauthorized dikembalikan ketika klien belum memberikan kredensial autentikasi yang valid. Respons harus menyertakan header WWW-Authenticate yang menunjukkan skema autentikasi (Basic, Bearer, Digest, dll.) yang diharapkan server.
403 Forbidden berbeda dari 401 karena klien terautentikasi tetapi tidak memiliki izin yang cukup. Misalnya, pengguna biasa yang mencoba mengakses endpoint admin harus mendapatkan 403, bukan 401.
404 Not Found adalah kode status HTTP yang paling terkenal. Ini menunjukkan server tidak dapat menemukan sumber daya yang diminta. Berhati-hatilah untuk tidak mengungkapkan apakah sumber daya ada tetapi disembunyikan — mengembalikan 404 untuk sumber daya yang tidak ada dan yang disembunyikan adalah praktik keamanan umum.
409 Conflict berguna untuk REST API ketika ada konflik versi. Misalnya, ketika permintaan PUT memperbarui sumber daya yang telah dimodifikasi oleh pengguna lain sejak klien terakhir mengambilnya.
429 Too Many Requests sangat penting untuk pembatasan tingkat API. Ini harus menyertakan header Retry-After yang menunjukkan berapa lama klien harus menunggu sebelum membuat permintaan lagi.
5xx - Kesalahan Server
Kode ini menunjukkan bahwa server menemui kesalahan saat memproses permintaan yang valid. Masalah ada di sisi server.
| Kode | Nama | Deskripsi |
|---|---|---|
| 500 | Kesalahan Server Internal | Kesalahan server umum, tidak ada detail spesifik yang tersedia |
| 501 | Tidak Diimplementasikan | Server tidak mendukung fungsionalitas yang diminta |
| 502 | Gateway Buruk | Server hulu mengembalikan respons yang tidak valid |
| 503 | Layanan Tidak Tersedia | Server untuk sementara tidak tersedia (kelebihan beban atau down) |
| 504 | Gateway Timeout | Server hulu tidak merespons tepat waktu |
| 505 | Versi HTTP Tidak Didukung | Server tidak mendukung versi protokol HTTP yang digunakan |
| 506 | Varian Juga Bernegosiasi | Kesalahan konfigurasi server dalam negosiasi konten |
| 507 | Penyimpanan Tidak Mencukupi | Server tidak dapat menyimpan representasi (WebDAV) |
| 508 | Deteksi Perulangan | Server mendeteksi perulangan tak terbatas (WebDAV) |
| 509 | Batas Bandwidth Terlampaui | Bukan status resmi, digunakan oleh beberapa modul Apache |
| 510 | Tidak Diperpanjang | Ekstensi lebih lanjut diperlukan untuk permintaan |
| 511 | Autentikasi Jaringan Diperlukan | Klien harus mengautentikasi untuk mengakses jaringan |
500 Internal Server Error adalah tangkapan semua untuk kegagalan sisi server. Ini tidak boleh pernah dikembalikan untuk permintaan klien yang tidak valid — itu harus menggunakan kode 4xx. Respons 500 menunjukkan ada yang salah dengan logika pemrosesan server.
502 Bad Gateway biasanya terjadi ketika proksi atau load balancer menerima respons yang tidak valid dari server hulu. Misalnya, jika server aplikasi crash atau mengembalikan respons yang salah bentuk, reverse proksi mengembalikan 502 ke klien.
503 Service Unavailable digunakan ketika server untuk sementara kelebihan beban atau down untuk pemeliharaan. Sertakan header Retry-After sehingga klien dan crawler tahu kapan harus mencoba lagi. Ini sering terlihat selama jendela penerapan atau lonjakan lalu lintas.
504 Gateway Timeout terjadi ketika satu server dalam rantai (misalnya, reverse proksi yang berbicara ke server aplikasi) tidak menerima respons tepat waktu dari server lain. Timeout default biasanya 30-120 detik tergantung pada infrastruktur.
Panduan Penggunaan Kode Status
| Skenario | Kode Status |
|---|---|
| Permintaan GET berhasil | 200 |
| POST berhasil (dibuat) | 201 |
| DELETE berhasil | 204 |
| Validasi formulir gagal | 422 |
| Pengguna belum masuk | 401 |
| Pengguna tidak memiliki izin | 403 |
| Sumber daya tidak ditemukan | 404 |
| Batas tingkat terlampaui | 429 |
| Server crash | 500 |
| Endpoint API belum diimplementasikan | 501 |
| Pemeliharaan sementara | 503 |
Praktik Terbaik untuk Menggunakan Kode Status HTTP
Selalu gunakan kode status yang paling spesifik yang berlaku untuk situasi Anda. Mengembalikan kesalahan 500 generik ketika 503 atau 504 lebih tepat membuat debugging lebih sulit bagi konsumen API. Sertakan pesan kesalahan deskriptif dan pengidentifikasi kesalahan unik dalam body respons Anda untuk membantu debugging. Untuk REST API, pertimbangkan juga untuk menyertakan kode kesalahan yang dapat dibaca mesin yang dapat ditangani klien secara terprogram. Terakhir, pastikan respons kesalahan Anda menghormati tipe konten yang diminta melalui negosiasi konten — kembalikan JSON untuk klien API dan HTML untuk halaman kesalahan berbasis browser.
Gunakan alat HTTP Status Code Reference untuk pencarian cepat setiap kali Anda perlu mengingat arti atau penggunaan yang tepat dari kode status HTTP.
