Kode Status HTTP

Sebuah Standar dengan Tiga Dekade Pergeseran

Kode status HTTP telah melewati beberapa generasi spesifikasi. RFC 1945 (Mei 1996) menstandarisasi HTTP/1.0 dengan kategori dasar 1xx-5xx. RFC 2616 (Juni 1999) menghadirkan HTTP/1.1 dan menjadi referensi kanonik selama lebih dari satu dekade. Seri 7230-7235 (Juni 2014) membagi HTTP/1.1 menjadi beberapa spesifikasi berdasarkan topik. Standar konsolidasi saat ini adalah RFC 9110 «HTTP Semantics» (Juni 2022), yang mengusangkan pembagian 7230-7235 dan merupakan kutipan yang tepat untuk pekerjaan modern. Registri live lengkap dari kode yang ditetapkan ada di registri kode status HTTP IANA.

Lima Kategori Sekilas

• 1xx Informational: respons sementara. Permintaan telah diterima dan server terus memprosesnya. Jarang dalam praktik; berguna untuk peningkatan protokol dan 103 Early Hints modern (yang memungkinkan server memuat sumber daya kritis sebelum respons penuh siap).
• 2xx Success: permintaan diterima, dipahami, dan diterima. 200 OK adalah kasus sehari-hari; 201 Created untuk pembuatan sumber daya; 204 No Content untuk tindakan sukses tanpa apa pun untuk dikembalikan.
• 3xx Redirection: diperlukan tindakan lebih lanjut. Pengalihan klasik (301 Moved Permanently, 302 Found, 307 Temporary Redirect, 308 Permanent Redirect) ditambah 304 Not Modified untuk validasi cache.
• 4xx Client Error: klien melakukan sesuatu yang salah: sintaks buruk, autentikasi yang hilang, meminta sesuatu yang tidak ada. Kategori terbesar dalam lalu lintas dunia nyata.
• 5xx Server Error: server yang bermasalah. Permintaannya valid; server hanya tidak bisa mengantarnya. Inilah yang membangunkan insinyur on-call.

Perbandingan «vs» yang Membingungkan Semua Orang

401 vs 403. Pasangan yang paling membingungkan. 401 Unauthorized berarti «Anda belum diautentikasi, coba masuk» (namanya secara teknis menyesatkan, ini tentang autentikasi, bukan otorisasi). 403 Forbidden berarti «Anda sudah diautentikasi, tetapi Anda tidak diizinkan melakukan ini», kredensial Anda valid tetapi tidak memberikan akses ke sumber daya ini. Kesalahan umum: mengembalikan 403 untuk permintaan yang tidak diautentikasi ketika 401 dengan header WWW-Authenticate yang benar.

301 vs 302 vs 307 vs 308. Dua sumbu, permanen vs sementara, dan perilaku preservasi metode:

Jika Anda mengalihkan permintaan GET untuk tujuan SEO, 301 adalah pilihan konvensional. Jika Anda mengalihkan permintaan POST atau PUT dan ingin metode dipertahankan, Anda memerlukan 307 atau 308.

400 vs 422. 400 Bad Request adalah untuk permintaan yang cacat secara sintaksis, JSON tidak valid, header yang diperlukan hilang, parameter kueri yang salah bentuk. 422 Unprocessable Entity (awalnya kode WebDAV, diadopsi secara luas oleh REST API) adalah untuk permintaan yang valid secara sintaksis dengan masalah semantik, JSON diurai dengan benar, tetapi nilainya gagal validasi bisnis (kuantitas negatif pada pesanan, email sudah digunakan). Banyak API menggunakan keduanya.

502 vs 503 vs 504. Tiga mode kegagalan upstream yang berbeda:

• 502 Bad Gateway: proksi/gateway menerima respons tidak valid dari server upstream.
• 503 Service Unavailable: server kelebihan beban atau dalam pemeliharaan. Sering dipasangkan dengan header Retry-After.
• 504 Gateway Timeout: server upstream tidak merespons tepat waktu.

404 vs 410. 404 Not Found adalah «kami tidak tahu apakah ini ada atau tidak.» 410 Gone adalah «ini pernah ada, sekarang dihapus secara permanen.» Dampak SEO: Google memperlakukan 410 sebagai sinyal yang lebih kuat bahwa konten tidak tersedia secara permanen dan menghapusnya dari indeks lebih cepat daripada 404.

Konvensi REST API

REST API modern telah menyepakati sekumpulan konvensi yang cukup konsisten tentang apa arti kode status untuk tindakan tertentu:

Implikasi SEO

• 200 OK: Google mengindeks halaman secara normal.
• 301 Moved Permanently: Google memperbarui URL yang diindeks ke yang baru dan mentransfer sinyal peringkat.
• 302 Found / 307 Temporary Redirect: Google mempertahankan URL asli yang diindeks; peringkat tetap dengan yang asli.
• 308 Permanent Redirect: Google memperlakukannya seperti 301: peringkat ditransfer.
• 304 Not Modified: digunakan oleh Googlebot untuk permintaan kondisional; memberi sinyal bahwa konten yang di-cache dapat digunakan kembali.
• 404 Not Found: Google menghapus URL dari indeksnya setelah beberapa kali crawl.
• 410 Gone: Google menghapus URL lebih cepat dari 404; sinyal «dihapus secara permanen» yang lebih kuat.
• 503 Service Unavailable dengan Retry-After: memberi tahu Googlebot untuk kembali lagi nanti. Gunakan selama jendela pemeliharaan; hindari penggunaan 503 untuk error nyata (Google menginterpretasikan 503 yang berlanjut sebagai instruksi untuk tidak melakukan crawl).
• 5xx yang berlanjut: Google mengurangi kecepatan crawl dan pada akhirnya dapat sepenuhnya menghapus URL dari indeks.

Kode-kode Terkenal & Budaya

• 418 I'm a teapot: lelucon April Mop dari RFC 2324 (Hyper Text Coffee Pot Control Protocol, 1 April 1998). Ketika IETF mengusulkan penghapusannya dari spesifikasi pada tahun 2017, kampanye «Save 418» berhasil mempertahankannya. Beberapa API menggunakannya sebagai penanda «this isn't real»; selainnya tidak berbahaya.
• 451 Unavailable For Legal Reasons: RFC 7725 (2015), dinamai setelah Fahrenheit 451 karya Ray Bradbury. Dikembalikan ketika konten disensor atas perintah pengadilan atau permintaan pemerintah.
• Seri 520-527 Cloudflare: non-standar, digunakan oleh Cloudflare untuk menunjukkan kegagalan koneksi server upstream tertentu. Umum ketika situs di balik Cloudflare mengalami masalah.
• Nginx's 444 No Response: spesifik untuk Nginx, dikembalikan ketika server menutup koneksi tanpa mengirimkan respons apa pun.
• 420 Enhance Your Calm historis Twitter: kode batas rate yang sudah dihapus yang digunakan oleh API Twitter sebelumnya; digantikan oleh standar 429.

Kesalahan Umum

1. Menggunakan 200 OK untuk error dengan error body. Mengembalikan {"error": "not found"} dengan status 200 membingungkan setiap lapisan caching, alat monitoring, dan client SDK. Gunakan kode status yang tepat.
2. Mengembalikan 403 untuk permintaan yang tidak diautentikasi. Kode yang tepat adalah 401 dengan header WWW-Authenticate.
3. Menggunakan 302 saat yang dimaksud adalah 301. Jika pemindahan bersifat permanen, mesin pencari membutuhkan 301 untuk mentransfer peringkat. 302 mempertahankan pengindeksan URL lama.
4. Menggunakan 301 atau 302 untuk pengalihan POST/PUT. Secara historis ini memungkinkan klien mengubah metode menjadi GET. 307 dan 308 secara ketat mempertahankan metode asli.
5. Mengembalikan 500 saat yang dimaksud adalah 503. Jika server kelebihan beban atau dalam pemeliharaan, 503 dengan Retry-After adalah sinyal yang tepat, baik untuk klien maupun untuk Googlebot.
6. Menggunakan 404 untuk halaman yang dihapus secara permanen. 410 Gone adalah sinyal yang lebih kuat dan dihapus dari indeks mesin pencari lebih cepat.
7. Melupakan header Location pada respons 201 dan 3xx. Header Location adalah yang memberi tahu klien di mana sumber daya baru berada atau ke mana harus diarahkan. Tanpanya, klien tidak dapat bernavigasi.

Pertanyaan yang Lebih Sering Diajukan

Kapan saya harus mengembalikan 422 alih-alih 400?

400 Bad Request berarti permintaan itu sendiri cacat, JSON tidak valid, header yang diperlukan hilang, parameter kueri yang salah bentuk. 422 Unprocessable Entity berarti permintaan sudah terbentuk dengan baik tetapi mengandung error semantik yang mencegah pemrosesan, field kuantitas yang diset ke angka negatif, alamat email yang sudah digunakan, tanggal di masa lalu untuk field yang hanya berlaku di masa depan. Konvensi REST API modern menyepakati pembagian ini, dengan sebagian besar API besar (GitHub, Stripe, Twilio) menggunakan 422 untuk error validasi.

Mengapa Cloudflare terkadang mengembalikan 520, 521, 522…?

Kode 520-527 adalah spesifik Cloudflare, menandakan berbagai cara edge mereka tidak dapat mencapai server origin Anda. 520 adalah generik «web server returned an unknown error»; 521 berarti origin Anda menolak koneksi; 522 adalah timeout koneksi ke origin Anda; 524 berarti origin Anda terlalu lama merespons. Kode-kode ini tidak ada di registri IANA tetapi sering ditemukan ketika situs di balik Cloudflare memiliki masalah backend.

Apakah browser saya akan menunjukkan kode mana yang dikembalikan API saya?

Ya, buka DevTools → tab Network, klik permintaan, dan lihat kolom «Status». Browser juga menampilkan halaman umum untuk beberapa kode (game dinosaurus pada kegagalan koneksi Chrome, halaman 404 / 500 standar); tetapi kode numerik aktual selalu ada dalam respons.

Apa itu 103 Early Hints?

Kode 1xx yang relatif baru (RFC 8297, 2017) yang memungkinkan server mengirim header Link: rel=preload sebelum respons penuh siap, memberi tahu browser untuk mulai mengambil sumber daya kritis (CSS, font, gambar) lebih awal. Kini didukung oleh Chrome dan dikirim oleh Cloudflare, Fastly, dan CDN lainnya sebagai optimasi kinerja.

Bisakah saya membuat kode status sendiri?

Secara teknis ya (HTTP mengizinkan kode 3-digit apa pun dalam rentang 100-599. Secara praktis tidak) klien, proksi, dan cache memperlakukan kode yang tidak dikenal berdasarkan digit pertamanya (jadi 4xx = error klien secara generik, 5xx = error server). Beberapa vendor melakukan ini (Cloudflare's 520s, Nginx's 444), tetapi kecuali Anda mengontrol kedua ujung saluran, tetaplah pada registri IANA. Membuat 299 tidak akan merusak apa pun tetapi juga tidak akan mengkomunikasikan apa pun.

Mengapa «kode status» disebut «status» dan bukan «kode error»?

Karena sebagian besar dari mereka bukanlah error. 200 OK adalah kode status yang paling banyak dikembalikan di dunia, artinya «semuanya berjalan lancar.» Kode-kode ini mengkomunikasikan status permintaan: sukses, pengalihan, error klien, error server. Menyebutnya «kode error» bias ke kasus negatif yang dicatat dan diperhatikan; kode sukses melakukan tugasnya secara diam-diam setiap mikrodetik.