PUT, PATCH, DELETE: Mengubah dan Menghapus Data

Mengedit dokumen kertas

Bayangkan selembar formulir biodata. Ada tiga cara mengubahnya: tulis ulang seluruh lembar dari nol, coret dan betulkan satu baris saja, atau sobek dan buang lembarnya. Tiga method HTTP ini bekerja dengan logika yang sama:

• PUT: ganti SELURUH data dengan versi baru.
• PATCH: ubah SEBAGIAN data saja.
• DELETE: hapus data.

Kenapa tidak cukup POST saja

Secara teknis kamu bisa melakukan semuanya dengan POST, dan banyak API lama memang begitu. Tapi method yang spesifik membuat maksud request jelas tanpa harus membaca dokumentasi panjang. DELETE /pengguna/42 langsung terbaca: hapus pengguna 42. Selain itu, PUT dan DELETE bersifat idempotent sehingga aman di-retry, sedangkan POST tidak.

Contoh 1: PUT mengganti seluruh data

PUT /api/pengguna/42 HTTP/1.1
Host: toko.contoh.id
Content-Type: application/json

{"nama": "Omni Baru", "email": "[email protected]", "telepon": "081234"}

"Ganti total data pengguna 42 dengan data ini." Kalau field telepon tidak disertakan, server boleh menganggapnya dikosongkan. Itu kontrak PUT: kirim lengkap, atau datanya berisiko hilang.

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "nama": "Omni Baru", "email": "[email protected]", "telepon": "081234"}

Contoh 2: PATCH untuk satu field, DELETE untuk menghapus

Hanya ubah nama, sisanya jangan disentuh:

PATCH /api/pengguna/42 HTTP/1.1
Host: toko.contoh.id
Content-Type: application/json

{"nama": "Omni Patch"}

Lalu hapus datanya:

DELETE /api/pengguna/42 HTTP/1.1
Host: toko.contoh.id

HTTP/1.1 204 No Content

204 artinya "berhasil, dan tidak ada isi untuk dikembalikan", respons standar untuk DELETE yang sukses. Perhatikan DELETE tidak butuh body: targetnya sudah jelas dari path.

Kesalahan umum pemula

Salah: memakai PUT untuk mengubah satu field. Kalau lupa menyertakan field lain, datanya bisa terhapus. Yang benar: untuk perubahan sebagian, pakai PATCH.

Salah: mengirim body besar di DELETE. Sebagian server dan proxy mengabaikan body pada DELETE. Yang benar: identifikasi target lewat path (/pengguna/42), bukan body.

Salah: tidak memikirkan klik ganda. User menekan tombol simpan dua kali, request PUT terkirim dua kali. Untungnya PUT idempotent, hasilnya tetap sama. Yang benar: tetap matikan tombol saat request berjalan, dan manfaatkan sifat idempotent untuk retry yang aman.

Salah: mengira DELETE selalu menghapus permanen. Banyak API hanya menandai data sebagai "terhapus" (soft delete) agar bisa dikembalikan. Yang benar: baca dokumentasi, dan jangan kaget kalau data "terhapus" masih bisa muncul lagi.

Studi kasus: API edit profil yang aman

Desain endpoint edit profil untuk aplikasi nyata:

PATCH /api/profil HTTP/1.1
Content-Type: application/json

{"nama": "Omni Baru", "bio": "Suka kopi"}

Kenapa PATCH bukan PUT? Form edit biasanya hanya mengirim field yang diubah user. Dengan PUT, backend harus menerima SEMUA field atau berisiko menghapus yang tidak dikirim. Dengan PATCH, backend hanya update field yang ada di body.

Untuk keamanan tambahan, banyak API profesional memakai pola ini:

PUT /api/profil          -> tolak jika ada field yang hilang (validasi ketat)
PATCH /api/profil        -> update parsial, fleksibel
DELETE /api/akun         -> hapus akun, butuh konfirmasi ulang

Satu jebakan umum: frontend mengirim PUT dengan body parsial karena "lebih gampang". Hasilnya field lain ter-reset ke default. Selalu cocokkan semantik method dengan perilaku backend: tanyakan ke tim backend "apakah PUT di sini full-replace atau merge?" sebelum coding.

Tips memilih dengan cepat: form edit yang mengirim semua field pakai PUT, form yang hanya mengirim field yang berubah pakai PATCH, tombol hapus pakai DELETE. Kalau backend-mu tidak mendukung PATCH, pola umum adalah POST dengan field _method: "PATCH" (method spoofing ala Laravel).

Catatan teknis: Tidak semua API mengikuti aturan ini dengan ketat. Ada API yang memakai POST untuk semua operasi. Selalu baca dokumentasi API yang kamu pakai, dan saat membuat API sendiri, ikuti konvensi method agar mudah dipahami orang lain.