Status 2xx: Semua yang Berarti Sukses
Bedanya 200, 201, 204, dan 206, plus kapan API-mu harus memakai masing-masing.
Lampu hijau di jalan raya
Status code adalah cara server menjawab "gimana hasil request-mu?" dalam tiga digit angka. Keluarga 2xx berarti sukses, seperti lampu hijau: silakan jalan, permintaanmu beres.
Kenapa angka, bukan kata? Karena angka bersifat universal. Server di Jepang dan browser di Indonesia tidak perlu sepakat soal bahasa, cukup sepakat soal angka. 200 selalu berarti sukses di mana pun.
Kenapa status code perlu ada
Tanpa status code, klien harus menebak hasil request dari isi body. Setiap API akan punya cara sendiri bilang "sukses" atau "gagal", dan setiap frontend harus belajar dialek masing-masing. Status code menyeragamkannya: angka pertama (2, 4, atau 5) langsung memberi tahu kategorinya, bahkan sebelum kamu membaca penjelasannya.
Contoh 1: 200 OK, si paling umum
GET /api/produk/1 HTTP/1.1
Host: toko.contoh.idHTTP/1.1 200 OK
Content-Type: application/json
{"id": 1, "nama": "Kopi Tubruk"}200 OK berarti "berhasil, dan ini datanya." Dipakai untuk GET yang sukses, juga untuk PUT/PATCH yang mengembalikan data hasil update.
Contoh 2: 201 dan 204, sukses yang lebih spesifik
Membuat data baru:
POST /api/produk HTTP/1.1
Host: toko.contoh.id
Content-Type: application/json
{"nama": "Kopi Susu"}HTTP/1.1 201 Created
{"id": 9, "nama": "Kopi Susu"}201 Created berarti "berhasil DIBUAT." Beda nuansa dengan 200: ada sesuatu yang baru lahir di server.
Menghapus data:
DELETE /api/produk/9 HTTP/1.1
Host: toko.contoh.idHTTP/1.1 204 No Content204 No Content berarti "berhasil, tidak ada yang perlu dikembalikan." Body-nya kosong, dan itu normal.
Kesalahan umum pemula
Salah: frontend hanya mengecek status === 200. Akibatnya response 201 dari POST dianggap gagal padahal sukses. Yang benar: anggap sukses untuk seluruh rentang 200-299, atau di JavaScript pakai response.ok yang sudah mencakup semuanya.
Salah: panik melihat body kosong pada 204. Itu memang disengaja. Yang benar: jangan panggil response.json() pada 204, karena tidak ada JSON untuk di-parse dan akan error.
Salah: memakai 200 untuk semua respons sukses di API sendiri. Bisa, tapi kurang informatif. Yang benar: 201 untuk "created", 204 untuk "sukses tanpa body". Klien API-mu akan berterima kasih karena tidak perlu menebak-nebak.
Salah: mengabaikan status dan langsung membaca body. Kalau server mengembalikan 500 dengan body HTML error, kode yang langsung parse JSON akan crash dengan pesan membingungkan. Yang benar: cek status dulu, baru tentukan cara membaca body.
Studi kasus: menangani semua 2xx di satu fungsi
Alih-alih mengecek status === 200 di setiap tempat, buat satu helper yang menangani seluruh keluarga 2xx dengan benar:
async function tanganiSukses(response) {
if (response.status === 204) {
return null; // tidak ada body, jangan parse
}
if (response.status === 201) {
const data = await response.json();
console.log("Data baru dibuat:", data.id);
return data;
}
if (response.ok) {
const contentType = response.headers.get("Content-Type") || "";
if (contentType.includes("application/json")) {
return await response.json();
}
return await response.text();
}
throw new Error("HTTP " + response.status);
}Fungsi ini menangani tiga skenario: 204 (langsung null tanpa parse), 201 (log khusus untuk data baru), dan 200 lainnya (parse sesuai Content-Type). Dengan helper ini, seluruh aplikasimu konsisten: tidak ada lagi bug "201 dianggap gagal" atau crash parse di 204.
Pola ini juga memudahkan testing: cukup mock objek response dengan status berbeda, tanpa perlu server sungguhan.
Satu anomali yang perlu kamu tahu: 204 No Content tidak boleh punya body MESKIPUN server mengirimnya; browser dan fetch akan mengabaikannya. Dan 201 Created idealnya menyertakan header Location berisi URL resource baru, misalnya Location: /api/produk/9, agar klien tahu di mana menemukan data yang baru dibuat.
Catatan teknis: Keluarga 2xx lengkapnya: 200 OK, 201 Created, 202 Accepted (diterima tapi diproses nanti), 204 No Content. Untuk sehari-hari, hafalkan tiga yang sering muncul; 202 akan terasa manfaatnya saat kamu belajar queue dan background job.
Tantangan
Bedakan 200, 201, 204 di fetch
Tulis kode fetch yang:
- GET ke
https://jsonplaceholder.typicode.com/posts/1dan cetak statusnya (harusnya 200). - POST ke
https://jsonplaceholder.typicode.com/postsdengan body JSON dan cetak statusnya (harusnya 201). - DELETE ke
https://jsonplaceholder.typicode.com/posts/1dan cetak statusnya.
Untuk tiap request, cetak juga res.ok. Apa kesimpulanmu tentang hubungan status code dan res.ok?
<!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>
Kuis Bab
Uji pemahamanmu: Bab 1: Dasar HTTP
Jawab 5 soal berikut, lalu tekan "Periksa Jawaban".
1.Apa kepanjangan HTTP dan apa peran utamanya?
2.Manakah pernyataan yang BENAR tentang method GET?
3.Kapan sebaiknya memakai PATCH daripada PUT?
4.Apa tujuan request OPTIONS otomatis (preflight) dari browser?
5.Response 201 Created sebaiknya menyertakan apa?