Wawancara Backend: Kapan Anda Harus Menggunakan PUT vs PATCH?

Perintah dan konteks

Anda mengelola API profil tim. Klien mungkin hanya mengubah displayName atau mengirimkan profil lengkap, dan percobaan ulang dari perangkat seluler sering terjadi. Jelaskan kapan harus menggunakan PUT atau PATCH, bagaimana mendefinisikan field yang diabaikan dan null, serta bagaimana menangani konflik, atomisitas, percobaan ulang idempoten, dan kompatibilitas.

Daftar wawancara backend Greenroom 2026 secara eksplisit mencakup perbedaan antara PUT dan PATCH, idempoten, dan pemilihan metode. RFC 5789 mendefinisikan entitas PUT sebagai representasi lengkap baru dari sumber daya, sedangkan entitas PATCH berisi instruksi untuk diterapkan pada sumber daya saat ini. Pertanyaan ini tidak terikat pada perusahaan tertentu.

Apa yang dinilai pewawancara

Jawaban rata-rata menghafal bahwa “PUT itu penuh, PATCH itu parsial.” Jawaban yang kuat mendefinisikan kontrak sumber daya, menyatakan apakah field yang diabaikan tetap tidak berubah, menyatakan apakah null mengosongkan field, menjelaskan If-Match, dan menyatakan apakah permintaan yang gagal membiarkan seluruh perubahan tidak diterapkan. Pertanyaan lanjutan biasanya mencakup permintaan duplikat, respons yang hilang, field yang tidak dikenal, peristiwa audit, dan klien lama.

Sinyal intinya adalah menghubungkan semantik HTTP ke pembaruan basis data dan kontrol konkurensi alih-alih memperlakukan PATCH sebagai PUT yang lebih kecil.

Pertanyaan klarifikasi

• Bisakah PUT membuat sumber daya? Perintah ini memperbarui profil yang ada; jika pembuatan diizinkan pada URI yang stabil, tentukan kepemilikan dan perilaku permintaan duplikat.
• Apakah klien mengirimkan sumber daya lengkap atau dokumen perubahan? Gunakan PUT untuk representasi lengkap dan PATCH untuk operasi field atau representasi parsial.
• Apa arti dari pengabaian dan null? Di sini pengabaian mempertahankan nilai dan null mengosongkan field yang dapat bernilai null; field yang tidak dapat bernilai null akan menolaknya.
• Bisakah pembaruan konkuren saling menimpa? Perintah ini menolak penimpaan diam-diam dan memerlukan ETag/If-Match atau kondisi versi basis data.
• Apakah ada efek samping? Pengindeksan pencarian, peristiwa audit, dan notifikasi harus mengikuti status yang telah di-commit; efek asinkron bukan bagian dari atomisitas HTTP.

Jawaban 30 detik

“Saya mendefinisikan PUT sebagai penggantian sumber daya dengan representasi lengkap, untuk klien yang memiliki snapshot penuh. PATCH membawa perubahan parsial seperti pembaruan displayName. PATCH harus mendefinisikan pengabaian versus null dan menolak versi usang daripada membiarkan formulir lama menimpa data baru. Server memvalidasi seluruh dokumen dan menerapkannya secara atomik dalam satu transaksi basis data, lalu memancarkan peristiwa asinkron berversi. Klien mencoba lagi dengan semantik permintaan yang sama dan If-Match. Jika perubahan tersebut berupa perintah alih-alih pembaruan sumber daya, saya menggunakan endpoint aksi alih-alih membebani PATCH secara berlebihan.”

Jawaban langkah demi langkah

Langkah 1: Tulis kedua metode sebagai kontrak sumber daya

Properti utama PUT bukanlah ukuran body; melainkan klaim klien bahwa representasinya lengkap. Jika klien hanya mengetahui beberapa field tetapi mengirimkan PUT, server dapat menginterpretasikan field yang hilang sebagai penghapusan atau nilai default. PATCH tidak otomatis aman: validasi, otorisasi, dan efek samping tetap berlaku.

Langkah 2: Definisikan dokumen PATCH dan tiga status field

PATCH /v1/teams/t_123/profile HTTP/1.1
Content-Type: application/merge-patch+json
If-Match: "profile-v17"

{"displayName":"Design Platform","avatarUrl":null}

Perintah ini menggunakan gaya JSON Merge Patch: displayName diganti, avatarUrl: null mengosongkan field yang dapat bernilai null, dan field yang diabaikan tetap tidak berubah. Jika bisnis memerlukan operasi array tingkat elemen, pemindahan, atau pengujian, gunakan daftar operasi JSON Patch yang dibatasi sebagai gantinya.

Parsing dokumen terlebih dahulu, lalu validasi daftar izin (allowlist), tipe, panjang, otorisasi, dan invarian domain. Jangan pernah memetakan jalur JSON klien arbitrer secara langsung ke kolom basis data. Field yang tidak dikenal dapat ditolak atau diabaikan dalam kontrak berversi, tetapi perilakunya harus tetap dan terdokumentasi.

Langkah 3: Cegah penimpaan diam-diam dengan kondisi versi

GET /v1/teams/t_123/profile HTTP/1.1

ETag: "profile-v17"

PATCH /v1/teams/t_123/profile HTTP/1.1
If-Match: "profile-v17"
Content-Type: application/merge-patch+json

{"displayName":"Design Platform"}

Pembaruan basis data membawa predikat versi: hanya versi 17 yang dapat menulis dan beralih ke 18. Ketidakcocokan akan mengembalikan 412 Precondition Failed; klien membaca ulang, menampilkan konflik, atau membuat ulang patch-nya. Klien tidak dapat memaksakan versi lama di atas data yang lebih baru. Jika If-Match wajib dan hilang, 428 Precondition Required dapat membuat kebijakan konkurensi menjadi eksplisit.

PATCH juga harus atomik sebagai dokumen: field A berhasil sementara field B gagal bukanlah pembaruan setengah-setengah yang dapat diterima. Transaksi, fase validasi, dan batasan unik menentukan apakah perubahan di-commit. Peristiwa efek samping harus ditulis ke outbox dan dipublikasikan setelah commit bersama versi sumber daya.

Langkah 4: Tangani permintaan duplikat dan hasil yang tidak diketahui

Permintaan PUT berulang dengan representasi lengkap yang sama akan mengarah pada status yang sama. PATCH memiliki properti tersebut hanya ketika operasinya dapat diulang: menyetel displayName bersifat idempoten, sedangkan increment seats by 1 tidak. PATCH yang tidak idempoten memerlukan ID permintaan, kondisi versi, atau operasi yang menyatakan status target.

Setelah kegagalan jaringan, klien tidak tahu apakah server telah melakukan commit. Gunakan ID permintaan yang stabil dengan sidik jari dan hasil yang dicatat, atau coba lagi dengan If-Match dan status target. Jangan mengulang patch yang menambahkan efek samping secara membabi buta. Setelah sumber daya di-commit, konsumen peristiwa menangani pengindeksan dan notifikasi serta melakukan deduplikasi berdasarkan ID peristiwa.

Langkah 5: Tentukan kapan PUT/PATCH bukan bentuk yang tepat

“Publikasikan profil,” “hitung ulang izin,” dan “kirim undangan” adalah perintah, bukan penggantian atau representasi sumber daya parsial. Endpoint aksi seperti POST /profile:publish menyatakan izin, audit, percobaan ulang, dan status asinkron dengan lebih jelas. Perintah berbentuk PATCH membuat klien salah memahami eksekusi duplikat dan efek samping.

Kontensi tinggi atau transaksi lintas sumber daya mungkin juga memerlukan perintah domain. Mengubah anggota dari editor menjadi pemilik memerlukan pemeriksaan kuota dan audit; mengubah satu string dengan PATCH tidak mengekspresikan invarian tersebut.

Contoh jawaban berkualitas tinggi

“Saya akan menyediakan PUT dan PATCH dengan kontrak yang berbeda. PUT menerima representasi profil tim yang lengkap; field yang diabaikan adalah kesalahan kontrak atau default eksplisit, tidak pernah secara tidak sengaja ‘dibiarkan tidak berubah.’ PATCH menerima Merge Patch yang dibatasi dan hanya field yang ada di daftar izin; pengabaian mempertahankan nilai dan null mengosongkannya hanya jika field tersebut dapat bernilai null.

“Kedua metode menggunakan ETag dan If-Match. Basis data melakukan pembaruan bersyarat versi dan mengembalikan 412 jika terjadi ketidakcocokan, sehingga klien lama tidak dapat menimpa data yang lebih baru. Dokumen PATCH divalidasi secara lengkap dan diterapkan dalam satu transaksi; outbox memublikasikan peristiwa pengindeksan berversi setelah commit. PATCH pengaturan field bisa bersifat idempoten; operasi penambahan (increment) memerlukan ID permintaan, kondisi, atau operasi status target. Publikasi dan pengundangan adalah aksi POST karena memiliki efek samping eksplisit. Saya akan menguji duplikat, respons yang hilang, pengabaian/null, konflik, field yang tidak dikenal, kegagalan parsial, dan kompatibilitas klien lama.”

Kesalahan umum

• Gejala → Menyebut PUT sebagai “perbarui field apa pun” → Mengapa gagal → Pemanggil tidak dapat mengetahui apakah field yang diabaikan akan hilang → Perbaikan → Jadikan PUT sebagai representasi lengkap dan gunakan PATCH untuk perubahan parsial.
• Gejala → Mengklaim PATCH pada dasarnya idempoten → Mengapa gagal → RFC 5789 tidak menjaminnya; penambahan berulang mengubah status → Perbaikan → Buat hanya patch status target yang dapat diulang dan tambahkan kondisi atau deduplikasi ke operasi lainnya.
• Gejala → Memetakan kunci JSON arbitrer ke kolom → Mengapa gagal → Otorisasi field, validasi tipe, dan invarian lintas field dilewati → Perbaikan → Gunakan daftar izin dan validasi domain eksplisit.
• Gejala → Membiarkan penulis terakhir menang (last writer wins) setelah konflik versi → Mengapa gagal → Formulir lama secara diam-diam menimpa data baru → Perbaikan → Gunakan If-Match dan predikat versi, mengembalikan 412 saat terjadi konflik.
• Gejala → Memanggil layanan pencarian secara sinkron setelah commit → Mengapa gagal → Respons yang hilang atau proses yang crash memisahkan sumber daya dan indeks → Perbaikan → Tulis ke outbox dalam transaksi dan publikasikan secara asinkron dengan deduplikasi ID peristiwa.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika produk menginginkan field PATCH yang diabaikan untuk mengosongkan nilai?

Itu mengubah PATCH menjadi kontrak representasi lengkap lainnya dan mengaburkannya dengan PUT. Gunakan PUT, atau tentukan tipe media penggantian set field yang dinamai dengan jelas; bagian pentingnya adalah membuat konsekuensi dari field yang diabaikan menjadi eksplisit.

Bagaimana jika dua klien membaca versi 17 dan mengedit field yang berbeda?

Kembalikan 412 secara default dan biarkan klien menggabungkan lalu mencoba lagi, karena server tidak dapat berasumsi bahwa pengeditan tersebut independen. Penggabungan tingkat field aman hanya jika domain secara eksplisit mengizinkannya dan patch menyertakan versi field atau operasi pengujian.

Bagaimana jika PATCH memicu penagihan atau notifikasi?

Pisahkan pembaruan sumber daya dan efek samping ke dalam langkah-langkah yang dapat diaudit: commit sumber daya dan outbox bersama-sama, lalu biarkan konsumen yang idempoten memproses peristiwa tersebut. Jika efek samping memerlukan niat pengguna yang eksplisit, jadikan itu sebagai perintah POST terpisah dengan status operasi asinkron.