Belajar Backend Developer - Arsitektur Client-Server & HTTP

#Pendahuluan

Setelah di episode 1 kalian memahami peran backend secara luas, sekarang waktunya membedah fondasi teknis yang pertama: arsitektur client-server dan HTTP. Ini bukan teori kelas semata — setiap endpoint yang kalian tulis nanti hanyalah cara merespons HTTP. Framework, middleware, dan error handling semuanya bekerja di atas protokol ini.

Mengapa harus memahami HTTP sebelum menulis API? Karena hampir semua bug backend berakar di sini: method yang salah, status code yang menyesatkan, header yang hilang, atau body yang tidak sesuai kontrak. Jika kalian paham bagaimana request terbentuk dan bagaimana response dibangun, kalian akan mampu mendiagnosis masalah API tanpa menebak-nebak.

#Arsitektur Client-Server

Model client-server memisahkan peran menjadi dua sisi:

• Client — pengirim request: browser, aplikasi mobile, atau server lain. Client meminta.
• Server — penerima request: aplikasi backend kalian. Server menyediakan.

Ciri khas model ini: server tidak pernah memulai komunikasi — ia hanya menunggu dan merespons. Ini membuat arsitektur sederhana dan bisa diskalakan, karena server bisa berjalan tanpa mengetahui siapa clientnya selama permintaan valid.

#Anatomi HTTP Request dan Response

#Request

Sebuah request HTTP terdiri dari tiga bagian: request line, header, dan opsional body.

GET /products?page=2&limit=10 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Accept: application/json
 

Baris pertama berisi method (GET), path lengkap dengan query (/products?page=2&limit=10), dan versi protokol (HTTP/1.1). Header membawa metadata seperti host dan autentikasi. Body hanya ada pada request yang mengirim data (biasanya POST/PUT).

#Response

Response memiliki struktur serupa: status line, header, dan body.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60
 
{"data":[{"id":1,"name":"Keyboard"}],"meta":{"page":2}}

Status line berisi versi protokol, status code (200), dan reason phrase (OK). Header Content-Type memberi tahu client cara memparsing body.

#Metode HTTP

Metode mengekspresikan intensi — apa yang ingin dilakukan client terhadap resource. Empat yang paling penting untuk backend:

Idempotent berarti memanggil berkali-kali menghasilkan efek yang sama. GET boleh dipanggil ulang tanpa risiko; POST tidak — setiap pemanggilan membuat resource baru. Memahami ini penting untuk mendesain retry yang aman.

#Status Code

Status code memberi tahu client hasil request dalam satu angka. Kelompok utama:

#2xx — Sukses

• 200 OK — request berhasil.
• 201 Created — resource baru berhasil dibuat (dipakai untuk POST).

#3xx — Redirection

• 301/302 — resource pindah lokasi.
• 304 Not Modified — cache client masih valid.

#4xx — Error dari Client

• 400 Bad Request — format request salah.
• 401 Unauthorized — belum/kurang terautentikasi.
• 403 Forbidden — terautentikasi tapi tidak diizinkan.
• 404 Not Found — resource tidak ada.
• 409 Conflict — konflik dengan kondisi saat ini (misal stok habis).
• 429 Too Many Requests — kena rate limit.

#5xx — Error dari Server

• 500 Internal Server Error — kesalahan tak terduga di server.
• 502 Bad Gateway — server antara menerima response tak valid.
• 503 Service Unavailable — server sedang kelebihan beban/pemeliharaan.

#Praktik: Melacak Request HTTP

Sekarang kita lihat HTTP dalam aksinya. Kita pakai layanan publik jsonplaceholder sebagai target — tanpa menulis kode apa pun:

curl -sS -v https://jsonplaceholder.typicode.com/todos/1

Flag -v membuat curl mencetak seluruh detail request dan response. Perhatikan output berikut:

> GET /todos/1 HTTP/1.1
> Host: jsonplaceholder.typicode.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< ETag: W/"53-fPBM0wCV6T4hB9Ee2b4tQm7u5jY"
<
{"userId":1,"id":1,"title":"delectus aut autem","completed":false}

Baris diawali > adalah request, diawali < adalah response. Lihat bagaimana struktur anatomi di atas terlihat nyata: request line, header, lalu body response JSON.

#Memakai Method dan Header yang Berbeda

curl -sS -X POST https://jsonplaceholder.typicode.com/todos \
  -H "Content-Type: application/json" \
  -d '{"title":"Belajar HTTP","completed":false}'

-X POST mengubah method, -H menambah header, dan -d mengirim body. Kalian juga bisa melihat status code tanpa body:

curl -sS -o /dev/null -w "%{http_code}\n" https://jsonplaceholder.typicode.com/todos/99999

Request ke resource yang tidak ada mengembalikan 404 — contoh nyata status code yang sedang kita bahas.

#Common Pitfalls

#Mengira Server Bisa "Push" Data

HTTP murni adalah pull model — server tidak bisa mengirim data tanpa diminta. Saat nanti kalian butuh notifikasi real-time, solusinya bukan memaksa HTTP, melainkan WebSocket atau event streaming (episode 22).

#Mengabaikan Header

Content-Type yang salah membuat client gagal memparsing body; Cache-Control yang tidak diatur membuat response tidak bisa di-cache (episode 9). Header adalah bagian dari kontrak API, bukan pelengkap.

#Membedakan 401 vs 403

Kedua status ini sering tertukar. 401 berarti "saya tidak tahu siapa kalian" (perlu login); 403 berarti "saya tahu siapa kalian, tapi tidak berhak" (perlu otorisasi). Episode 7 membahas keduanya secara detail.

#Penutup

Episode 2 membangun fondasi komunikasi semua API: arsitektur client-server di mana server hanya merespons, anatomi request dan response, lima metode HTTP, kelompok status code, dan cara melacak request nyata dengan curl.

Inti yang harus dibawa pulang:

• HTTP adalah model request-response; server tidak pernah memulai komunikasi.
• Metode HTTP mengekspresikan intensi; POST tidak idempoten, GET/PUT/DELETE idempoten.
• Status code berkelompok: 2xx sukses, 3xx redirect, 4xx error client, 5xx error server.
• Header adalah bagian kontrak API; Content-Type dan Cache-Control sering jadi sumber bug.
• curl -v adalah alat paling ampuh untuk melihat request dan response nyata.

Di episode 3 selanjutnya kita akan memilih senjata utama: memilih bahasa dan stack — perbandingan Node.js/TypeScript, Python, Go, Java/Kotlin, dan Rust, kapan memakai yang mana, dan bagaimana menentukan pilihan berdasarkan use case nyata. Sampai jumpa di episode 3!