HTTP Methods di REST: Cara Sistem Ngomong “Mau Ngapain?”

Dalam dunia REST API, setiap kali kamu kirim request, itu ibarat kamu lagi ngobrol sama server.
Tapi, seperti ngobrol sama orang, cara ngomongnya harus jelas.
Kalau kamu asal ngomong “pokoknya saya mau ini!”, server bisa bingung—mau ambil data? Mau bikin baru? Mau hapus? Yang bener yang mana?

Nah, supaya komunikasi ini nggak bikin salah paham, dipakailah yang namanya HTTP Methods.

Kita bisa anggap HTTP Methods itu kayak kata kerja sopan di dunia web.
Daripada bilang “saya mau ngapa-ngapain data ini”, kita bilang langsung dengan gaya yang to the point dan terstruktur.

Contohnya:

“Saya cuma mau liat datanya, kok.” → pakai GET

“Saya mau masukin data baru, nih.” → pakai POST

“Yang lama diganti aja, ini versi barunya.” → pakai PUT

“Cuma mau ubah satu bagian aja, gak semuanya.” → pakai PATCH

“Sudah gak dipakai, buang aja.” → pakai DELETE

Dengan cara ini, server ngerti maksud kita, dan kita pun jadi punya standar komunikasi yang rapi.
Semua sistem bisa saling ngerti — walaupun dibikin oleh tim yang beda, bahasa pemrograman yang beda, atau bahkan beda generasi.

Jadi, HTTP Methods ini bukan cuma aturan teknis. Mereka itu kayak etika komunikasi antar mesin.
Gak pakai basa-basi, tapi juga gak asal bacot. Jelas, tegas, dan sopan.

Yuk, kenalan satu-satu sama mereka. Tenang aja, gak akan bikin pusing.

GET — “Mau Lihat Data, Gak Ngapa-ngapain Kok!”

Ini metode paling adem.
Paling kalem.
Kalau HTTP Methods itu kayak teman nongkrong, maka GET adalah si pengamat — dia duduk manis, dengerin semua, tapi gak pernah ganggu siapa-siapa.

Kalau kamu kirim request pakai GET, artinya kamu cuma pengin lihat-lihat data.
Gak ada niat buat ngubah, gak pengin nyimpen, apalagi ngapus. Cuma pengin tahu aja.

Contohnya:

GET /users/123

Itu artinya:
"Hai server, boleh dong kasih data user nomor 123? Aku cuma mau lihat, gak akan aku apa-apain kok."

Dan karena GET ini gak bikin perubahan apa-apa, dia termasuk metode yang aman.
Aman dalam artian: kamu bisa pakai berkali-kali tanpa efek samping.
Server juga santai aja—dia tahu kamu cuma numpang baca.

GET ini juga bisa:

• di-cache (buat nyimpen hasil sementara),
• di-bookmark (karena URL-nya konsisten),
• dan diulang-ulang sesuka hati (karena gak bakal ngubah apa-apa).

Saking jinaknya, GET sering dipakai buat hal-hal seperti:

• ngambil daftar produk,
• melihat detail artikel,
• menampilkan profil pengguna,
• atau nge-load halaman utama aplikasi.

Pokoknya kalau kamu cuma butuh info dari server tanpa niat macem-macem, GET adalah jalan ninjamu.

POST — “Saya Mau Tambah yang Baru!”

Nah, kalau GET itu cuma numpang lihat, POST beda cerita.
Dia datang dengan niat. Niat baik, tentu saja—karena POST itu dipakai buat bikin sesuatu yang baru.

Misalnya:

POST /comments

Ini berarti kamu pengin kirim komentar baru.
Server akan menerima data itu, nyimpen ke database, dan biasanya ngebalas dengan ID baru yang dikasih ke komentar tersebut.

POST itu semacam tombol “submit” di formulir. Sekali kamu klik, datanya dikirim dan tersimpan.
Tapi hati-hati ya… kalau kamu kirim dua kali, ya dapet dua entri.
Makanya POST itu disebut non-idempotent. Artinya, hasilnya bisa beda tiap kali kamu kirim—tergantung isinya.

Biasanya POST dipakai buat:

• daftar akun baru,
• kirim form kontak,
• bikin order baru,
• upload data ke sistem.

Intinya, kalau kamu lagi nambah sesuatu ke server dan pengin itu dicatat sebagai "hal baru", maka POST adalah metodenya.

Dan oh ya—jangan klik tombol submit dua kali. Itu cara tercepat buat nambahin masalah. :)

PUT — “Ganti Total, Ya?”

PUT itu semacam renovasi besar-besaran.
Kalau POST itu nambah bangunan baru, maka PUT adalah ngganti rumah lama dengan versi yang lebih fresh.

Contoh:

PUT /users/123

Artinya:
"Ganti semua info user 123 pakai data baru ini ya, dari atas sampai bawah."

PUT akan menimpa data lama dengan isi baru secara keseluruhan.
Jadi kalau kamu gak kirim semua field yang diperlukan, bisa-bisa data yang lain ikut hilang.
Makanya penting banget: kalau pakai PUT, kirim data yang lengkap, ya!

Tapi ada kabar baik juga: PUT itu idempotent.
Artinya, mau kamu kirim request yang sama sekali, dua kali, atau sepuluh kali… hasilnya akan tetap sama.
Server cuma akan ngeganti data satu kali, dengan isi yang sama.

Biasanya dipakai untuk:

• update profil secara penuh,
• mengganti setting konfigurasi,
• atau revisi dokumen lengkap.

Kalau niat kamu “ganti semuanya aja deh sekalian”, maka PUT adalah pilihan yang tepat.

PATCH — “Eh, Edit Dikit Aja Nih…”

Kalau PUT itu renovasi total, PATCH ini perbaikan kecil di pojokan.
Misalnya cuma mau ubah email, atau ganti foto profil—gak perlu kirim semua data.

Contohnya:

PATCH /users/123

Dengan body:

{
  "email":"[email protected]"
}

Artinya: "Email-nya aja ya yang diganti, sisanya biarin kayak kemarin."

PATCH itu hemat.
Cepat.
Dan cocok banget buat update kecil-kecilan.

Tapi karena cuma ubah sebagian, PATCH sering tergantung pada implementasi di server—jadi pastikan backend-nya emang siap nerima PATCH.

Biasanya dipakai buat:

• update satu field,
• ubah status order,
• ganti nama tampilan,
• atau aktif/nonaktifkan sesuatu.

PATCH bukan idempotent secara default, tapi kalau diterapkan dengan baik, bisa dibuat aman juga.

DELETE — “Buang Aja, Gak Butuh Lagi!”

Terakhir, metode yang paling to the point: DELETE.

Kalau kamu kirim:

DELETE /users/123

Itu artinya:
"Hapus user 123 dari sistem, ya. Gak usah disimpan, gak usah ditanya-tanya lagi."

DELETE itu metode paling tegas. Sekali jalan, ya udah.
Biasanya gak ada konfirmasi (kecuali sistemmu bikin UI konfirmasi duluan).

Tapi bagusnya, DELETE itu juga idempotent.
Kamu bisa "hapus" dua kali, dan hasilnya tetap sama: data itu gak ada.

Biasanya dipakai buat:

• hapus postingan,
• buang file yang gak kepake,
• nonaktifkan akun (kalau soft-delete),
• atau bersih-bersih database.

Catatan penting:
Beberapa sistem gak langsung hapus permanen. Kadang DELETE cuma tandain data sebagai "dihapus" (soft delete), dan masih bisa dikembalikan. Jadi tergantung kebijakan backend-nya juga.

BONUS: HEAD & OPTIONS — “Nanya Dulu Sebelum Bertindak”

Selain metode utama kayak GET POST, PUT, PATCH, dan DELETE, REST juga punya dua metode tambahan yang suka muncul di balik layar: HEAD dan OPTIONS.

Mereka ini ibarat tukang intip dan tukang tanya. Gak ngapa-ngapain, tapi penting buat ngecek situasi.

HEAD — “Cuma Mau Ngecek, Gak Ambil Apa-Apa Kok”

HEAD itu kayak GET, tapi tanpa isi.

Misalnya:

HEAD /users/123

Server akan cek:
“Oke, data user 123 ada. Tapi aku gak bakal kirim isinya ya—cuma header-nya aja.”

Ini berguna banget buat ngecek:

• Apakah file atau data tersedia
• Berapa ukurannya
• Kapan terakhir di-update

...tanpa harus ngambil datanya beneran. Jadi hemat bandwidth juga.

OPTIONS — “Endpoint Ini Bisa Diapain Aja, Sih?”

OPTIONS itu kayak kamu nanya dulu sebelum bertindak:

“Endpoint ini bisa dipakai metode apa aja sih? GET bisa? DELETE boleh gak?”

Contohnya:

OPTIONS /users

Server bakal jawab dengan daftar metode yang boleh dipakai, misalnya:

Allow: GET, POST, OPTIONS

Biasanya OPTIONS dipakai pas proses preflight request di browser (terutama kalau pakai CORS), atau kalau kamu developer yang pengin tahu hak akses sebelum lanjut coding.

Ringkasan Metode REST

Method	Tujuan	Sifat	Bisa Diulang Aman?	Cocok untuk
GET	Ambil data	Baca-only	Ya	Lihat detail, daftar, profil
POST	Tambah data baru	Create	Tidak	Buat akun, kirim form, order
PUT	Ganti semua data	Replace total	Ya	Update profil penuh, setting
PATCH	Ubah sebagian data	Partial update	Tergantung	Edit email, ubah status
DELETE	Hapus data	Remove	Ya	Hapus akun, file, komentar
HEAD	Cek resource (tanpa isi)	Metadata only	Ya	Validasi data, cek ukuran
OPTIONS	Tanya metode apa yang boleh	Preflight	Ya	CORS, debugging, cek hak akses

Penutup: REST Juga Butuh Etika Bicara

Ngobrol sama server tuh mirip kayak ngobrol sama orang.
Kalau caramu gak jelas, ya yang diajak ngobrol bisa bingung, salah paham, atau malah diem aja gak jawab.

Makanya REST ngasih kita “kata kerja” yang udah baku — biar tiap request bisa dimengerti dengan jelas:

• Mau lihat-lihat? Pakai GET.
• Mau nambahin? Panggil POST.
• Mau ganti semuanya? Pilih PUT.
• Mau edit dikit? Cukup PATCH.
• Mau buang? Pakai DELETE.

Dan buat kamu yang lebih berhati-hati, bisa juga pakai HEAD buat ngecek dulu, atau OPTIONS buat nanya, “Ini endpoint bisa diapain aja, sih?”

REST bukan soal coding doang.
REST ngajarin kita komunikasi yang rapi dan sopan antar sistem.

Dan kalau kamu udah ngerti cara request yang bener, server mana pun bakal nurut sama kamu.