Buka sebuah situs, dan ada hal yang diam-diam dramatis terjadi di balik layar. Browser kamu mengirim pesan kecil melintasi internet yang intinya berbunyi “tolong kasih saya halaman ini”, lalu sebuah komputer yang tak pernah kamu temui mengirim pesan balik yang berbunyi “ini dia”. Tarik-ulur inilah jantung dari web, dan namanya: request dan response HTTP.
Kamu tidak perlu jadi insinyur jaringan untuk memahaminya. Begitu kamu bisa membayangkan kedua pesan ini beserta bagian-bagiannya, banyak sekali hal di pengembangan web yang tadinya terasa seperti sulap jadi masuk akal. Di artikel ini kita akan bongkar kedua pesan itu satu per satu, melihat contoh aslinya, dan membangun gambaran mental yang bisa kamu pakai sepanjang karier.
Web adalah sebuah percakapan
HTTP itu singkatan dari HyperText Transfer Protocol. “Protokol” sebenarnya cuma sekumpulan aturan yang sudah disepakati soal bagaimana dua pihak harus berbicara supaya saling paham. Bayangkan dua orang yang tidak punya bahasa yang sama, lalu sepakat di awal: “saya akan bertanya dengan format persis begini, kamu menjawab dengan format persis begitu.” HTTP adalah kesepakatan semacam itu, tapi untuk komputer.
Dua pihak ini biasa disebut client dan server. Client adalah pihak yang memulai percakapan dengan meminta sesuatu. Seringnya itu browser kamu, tapi bisa juga aplikasi di ponsel, atau program kecil yang berjalan di server. Server adalah komputer yang menyimpan sumber daya yang kamu inginkan, entah itu halaman web, gambar, atau data, lalu mengirimkannya balik.
CLIENT SERVER
(browser kamu) (acy-partner.com)
| |
| ----------- REQUEST -----------> |
| "GET halaman di /about" |
| |
| <---------- RESPONSE ----------- |
| "200 OK, ini HTML-nya" |
| |Satu hal penting: client selalu bicara duluan. Server tidak pernah tiba-tiba mengirimi kamu halaman tanpa diminta; ia hanya menjawab ketika ada yang bertanya. Setiap request mendapat tepat satu response. Tanya sekali, dapat satu jawaban. Ingat baik-baik ritme ini, karena ia menentukan segalanya.
Anatomi sebuah request
Request adalah pesan yang dikirim client. Ia punya sampai empat bagian, dan tiga yang pertama selalu ada.
1. Method
Method adalah satu kata yang menyatakan apa yang ingin kamu lakukan terhadap sumber daya itu. Ibarat kata kerja dalam sebuah kalimat. Yang paling sering dipakai gampang dihafal:
| Method | Artinya | Analogi sehari-hari |
|---|---|---|
| GET | Mengambil sumber daya, tanpa mengubah apa pun | Membaca halaman di buku |
| POST | Mengirim data baru untuk dibuat | Mengirim formulir baru lewat pos |
| PUT | Mengganti sumber daya secara utuh | Menukar seluruh dokumen |
| PATCH | Memperbarui sebagian sumber daya | Mengoreksi satu baris |
| DELETE | Menghapus sumber daya | Membuang sebuah berkas |
Saat kamu mengetik alamat web lalu menekan enter, browser mengirim request GET. Saat kamu mengisi formulir pendaftaran lalu klik kirim, biasanya yang dikirim adalah POST. Method memberi tahu server apa niatmu sebelum ia membaca apa pun yang lain.
2. Path
Path adalah bagian alamat yang muncul setelah nama domain. Kalau alamat lengkapnya https://blog.acy-partner.com/id/about, maka path-nya adalah /id/about. Path memberi tahu server sumber daya mana yang kamu minta. Domain mengantar pesanmu ke gedung yang benar; path menunjuk ke ruangan yang tepat di dalamnya.
3. Header
Header adalah baris-baris informasi tambahan, masing-masing ditulis sebagai Nama: nilai. Anggap saja seperti catatan yang kamu tulis di amplop plus surat pengantar di dalamnya: bukan isi utama, tapi konteks yang dibutuhkan penerima. Header bisa menyebut situs mana yang kamu hubungi (Host), program jenis apa yang bertanya (User-Agent), format jawaban apa yang bisa kamu terima (Accept), dan masih banyak lagi.
4. Body (opsional)
Body adalah muatan data yang ikut kamu kirim, dan ia hanya muncul kalau memang ada sesuatu yang perlu dikirim. Request GET biasanya tidak punya body, karena kamu cuma meminta, bukan menyerahkan apa pun. Sebaliknya, request POST yang mengirim formulir membawa data formulir itu di dalam body-nya.
Cara rapi mengingatnya
Sebuah request terdiri dari: method (mau melakukan apa) + path (sumber daya yang mana) + header (konteks) + body opsional (data yang dikirim). Empat bagian, dan yang terakhir hanya ada saat dibutuhkan.
Anatomi sebuah response
Response adalah balasan dari server, dan bentuknya mirip dengan request. Ia punya tiga bagian.
1. Kode status
Kode status adalah angka tiga digit yang merangkum bagaimana hasilnya, bahkan sebelum kamu membaca satu kata pun dari body. Kamu pasti pernah melihat 404 saat sebuah halaman tidak ditemukan. Itu salah satu kode status. Mereka dikelompokkan berdasarkan digit pertamanya:
| Rentang | Artinya | Contoh umum |
|---|---|---|
| 1xx | Informasi, tunggu dulu | 100 Continue |
| 2xx | Berhasil, lancar | 200 OK, 201 Created |
| 3xx | Pengalihan, cari di tempat lain | 301 Moved Permanently, 304 Not Modified |
| 4xx | Kesalahan client, kamu yang keliru | 400 Bad Request, 401 Unauthorized, 404 Not Found |
| 5xx | Kesalahan server, server yang bermasalah | 500 Internal Server Error, 503 Service Unavailable |
Polanya layak kamu hafal: 2xx berarti aman, 3xx berarti “pergi ke tempat lain”, 4xx menunjuk ke request yang kamu kirim, dan 5xx berarti server-nya sendiri yang rusak. Cukup melirik digit pertama, kamu sudah tahu garis besarnya.
2. Header
Sama seperti request, response juga membawa header berupa baris Nama: nilai. Header ini menjelaskan jawabannya: jenis konten apa yang dikirim balik (Content-Type), seberapa besar ukurannya (Content-Length), boleh tidaknya browser menyimpannya di cache, dan seterusnya. Browser membaca header ini sebelum body, supaya tahu cara menangani apa yang menyusul.
3. Body
Body adalah isi sebenarnya yang kamu minta. Untuk halaman web biasa, isinya dokumen HTML. Untuk gambar, isinya data gambar. Untuk sebuah API, sering kali isinya JSON. Kode status dan header bercerita tentang jawaban; body itu sendiri adalah jawabannya.
Contoh request dan response nyata
Cukup penjelasannya. Berikut wujud asli sebuah pertukaran dalam teks mentah, persis seperti yang lewat di jaringan. Pertama, request yang dikirim browser:
GET /id/about HTTP/1.1
Host: blog.acy-partner.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: id-ID,id;q=0.9
Connection: keep-aliveBaca dari atas ke bawah. Baris pertama memadatkan tiga hal: method (GET), path (/id/about), dan versi HTTP (HTTP/1.1). Setiap baris setelahnya adalah header. Karena ini GET, tidak ada body; pesannya berakhir begitu saja setelah header.
Sekarang balasan dari server:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1024
Date: Mon, 15 Sep 2026 10:30:00 GMT
Server: nginx
<!DOCTYPE html>
<html>
<head><title>Tentang ACY Partner Indonesia</title></head>
<body><h1>Tentang kami</h1></body>
</html>Baris pertama membawa kode status: 200 OK, artinya berhasil. Baris-baris di bawahnya adalah header response, yang memberi tahu browser bahwa ini HTML, seberapa panjang, dan kapan dikirim. Lalu ada satu baris kosong, yang merupakan tanda universal “header sudah selesai, body dimulai di sini”. Semua yang berada setelah baris kosong itu adalah body, yaitu halaman HTML-nya sendiri.
Baris kosong itu punya tugas penting
Pada kedua pesan, satu baris kosong memisahkan header dari body. Itu bukan hiasan. Itu penanda yang disepakati untuk berkata “header habis, yang menyusul adalah muatannya”. Tanpa baris itu, penerima tidak bisa membedakan di mana konteks berakhir dan isi dimulai.
Sekarang bandingkan dengan request yang memang membawa body, misalnya saat mengirim formulir pendaftaran untuk pengguna bernama Jane Doe:
POST /id/signup HTTP/1.1
Host: blog.acy-partner.com
Content-Type: application/json
Content-Length: 54
{"name": "Jane Doe", "email": "jane@example.com"}Bentuknya sama: method, path, header, baris kosong, dan kini ada body yang berisi data JSON yang dikirim. Server akan membalas dengan kode status dan header-nya sendiri, mungkin 201 Created untuk menegaskan akun baru berhasil dibuat.
Kenapa gambaran ini layak disimpan
Begitu gambaran ini tertanam di kepala, banyak bagian pengembangan web jadi pas dengan sendirinya. Saat sebuah halaman gagal dimuat, kamu bisa bertanya lebih tajam: tadi itu 4xx (ada yang salah dengan yang saya kirim) atau 5xx (server-nya yang rusak)? Saat kamu membuat formulir, kamu paham kenapa datanya masuk ke body request dan kenapa kamu memilih POST ketimbang GET. Saat kamu membaca soal API, REST, atau panggilan fetch di JavaScript, kamu akan sadar semua itu cuma versi rapi dari tarian request-dan-response yang sama.
Hebatnya, pengetahuan ini sangat awet. Browser, bahasa, dan framework berubah terus, tapi ide intinya, bertanya dengan format yang disepakati lalu dapat jawaban dengan format yang disepakati, tetap kokoh selama puluhan tahun. Pelajari sekali, manfaatnya terus mengalir.
Rangkuman
Mari rangkai semuanya kembali:
- Web bekerja sebagai percakapan antara client (yang bertanya) dan server (yang menjawab), memakai aturan HTTP. Client selalu bicara duluan, dan setiap request mendapat satu response.
- Sebuah request tersusun dari method (mau melakukan apa), path (sumber daya yang mana), header (konteks), dan body opsional (data yang dikirim).
- Sebuah response tersusun dari kode status (bagaimana hasilnya, dirangkum dalam tiga digit), header (info soal jawaban), dan body (jawaban itu sendiri).
- Digit pertama kode status adalah peta cepat: 2xx berhasil, 3xx pengalihan, 4xx request-mu keliru, 5xx server rusak.
- Dalam pesan mentah, satu baris kosong selalu memisahkan header dari body.
Dari sini, langkah berikutnya yang wajar adalah menelisik method-nya lebih dalam, terutama beda antara GET dan POST, atau menggali apa sebenarnya yang ingin disampaikan kode status tertentu ketika ada yang tidak beres. Keduanya berdiri langsung di atas gambaran yang baru saja kamu pelajari, dan keduanya akan membuat momen halaman bertingkah aneh berikutnya terasa jauh lebih masuk akal.
