Kenapa HTTP Bersifat Stateless (dan Cara Situs Tetap Mengingatmu)

Ada satu kenyataan kecil soal web yang hampir selalu bikin kaget orang saat pertama kali mendengarnya: protokol yang dipakai browser kamu untuk memuat halaman, yaitu HTTP, tidak punya ingatan. Sama sekali. Setiap kali browser meminta sesuatu ke server, server memperlakukan permintaan itu seolah-olah belum pernah bertemu kamu sebelumnya. Pertanyaan dijawab, lalu kamu langsung dilupakan.

Kedengarannya seperti cacat. Kalau server lupa setelah tiap permintaan, bagaimana sebuah situs bisa menjaga kamu tetap login, menyimpan barang di keranjang, atau ingat kalau kamu lebih suka mode gelap? Jawaban singkatnya: sifat pelupa itu memang disengaja, dan orang-orang menciptakan trik cerdik untuk menyiasatinya. Mari kita bedah apa arti “stateless” yang sebenarnya, kenapa itu keputusan desain yang cerdas, dan bagaimana web berpura-pura punya ingatan di atas protokol yang sebenarnya tidak punya.

Apa arti “stateless” sebenarnya

Sederhananya, state adalah “hal-hal yang diingat di antara kejadian.” Ngobrol dengan teman itu punya state: dia ingat apa yang kamu ucapkan lima menit lalu, jadi kamu tidak perlu memperkenalkan diri lagi tiap kalimat. Protokol yang stateless justru kebalikannya. Setiap interaksi dianggap berdiri sendiri sepenuhnya, dan tidak ada satu pun yang dibawa dari interaksi sebelumnya.

HTTP bekerja dalam pola bolak-balik yang sederhana. Browser kamu (si client) mengirim sebuah request, lalu server membalas dengan response. Itu satu putaran penuh. Masalahnya, secara bawaan server tidak menyimpan catatan apa pun yang menghubungkan satu putaran dengan putaran berikutnya.

Request 1:  GET /home        -->  server menjawab, lalu lupa kamu
Request 2:  GET /products    -->  server menjawab, lalu lupa kamu
Request 3:  GET /cart        -->  "Kamu siapa tadi ya?"

Tiap request harus benar-benar bisa berdiri sendiri. Ia wajib membawa segala hal yang dibutuhkan server untuk memenuhinya, karena server tidak akan bersandar pada apa pun dari request sebelumnya. Tidak ada fitur bawaan “ingat sampai mana kita tadi.”

Kenapa ada yang merancangnya seperti ini?

Terasa seperti kelemahan, tapi sifat stateless justru salah satu alasan web bisa melayani miliaran orang. Ketika server tidak harus mengingat apa pun tentang kamu di antara request, sejumlah masalah yang sangat rumit jadi hilang dengan sendirinya.

Keuntungan terbesarnya adalah skalabilitas. Bayangkan sebuah situs populer berjalan bukan dengan satu server, melainkan seratus server kembar di balik load balancer (semacam pengatur lalu lintas yang membagi request ke banyak mesin). Kalau server harus mengingat setiap pengunjung, request keduamu harus kembali ke mesin yang persis sama dengan yang menangani request pertamamu, kalau tidak, kamu tidak akan dikenali. Dengan HTTP yang stateless, server mana pun dari seratus itu bisa menjawab request mana pun, karena setiap request sudah lengkap sendiri. Kamu bebas menambah atau mengurangi server, dan satu mesin boleh tumbang tanpa membuat “sesi” siapa pun hilang di tengah jalan.

Sifat stateless juga membuat sistem lebih sederhana dan andal. Server yang tidak menyimpan ingatan per pengunjung memakai lebih sedikit memori, lebih mudah dipahami, dan pulih dengan bersih setelah restart. Request bisa di-cache, diulang, dan diarahkan tanpa perlu khawatir ada konteks tersembunyi.

Jadi desainnya memang bagus. Konsekuensinya, ia melemparkan satu masalah nyata ke setiap orang yang membangun situs: kalau server langsung melupakanmu, bagaimana cara membuat sesuatu yang terasa personal dan berkelanjutan?

Masalahnya: bagaimana situs bisa mengingatmu?

Coba pikirkan proses login. Kamu mengetik username dan password sekali, server memeriksanya, lalu kamu masuk. Tapi request berikutnya, yaitu memuat dashboard, adalah request yang sama sekali baru dan berdiri sendiri. Server sudah lupa bahwa kamu tadi login. Tanpa bantuan, setiap halaman akan menyuruhmu login lagi. Web jadi tidak bisa dipakai.

Triknya adalah berhenti berharap server yang mengingat, dan sebagai gantinya membuat setiap request membawa bukti siapa dirimu. Kalau tiap request menyerahkan secuil tanda identitas ke server, server bisa mengenalimu setiap kali tanpa perlu menyimpan ingatan di antara request. Sifat stateless tetap terjaga, dan rasa berkelanjutan diciptakan di atasnya.

Ada tiga komponen dasar yang membuat ini bekerja: cookie, session, dan token. Ketiganya berkaitan tapi bukan hal yang sama, dan pemula sering tertukar. Mari kita pisahkan satu per satu.

Cookie: catatan tempel milik browser

Cookie adalah potongan teks kecil yang diminta server untuk disimpan browser kamu, lalu dikirim kembali pada setiap request berikutnya ke situs itu. Server memasangnya lewat sebuah header response, dan sejak saat itu browser otomatis menempelkannya ke tiap request, tanpa usaha tambahan.

# Response server berkata: "tolong ingat ini"
Set-Cookie: theme=dark; Max-Age=31536000

# Setiap request berikutnya dari browser menyertakan:
Cookie: theme=dark

Putaran bolak-balik itulah seluruh keajaibannya. Server tidak mengingat preferensi tema kamu. Browser kamu yang mengingatnya, dan ia terus menyodorkan catatan itu kembali. Cookie cocok untuk preferensi kecil berisiko rendah seperti bahasa atau tema. Ada juga kekurangannya: ukurannya terbatas, ia ikut terkirim di setiap request ke situs tersebut, dan karena tersimpan di browser, ia tidak boleh dipercaya untuk menyimpan rahasia sensitif sendirian.

Session: simpan datanya di sisi server

Menaruh data asli yang sensitif langsung di dalam cookie itu berisiko, karena cookie tinggal di mesin pengguna, tempat ia bisa dibaca atau diutak-atik. Pola session menyelesaikan ini dengan rapi. Alih-alih menaruh datamu di cookie, server menyimpan datanya di sisinya sendiri, dan hanya menaruh sebuah session ID tanpa makna di dalam cookie.

Cookie menyimpan:  session_id = a8f3c0...   (sekadar nomor tiket acak)
Server menyimpan:  a8f3c0... -> { user: "Jane Doe", login: true, cart: [...] }

Anggap saja seperti tiket penitipan jaket. Tiket di sakumu cuma sebuah nomor; jaket aslinya tetap aman di balik meja penitipan. Pada tiap request, browser kamu menyerahkan tiketnya (session ID di dalam cookie), lalu server mencari data yang cocok di penyimpanannya sendiri. Detail sensitifmu tidak pernah keluar dari server, dan cookie itu tidak membocorkan apa pun yang berguna kalau dicuri sendirian.

Konsekuensinya, server kini harus menyimpan sesuatu per pengguna aktif, yang artinya sedikit state juga pada akhirnya. State itu biasanya tinggal di penyimpanan bersama yang cepat, supaya, sesuai semangat HTTP, server mana pun di armada tetap bisa mencari session mana pun.

Token: identitas yang dibawa sendiri oleh request

Pendekatan yang lebih baru dan sangat umum membalik lagi soal penyimpanan. Alih-alih server menyimpan tabel pencarian session, client-lah yang memegang sebuah token yang sudah memuat (dan melindungi secara kriptografis) informasi identitas. Request membawa token ini, server memverifikasi keasliannya, lalu memercayai isinya tanpa perlu pencarian di sisi server.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...

Gaya ini populer untuk API dan aplikasi yang banyak layanannya berdiri sendiri tapi perlu memverifikasi pengguna yang sama tanpa berbagi satu penyimpanan session terpusat. Karena buktinya ikut bepergian di dalam request itu sendiri, ia sangat pas dengan sifat stateless HTTP.

Satu peringatan yang adil: detail melakukan autentikasi secara aman — meng-hash password, menandatangani dan mengatur kedaluwarsa token, bertahan dari pencurian dan pemalsuan — adalah topik mendalam tersendiri, dan salah menanganinya itu berbahaya. Artikel ini membahas bagaimana state dibawa melintasi request yang stateless, bukan cara mengamankannya. Perlakukan detail autentikasi sebagai subjek terpisah yang perlu dipelajari dengan teliti sebelum kamu meluncurkan sistem login.

Merangkai semuanya: cookie dan state

Inilah model berpikir yang layak dipegang. HTTP sendiri tetap pelupa, persis seperti rancangannya. Di atas kanvas kosong itu, kita menumpuk satu konvensi tipis: client membawa secuil identitas, lalu mengirimnya ulang pada setiap request. Entah secuil itu berupa preferensi mentah (nilai cookie), nomor tiket yang menunjuk ke data di server (session), atau kredensial bertanda tangan yang lengkap sendiri (token), prinsipnya identik. Request membawa konteksnya sendiri supaya server tak perlu mengingat apa pun.

Protokol stateless  +  "bawa identitasmu tiap kali"  =  rasa punya ingatan

Gagasan tunggal itulah alasan sebuah protokol stateless bisa menggerakkan sesuatu yang terasa berkelanjutan seperti tetap login melintasi ratusan klik. Tidak ada yang berubah pada HTTP. Kita cuma bersepakat untuk terus menyodorkan pengingat ke server.

Rangkuman

HTTP itu stateless: setiap request berdiri sendiri, dan server tidak punya ingatan bawaan tentang apa yang terjadi sebelumnya. Itu disengaja. Sifat ini membuat web bisa diskalakan melintasi banyak server yang bisa saling menggantikan, pulih dari kegagalan, melakukan caching besar-besaran, dan tetap sederhana. Harganya: rasa berkelanjutan, seperti tetap login, tidak datang gratis.

Web menyelesaikannya dengan membuat tiap request membawa bukti identitasnya sendiri. Cookie membuat browser menyimpan dan mengirim ulang sebuah nilai kecil secara otomatis. Session menyimpan data aslinya di server dan hanya mengoper sebuah ID acak di dalam cookie, mirip tiket penitipan jaket. Token mengemas identitas yang bisa diverifikasi ke dalam request itu sendiri, yang cocok untuk API dan sistem terdistribusi. Ketiganya berbagi satu trik: jangan minta server mengingat, buat request yang mengingatkannya.

Dari sini, langkah lanjutan yang alami adalah melihat cara cookie diatur dengan aman (atribut yang membatasi ke mana dan bagaimana ia bepergian) serta cara autentikasi dilakukan dengan benar. Di situlah sifat stateless bertemu keamanan dunia nyata, dan keduanya layak dipelajari dengan cermat.