Jenis-Jenis HTTP Status Code: Penjelasan Lengkap untuk Memahami Respons Server Web

1xx: Respons Informasi

Kode status kelas 1xx adalah yang paling jarang ditemui dalam pengembangan web sehari-hari, tetapi kode ini memiliki fungsi penting di tingkat protokol yang perlu dipahami. Kode-kode ini bersifat sementara — kode ini menunjukkan bahwa permintaan telah diterima dan dipahami, dan bahwa klien harus melanjutkan permintaan atau menunggu respons selanjutnya. Kode ini bukanlah jawaban akhir; kode ini adalah sinyal di tengah percakapan.

100 Continue

Kode status 100 Continue dirancang untuk menangani masalah efisiensi spesifik dalam HTTP. Ketika klien ingin mengirimkan badan permintaan yang besar — ​​unggahan file, pengiriman formulir yang besar, atau muatan JSON yang besar — ​​klien dapat terlebih dahulu mengirimkan header permintaan dan kemudian menunggu server untuk mengkonfirmasi bahwa server bersedia menerima badan permintaan sebelum mengirimkannya. Jika server akan menolak permintaan hanya berdasarkan header (misalnya, karena otentikasi gagal), klien menghemat biaya pengiriman muatan yang berpotensi besar yang akan dibuang.

101 Switching Protocols

Respons 101 Switching Protocols menunjukkan bahwa server telah setuju untuk beralih ke protokol yang berbeda, seperti yang diminta oleh klien melalui header Upgrade. Penggunaan kode ini yang paling umum di dunia nyata adalah jabat tangan WebSocket. Ketika browser atau klien ingin membuat koneksi WebSocket — yang memungkinkan komunikasi full-duplex dan persisten melalui satu koneksi TCP — ia memulai dengan permintaan HTTP dan header Upgrade: websocket. Jika server mendukung WebSocket dan menyetujui peningkatan tersebut, server akan merespons dengan 101 Switching Protocols, dan sejak saat itu koneksi beroperasi di bawah protokol WebSocket, bukan HTTP.

102 Processing

Didefinisikan dalam WebDAV (Web Distributed Authoring and Versioning), kode 102 Processing menunjukkan bahwa server telah menerima dan sedang memproses permintaan tetapi belum menyelesaikannya. Kode ini ada untuk mencegah klien kehabisan waktu (timeout) selama operasi WebDAV yang berjalan lama — misalnya, manipulasi sistem file yang kompleks, yang mungkin membutuhkan waktu lebih lama daripada ambang batas waktu HTTP biasa. Dengan mengirimkan 102 Processing secara berkala, server memberi sinyal kepada klien bahwa server masih aktif dan berfungsi. Kode ini jarang ditemui di luar aplikasi khusus WebDAV.

103 Early Hints

Kode 103 Early Hints adalah tambahan yang relatif baru pada spesifikasi HTTP dan mengatasi tantangan optimasi kinerja web modern. Ketika server membutuhkan waktu untuk menghasilkan respons HTML — melakukan kueri database, menjalankan logika sisi server, menyusun konten — browser biasanya akan diam menunggu respons sebelum mengetahui stylesheet CSS, file JavaScript, dan font apa yang dibutuhkan halaman tersebut.

2xx: Respons Sukses

Kode status kelas 2xx menunjukkan bahwa permintaan klien telah diterima, dipahami, dan diproses dengan sukses. Kode-kode ini mengkonfirmasi bahwa semuanya berjalan sesuai rencana, dan membawa nuansa semantik penting yang sangat berpengaruh pada desain API REST.

200 OK

Kode status 200 OK adalah respons yang paling umum di web. Ini berarti permintaan berhasil dan server mengembalikan sumber daya yang diminta atau hasil dari operasi yang diminta. Arti dari isi respons bergantung pada metode HTTP yang digunakan: untuk permintaan GET, isi respons berisi sumber daya yang diminta; untuk permintaan POST yang melakukan tindakan, isi respons berisi hasil dari tindakan tersebut; untuk permintaan DELETE, isi respons mungkin kosong atau berisi konfirmasi.

201 Created

Kode status 201 Created menunjukkan bahwa permintaan berhasil dan sumber daya baru telah dibuat sebagai hasilnya. Ini adalah respons yang benar untuk permintaan POST yang membuat sumber daya baru — membuat akun pengguna baru, mengirimkan pesanan, mengunggah file. Respons harus menyertakan header Lokasi yang berisi URL dari sumber daya yang baru dibuat, sehingga klien tahu di mana menemukan apa yang baru saja dibuat.

202 Accepted

Kode status 202 Accepted menunjukkan bahwa permintaan telah diterima untuk diproses tetapi pemrosesan belum selesai — dan mungkin tidak akan selesai pada saat respons dikirim. Ini adalah respons yang tepat untuk operasi asinkron, yaitu seperti pekerjaan latar belakang, tugas yang diantrekan, pengiriman email, pengkodean video, impor data besar, dan operasi lain di mana pekerjaan terjadi setelah respons HTTP dikembalikan.

Respons 202 biasanya menyertakan informasi dalam isi respons tentang bagaimana klien dapat memeriksa status operasi — ID pekerjaan, URL polling, atau URL webhook tempat hasilnya akan dikirimkan. Semantik utama dari 202 Accepted adalah bahwa server tidak menjamin keberhasilan akhir; server hanya mengkonfirmasi penerimaan dan memulai pekerjaan. Operasi mungkin masih gagal, dan klien membutuhkan mekanisme lain untuk mengetahui hasil akhirnya.

204 No Content

Kode status 204 No Content menunjukkan bahwa permintaan berhasil tetapi tidak ada konten yang dikembalikan dalam isi respons. Ini adalah respons yang tepat untuk operasi yang berhasil tetapi tidak menghasilkan output yang berarti untuk dikembalikan — permintaan DELETE yang menghapus sumber daya, permintaan PUT atau PATCH yang memperbarui sumber daya tanpa perlu mengembalikan versi yang diperbarui, atau tindakan POST tertentu yang memicu efek samping tanpa menghasilkan sumber daya baru.

Perbedaan teknis penting antara 204 No Content dan 200 OK dengan body kosong adalah bahwa 204 secara eksplisit menginstruksikan klien untuk tidak memperbarui tampilannya — klien tidak boleh beralih dari halaman saat ini, dan tidak boleh mengatur ulang statusnya saat ini. Browser dan klien API memperlakukan 204 secara berbeda dari 200 dengan body kosong karena alasan ini. Dalam aplikasi satu halaman di mana panggilan AJAX memperbarui sebagian konten halaman, mengembalikan 204 untuk operasi yang berhasil yang tidak perlu mengembalikan data adalah pola yang umum dan benar secara semantik.

206 Partial Content

Kode status 206 Partial Content dikembalikan ketika server memenuhi permintaan GET parsial — permintaan yang menyertakan header Range yang menentukan bahwa klien hanya menginginkan sebagian dari sumber daya yang diminta. Mekanisme ini mendasar bagi cara kerja unduhan yang dapat dilanjutkan dan streaming media.

Ketika unduhan file besar terhenti dan kemudian dilanjutkan, klien mengirimkan permintaan GET baru dengan header Range: bytes=10485760- yang menunjukkan bahwa klien telah memiliki 10 MB pertama dan hanya menginginkan sisanya. Server merespons dengan 206 Partial Content dan byte yang tersisa. Pendekatan ini menghindari pengunduhan ulang konten yang telah berhasil diterima. Pemutar media menggunakan 206 untuk streaming audio dan video: alih-alih mengunduh seluruh file video sebelum pemutaran dimulai, pemutar meminta beberapa detik pertama sebagai rentang, mulai memutar, dan meminta rentang berikutnya secara paralel, memungkinkan streaming yang lancar dengan buffering minimal.

3xx: Respons Pengalihan

Kode status kelas 3xx menunjukkan bahwa klien harus melakukan tindakan tambahan untuk menyelesaikan permintaan — khususnya, bahwa sumber daya yang diminta telah dipindahkan atau tersedia di lokasi yang berbeda. Kode pengalihan adalah salah satu yang terpenting untuk dipahami baik dalam pengembangan web maupun optimasi mesin pencari, karena kode spesifik yang digunakan menentukan bagaimana browser, mesin pencari, dan klien lain menangani pengalihan tersebut.

301 Moved Permanently

Kode status 301 Moved Permanently adalah pengalihan utama untuk perubahan URL permanen. Kode ini memberi tahu klien — dan yang terpenting, mesin pencari — bahwa sumber daya yang diminta telah dipindahkan secara permanen ke URL baru yang ditentukan dalam header Lokasi. Setelah menerima 301, browser menyimpan pengalihan tersebut dalam cache dan permintaan selanjutnya untuk URL lama langsung menuju ke URL baru tanpa perlu mengakses server lagi. Mesin pencari mentransfer "ekuitas tautan" (sinyal peringkat dan tautan balik) yang dikumpulkan oleh URL lama ke URL baru.

Sifat permanen dari 301 memiliki implikasi praktis yang penting. Pengalihan 301 memberi tahu mesin pencari untuk memperbarui indeks mereka dengan URL baru, berhenti merayapi URL lama, dan mentransfer semua sinyal peringkat. Ini menjadikannya pilihan yang tepat untuk restrukturisasi URL permanen, migrasi domain, transisi HTTP ke HTTPS, dan kanonisasi URL. Karena browser menyimpan pengalihan 301 secara agresif dalam cache, pengujian logika pengalihan dengan 301 selama pengembangan dapat menimbulkan masalah caching — lingkungan pengembangan biasanya menggunakan 302 hingga logika pengalihan dipastikan benar.

302 Found

Kode status 302 Found menunjukkan pengalihan sementara — sumber daya tersedia di URL yang ditentukan dalam header Lokasi, tetapi hanya untuk saat ini. Tidak seperti 301, 302 tidak menginstruksikan browser untuk menyimpan pengalihan dalam cache atau mesin pencari untuk memperbarui indeks mereka. URL asli tetap menjadi URL kanonik; pengalihan adalah jalan pintas sementara. Mesin pencari terus merayapi dan mengindeks URL asli daripada tujuan pengalihan.

Dalam praktiknya, 302 sering disalahgunakan. Banyak kerangka kerja web dan konfigurasi server secara default menggunakan kode 302 ketika developer bermaksud melakukan pengalihan permanen, yang menyebabkan masalah SEO di mana nilai tautan tidak ditransfer dengan benar. Perbedaan ini penting: gunakan 301 ketika perubahan URL bersifat permanen dan dimaksudkan untuk final, gunakan 302 ketika pengalihan benar-benar sementara — misalnya, mengalihkan pengguna yang terautentikasi ke halaman login sambil mempertahankan URL yang awalnya diminta untuk pengalihan setelah login, atau mengalihkan selama pengujian A/B.

303 See Other

Kode status 303 See Other dirancang khusus untuk menangani pola web umum: setelah pengiriman formulir atau permintaan POST lainnya yang memodifikasi status server, alihkan klien ke URL berbeda yang menampilkan hasilnya. Ini mengatasi masalah "POST ganda" — tanpa pengalihan setelah POST, menekan tombol kembali browser dan kemudian menyegarkan halaman akan mengirimkan kembali formulir, berpotensi membuat catatan duplikat atau mengulangi tindakan yang tidak diinginkan.

Perbedaan teknis penting dari 303 adalah bahwa ia secara eksplisit mengubah permintaan selanjutnya menjadi GET terlepas dari metode aslinya. Ketika klien menerima 303 setelah POST, ia mengambil URL di header Lokasi menggunakan GET. Ini adalah perilaku yang benar untuk pola Post-Redirect-Get (PRG), yang merupakan teknik mendasar dalam desain aplikasi web untuk mencegah pengiriman formulir duplikat. Sebagian besar kerangka kerja web sisi server menerapkan pola ini secara default dalam penanganan formulir mereka.

304 Not Modified

Kode status 304 Not Modified adalah dasar dari caching HTTP dan merupakan salah satu mekanisme optimasi kinerja terpenting di web. Ketika klien memiliki salinan sumber daya yang di-cache, klien dapat menyertakan header validasi caching dalam permintaannya — If-Modified-Since dengan stempel waktu versi yang di-cache, atau If-None-Match dengan ETag dari versi yang di-cache. Server memeriksa apakah sumber daya telah berubah sejak versi yang di-cache. Jika tidak berubah, server mengembalikan 304 Not Modified tanpa isi, dan klien menggunakan salinan yang di-cache.

Manfaat kinerja dari 304 sangat besar. Alih-alih mentransfer seluruh sumber daya — yang mungkin berupa file JavaScript besar, stylesheet, atau gambar — server hanya mengirimkan respons 304 yang kecil, dan klien menggunakan salinan yang sudah dimilikinya. Ini mengurangi konsumsi bandwidth, beban server, dan waktu pemuatan halaman secara bersamaan. Penerapan caching yang tepat dengan ETags dan header Last-Modified, dikombinasikan dengan penanganan 304 yang benar, adalah salah satu optimasi paling berdampak yang tersedia untuk aplikasi web.

307 Pengalihan Sementara

Kode status 307 Pengalihan Sementara mirip dengan 302 karena menunjukkan pengalihan sementara, tetapi dengan perbedaan penting: kode ini mengharuskan klien untuk mempertahankan metode permintaan asli saat mengikuti pengalihan. Jika permintaan POST menerima kode 307, klien harus mengirimkan POST ke URL pengalihan, bukan GET. Ini menjadikan 307 kode yang tepat untuk mengalihkan sementara permintaan non-GET sambil mempertahankan metode dan isi permintaan tersebut.

Ketelitian semantik ini penting dalam desain API. Jika titik akhir API sementara tidak tersedia dan permintaan perlu dialihkan ke titik akhir cadangan, menggunakan 307 memastikan bahwa permintaan POST, PUT, PATCH, dan DELETE mempertahankan metode yang benar di tujuan pengalihan. Menggunakan 302 dalam skenario yang sama akan secara diam-diam mengubah permintaan tersebut menjadi GET, yang kemungkinan akan gagal atau berperilaku tidak benar di tujuan pengalihan.

308 Pengalihan Permanen

Kode status 308 Pengalihan Permanen melengkapi kuartet pengalihan dengan menyediakan alternatif permanen yang mempertahankan metode, sebagai pelengkap 307. Seperti 301, kode ini menunjukkan pengalihan permanen dan menginstruksikan browser dan mesin pencari untuk memperbarui catatan mereka sesuai dengan itu. Seperti 307, kode ini mempertahankan metode permintaan asli — POST yang menerima kode 308 harus melakukan POST ke URL baru. Hal ini menjadikan 308 pilihan yang tepat untuk memindahkan endpoint API secara permanen yang menerima permintaan non-GET, memastikan bahwa perubahan permanen pada URL tidak secara diam-diam mengubah semantik permintaan.

4xx: Respons Kesalahan Klien

Kode status kelas 4xx menunjukkan bahwa klien melakukan kesalahan dalam permintaannya. Server menerima dan memahami permintaan tersebut tetapi menolak atau tidak dapat memenuhinya karena masalah dengan apa yang dikirim klien. Kode-kode ini sangat penting bagi developer API karena mengkomunikasikan secara tepat apa yang salah dilakukan klien, memungkinkan penanganan kesalahan yang jelas dan pesan kesalahan yang bermanfaat.

400 Bad Request

Kode status 400 Bad Request adalah respons kesalahan klien umum, yang dikembalikan ketika server tidak dapat memproses permintaan karena sintaks yang salah, parameter yang tidak valid, atau masalah tingkat permintaan lainnya yang tidak sesuai dengan kode kesalahan yang lebih spesifik. Penyebab umum termasuk JSON yang salah format dalam badan permintaan, parameter yang diperlukan hilang, tipe data yang tidak valid dalam string kueri, nilai parameter di luar rentang yang dapat diterima, atau badan permintaan yang melebihi batas ukuran.

401 Unauthorized

Terlepas dari namanya, 401 Unauthorized secara khusus berkaitan dengan autentikasi, bukan otorisasi. Ini berarti permintaan tersebut tidak memiliki kredensial autentikasi yang valid — klien belum mengidentifikasi dirinya, atau telah memberikan kredensial yang tidak valid, kedaluwarsa, atau dalam format yang salah. Server harus menyertakan header WWW-Authenticate yang menentukan skema autentikasi yang diharapkan, yang memberi tahu klien cara melakukan autentikasi.

Pertemuan praktis dengan 401 cukup umum: mengakses API yang dilindungi tanpa kunci API, memberikan JWT yang kedaluwarsa, menggunakan kata sandi yang salah, atau menghilangkan token Bearer dari header Otorisasi. Respons klien yang benar terhadap kode kesalahan 401 adalah melakukan autentikasi dan mencoba kembali permintaan dengan kredensial yang valid. Dalam aplikasi web, menerima kode kesalahan 401 dari API biasanya memicu pengalihan ke halaman login atau alur pembaruan token.

Kode status 402 Payment Required

Kode status 402 Payment Required memiliki sejarah yang menarik: awalnya kode ini dicadangkan untuk potensi penggunaan di masa mendatang dalam sistem pembayaran digital, tetapi mekanisme pembayaran tingkat protokol yang dimaksudkan tidak pernah distandarisasi. Akibatnya, 402 tidak digunakan secara formal dalam cara standar apa pun dan hanya muncul dalam implementasi non-standar dan spesifik aplikasi.

Beberapa API dan layanan menggunakan 402 untuk menunjukkan bahwa tindakan yang diminta memerlukan langganan berbayar atau bahwa pembayaran akun telah jatuh tempo. Stripe, misalnya, menggunakan 402 untuk menunjukkan bahwa pembayaran ditolak. GitHub menggunakannya untuk menunjukkan batasan paket. Ini adalah penggunaan kode yang masuk akal dan sesuai secara semantik tanpa adanya standar formal, dan pola umum "pembayaran diperlukan untuk memenuhi permintaan ini" sekarang menjadi arti de facto dari 402 dalam praktiknya.

403 Forbidden

Kode status 403 Forbidden berarti server memahami permintaan tersebut, mengetahui siapa yang mengajukannya (atau tidak perlu mengetahuinya), dan menolak untuk memenuhinya karena klien tidak memiliki izin. Tidak seperti 401, yang berkaitan dengan otentikasi, 403 berkaitan dengan otorisasi — identitas klien telah ditetapkan tetapi hak aksesnya tidak mencukupi.

Skenario umum untuk 403 meliputi pengguna yang telah diautentikasi mencoba mengakses data pribadi pengguna lain, akun tingkat gratis mencoba menggunakan fitur yang memerlukan paket berbayar, pengguna tanpa hak akses admin mencoba melakukan tindakan admin, atau permintaan dari alamat IP yang diblokir. Semantik utama dari 403 adalah bahwa otentikasi ulang tidak akan membantu — masalahnya bukan karena server tidak tahu siapa Anda, tetapi karena Anda tidak memiliki izin untuk melakukan apa yang Anda minta.

404 Not Found

Kode status 404 Not Found hampir pasti merupakan kode status HTTP yang paling terkenal, dikenali oleh sebagian besar pengguna internet bahkan jika mereka tidak dapat menyebutkan kode lain. Ini berarti server tidak dapat menemukan sumber daya yang diminta di URL yang ditentukan. Sumber daya tersebut mungkin tidak pernah ada, mungkin telah dihapus, atau URL-nya mungkin salah.

Hal penting yang perlu dipahami tentang 404 adalah bahwa kode ini tidak menyebutkan apakah sumber daya tersebut pernah ada atau apakah mungkin ada di masa mendatang. Ini adalah pernyataan tentang keadaan URL saat ini, bukan tentang riwayat atau ketersediaan sumber daya di masa mendatang. Perbedaan ini penting untuk pemeliharaan tautan: URL yang mengembalikan 404 bisa jadi URL yang diketik salah, tautan yang merujuk ke halaman yang dihapus, atau sumber daya yang memang tidak ada di server ini.

405 Method Not Allowed

Kode status 405 Method Not Allowed menunjukkan bahwa server mengetahui URL yang diminta tetapi tidak mendukung metode HTTP yang digunakan dalam permintaan. Server harus menyertakan header Allow yang mencantumkan metode yang diterimanya untuk sumber daya tersebut, sehingga klien mengetahui metode mana yang valid. Skenario umum adalah mencoba melakukan permintaan POST ke URL yang hanya mendukung GET, atau mengirimkan permintaan DELETE ke sumber daya yang hanya dapat dibaca.

406 Not Acceptable

Kode status 406 Not Acceptable dikembalikan ketika server tidak dapat menghasilkan respons dalam format apa pun yang ditunjukkan klien dapat diterima. Negosiasi konten HTTP memungkinkan klien untuk menentukan format respons pilihan mereka melalui header Accept — Accept: application/json untuk JSON, Accept: application/xml untuk XML, Accept: text/html untuk HTML. Jika server hanya dapat menghasilkan format yang bertentangan dengan preferensi yang dinyatakan klien, server akan mengembalikan 406.

408 Request Timeout

Kode status 408 Request Timeout menunjukkan bahwa server kehabisan waktu menunggu permintaan. Beberapa server mengirimkan respons ini pada koneksi yang tidak aktif untuk mengklaim kembali sumber daya. Klien dapat mengulangi permintaan tanpa modifikasi. Kode ini berbeda dari 504 Gateway Timeout — 408 berkaitan dengan server yang menunggu klien menyelesaikan permintaan, sedangkan 504 berkaitan dengan proxy atau gateway yang menunggu server upstream.

409 Conflict

Kode status 409 Conflict menunjukkan bahwa permintaan tidak dapat diselesaikan karena konflik dengan status sumber daya target saat ini. Ini adalah salah satu kode yang paling informatif secara semantik dalam rentang 4xx karena memberi tahu klien bahwa masalahnya bukan pada format permintaan atau izin, tetapi pada status logis data. Penyebab umum termasuk upaya untuk membuat sumber daya dengan pengidentifikasi yang sudah ada, mengirimkan pembaruan versi yang bertentangan dengan pembaruan bersamaan (konflik penguncian optimistik), atau mencoba mentransisikan sumber daya ke status yang tidak diizinkan oleh status saat ini.

410 Gone

Kode status 410 Gone adalah varian yang lebih spesifik dari 404 yang membawa makna eksplisit: sumber daya tersebut pernah ada di URL ini di masa lalu tetapi telah dihapus secara permanen dan tidak akan tersedia lagi. Tidak seperti 404, yang tidak menyebutkan riwayat, 410 adalah pernyataan eksplisit bahwa penghapusan tersebut disengaja dan permanen.

411 Length Required

Kode status 411 Length Required menunjukkan bahwa server menolak untuk menerima permintaan tanpa header Content-Length yang ditentukan. Hal ini terutama ditemui dalam skenario pengunggahan di mana server perlu mengetahui ukuran muatan yang masuk sebelum mulai memprosesnya — misalnya, untuk memvalidasinya terhadap batas ukuran maksimum atau untuk mengalokasikan ruang buffer yang sesuai. Solusinya mudah: sertakan header Content-Length dengan ukuran byte dari isi permintaan.

413 Content Too Large

Kode status 413 Content Too Large (sebelumnya disebut "Payload Too Large" dalam spesifikasi HTTP sebelumnya) menunjukkan bahwa isi permintaan lebih besar daripada yang bersedia atau mampu diproses oleh server. Server web, gateway API, dan kerangka kerja aplikasi biasanya memiliki batasan yang dapat dikonfigurasi pada ukuran isi permintaan, dan upaya untuk mengunggah konten yang melebihi batasan tersebut akan memicu respons 413. Server dapat menutup koneksi atau menyertakan header Retry-After jika kondisinya bersifat sementara.

414 URI Too Long

Kode status 414 URI Too Long menunjukkan bahwa URL yang dikirim klien lebih panjang daripada yang dapat diproses oleh server. Sebagian besar server web memiliki batas panjang URL maksimum — biasanya antara 2.048 dan 8.192 karakter — dan permintaan yang melebihi batas tersebut akan ditolak dengan kode 414. Hal ini paling sering terjadi ketika parameter yang seharusnya berada dalam badan permintaan ditempatkan secara tidak benar dalam string kueri, sehingga menghasilkan URL yang terlalu panjang.

415 Unsupported Media Type

Kode status 415 Unsupported Media Type menunjukkan bahwa server menolak permintaan karena format badan permintaan — yang ditentukan oleh header Content-Type — bukanlah format yang diterima server untuk endpoint ini. Jika server mengharapkan application/json tetapi klien mengirimkan application/xml, server akan mengembalikan kode 415. Ini adalah kebalikan dari kode 406 Tidak Dapat Diterima, yang menangani ketidaksesuaian format di sisi output.

422 Unprocessable Entity
Kode status 422 Unprocessable Entity telah menjadi salah satu kode terpenting dalam desain API modern, khususnya untuk API REST yang memvalidasi isi permintaan. Sementara 400 Bad Request mencakup masalah struktural atau sintaksis pada permintaan, 422 mencakup kegagalan validasi semantik — kasus di mana permintaan secara sintaksis benar tetapi konten gagal dalam validasi aturan bisnis.

429 Too Many Requests

Kode status 429 Too Many Requests dikembalikan ketika klien telah mengirimkan terlalu banyak permintaan dalam periode waktu tertentu — pembatasan laju permintaan sedang beraksi. Pembatasan laju permintaan melindungi API dan layanan web dari penyalahgunaan, mencegah klien individu memonopoli sumber daya server, dan memastikan penggunaan yang adil di semua klien. Respons 429 harus menyertakan header Retry-After yang menunjukkan kapan klien dapat membuat permintaan lain, atau keluarga header X-RateLimit-* (konvensi umum, meskipun tidak distandarisasi secara formal) yang menunjukkan batas laju permintaan, kuota yang tersisa, dan kapan batas tersebut diatur ulang.

451 Unavailable For Legal Reasons

Kode status 451 Unavailable For Legal Reasons secara resmi ditambahkan ke spesifikasi HTTP pada tahun 2015 dan memiliki nama yang sengaja bersifat sastra — merujuk pada "Fahrenheit 451" karya Ray Bradbury, novel tentang pembakaran buku. Kode ini dikembalikan ketika akses ke suatu sumber daya ditolak karena alasan hukum, seperti sensor pemerintah, perintah pengadilan, kepatuhan terhadap penghapusan DMCA, atau pembatasan lisensi geografis.

5xx: Respons Kesalahan Server

Kode status kelas 5xx menunjukkan bahwa server mengalami kesalahan saat mencoba memproses permintaan. Tidak seperti kesalahan 4xx, yang merupakan kesalahan klien, kesalahan 5xx adalah kesalahan server — klien membuat permintaan yang valid tetapi server gagal menanganinya dengan benar. Kode-kode inilah yang memicu peringatan dalam sistem pemantauan, membangunkan teknisi yang sedang bertugas, dan muncul dalam laporan insiden.

500 Internal Server Error

500 Internal Server Error adalah kode kegagalan sisi server generik, yang dikembalikan ketika server mengalami kondisi yang tidak terduga yang mencegahnya memenuhi permintaan. Ini adalah padanan server dari pengecualian yang tidak ditangani — sesuatu yang salah terjadi yang tidak diantisipasi oleh server dan tidak memiliki penanganan kesalahan khusus. Penyebabnya termasuk pengecualian yang tidak tertangkap dalam kode aplikasi, dereferensi penunjuk null, kegagalan kueri basis data yang menyebar ke lapisan HTTP, kondisi disk penuh, kehabisan memori, dan kesalahan konfigurasi.

501 Not Implemented

Kode status 501 Not Implemented menunjukkan bahwa server tidak mendukung fungsionalitas yang diperlukan untuk memenuhi permintaan. Penggunaan yang paling umum adalah menunjukkan bahwa metode HTTP tidak dikenali atau didukung — jika klien mengirimkan permintaan dengan metode yang sama sekali tidak dipahami oleh server (tidak hanya untuk sumber daya tertentu, tetapi di mana saja), server mengembalikan 501. Ini berbeda dari 405 Method Not Allowed, yang berarti metode tersebut dikenal tetapi tidak didukung untuk sumber daya yang diminta secara spesifik. Kode 501 berarti metode tersebut tidak dikenal atau belum diimplementasikan di server secara keseluruhan.

502 Bad Gateway

Kode status 502 Bad Gateway dikembalikan oleh proxy, load balancer, atau gateway ketika menerima respons yang tidak valid dari server upstream. Dalam arsitektur web tipikal di mana NGINX atau CDN berada di depan server aplikasi, 502 berarti proxy menerima sesuatu yang tidak diharapkan dari server aplikasi — HTTP yang salah format, respons kosong, atau koneksi yang ditutup sebelum respons lengkap dikirim.

503 Service Unavailable

Kode status 503 Service Unavailable menunjukkan bahwa server saat ini tidak dapat menangani permintaan, baik karena server tersebut sementara kelebihan beban atau sedang dalam pemeliharaan. Tidak seperti 500, yang menunjukkan kegagalan yang tidak terduga, 503 seringkali disengaja — server yang terlalu banyak beban mungkin sengaja mengembalikan 503 untuk mengurangi lalu lintas, dan server yang sedang menjalani pemeliharaan terencana mungkin mengembalikan 503 untuk memberi tahu klien bahwa server tersebut sementara offline.

504 Gateway Timeout

Kode status 504 Gateway Timeout dikembalikan oleh proxy, load balancer, atau gateway ketika tidak menerima respons tepat waktu dari server upstream. Proxy berhasil menghubungi server upstream, tetapi server upstream membutuhkan waktu terlalu lama untuk merespons, melebihi batas waktu yang dikonfigurasi pada proxy. Ini berbeda dari 408 Request Timeout (server kehabisan waktu menunggu klien) dan dari 503 (server tidak tersedia). Kode 504 berarti server upstream dapat dijangkau tetapi terlalu lambat.

505 HTTP Version Not Supported

Kode status 505 HTTP Version Not Supported menunjukkan bahwa server tidak mendukung versi HTTP yang digunakan dalam permintaan. Jika klien mengirimkan permintaan HTTP/3 ke server yang hanya mendukung HTTP/1.1 dan HTTP/2, server akan merespons dengan 505. Kode ini jarang ditemui dalam praktiknya karena server modern mendukung beberapa versi HTTP dan negosiasi versi yang sesuai biasanya terjadi pada tingkat protokol sebelum permintaan diproses.

507 Insufficient Storage

Kode status 507 Insufficient Storage, yang didefinisikan dalam ekstensi WebDAV untuk HTTP, menunjukkan bahwa server tidak dapat menyimpan representasi yang dibutuhkan untuk menyelesaikan permintaan karena ruang penyimpanan penuh atau telah mencapai batasnya. Ini berbeda dari 413 Konten Terlalu Besar, yang berkaitan dengan permintaan yang terlalu besar untuk kebijakan server; 507 berkaitan dengan server yang secara fisik kekurangan ruang penyimpanan untuk mengakomodasi permintaan terlepas dari kebijakan. Kode ini muncul dalam aplikasi WebDAV dan di beberapa API penyimpanan cloud yang memberlakukan kuota penyimpanan per akun.

508 Loop Detected

Kode status 508 Loop Detected, juga dari spesifikasi WebDAV, dikembalikan ketika server menghentikan operasi karena menemukan loop tak terbatas saat memproses permintaan dengan "Kedalaman: tak terhingga." Ini dapat terjadi dalam operasi WebDAV yang secara rekursif menelusuri pohon direktori ketika struktur direktori berisi referensi melingkar. Ini adalah mekanisme keamanan yang mencegah rekursi sisi server yang tak terkendali dari mengonsumsi sumber daya tak terbatas.

511 Network Authentication Required

Kode status 511 Network Authentication Required menunjukkan bahwa klien perlu melakukan autentikasi untuk mendapatkan akses jaringan — kode ini dirancang khusus untuk digunakan oleh sistem captive portal seperti yang digunakan di hotel, bandara, dan kedai kopi yang mengharuskan pengguna untuk masuk melalui antarmuka web sebelum memberikan akses internet. Ketika perangkat pengguna membuat permintaan ke server eksternal tetapi jaringan mencegatnya, captive portal dapat mengembalikan 511 untuk memberi tahu perangkat bahwa autentikasi diperlukan sebelum permintaan dapat dipenuhi. Hal ini memungkinkan perangkat lunak pendeteksi captive portal untuk membedakan persyaratan otentikasi tingkat jaringan dari kesalahan lainnya.

Jadi, kode status HTTP lebih dari sekadar nomor kesalahan yang dicari ketika terjadi kesalahan. Kode status HTTP adalah kosakata yang didefinisikan secara tepat untuk mengkomunikasikan hasil interaksi web — sebuah bahasa yang dipahami secara identik oleh browser, aplikasi seluler, klien API, CDN, penyeimbang beban, perayap mesin pencari, dan sistem pemantauan di seluruh dunia.