Temu Duga Backend: Bilakah Anda Patut Menggunakan PUT vs PATCH?

Prompt dan konteks

Anda memiliki API profil pasukan. Klien mungkin hanya menukar displayName atau menghantar profil lengkap, dan percubaan semula mudah alih adalah perkara biasa. Terangkan masa untuk menggunakan PUT atau PATCH, cara mentakrifkan medan yang ditinggalkan dan null, serta cara mengendalikan konflik, keatoman, percubaan semula idempoten, dan keserasian.

Senarai temu duga backend 2026 Greenroom secara eksplisit merangkumi perbezaan antara PUT dan PATCH, keidempotenan, dan pilihan kaedah. RFC 5789 mentakrifkan entiti PUT sebagai perwakilan lengkap baharu bagi sumber, manakala entiti PATCH mengandungi arahan untuk digunakan pada sumber semasa. Soalan ini tidak terikat kepada syarikat tertentu.

Perkara yang dinilai oleh penemu duga

Jawapan biasa menghafal “PUT adalah penuh, PATCH adalah separa.” Jawapan yang kukuh mentakrifkan kontrak sumber, menyatakan sama ada medan yang ditinggalkan kekal tidak berubah, menyatakan sama ada null mengosongkan medan, menerangkan If-Match, dan menyatakan sama ada permintaan yang gagal membiarkan keseluruhan perubahan tidak dilaksanakan. Tindakan susulan biasanya merangkumi permintaan pendua, respons yang hilang, medan yang tidak diketahui, peristiwa audit, dan klien lama.

Isyarat teras adalah menghubungkan semantik HTTP dengan kemas kini pangkalan data dan kawalan konkurensi daripada menganggap PATCH sebagai PUT yang lebih kecil.

Soalan penjelasan

• Bolehkah PUT mencipta sumber? Prompt ini mengemas kini profil sedia ada; jika penciptaan dibenarkan pada URI yang stabil, tentukan pemilikan dan tingkah laku permintaan pendua.
• Adakah klien menghantar sumber lengkap atau dokumen perubahan? Gunakan PUT untuk perwakilan lengkap dan PATCH untuk operasi medan atau perwakilan separa.
• Apakah maksud peninggalan dan null? Di sini peninggalan mengekalkan nilai dan null mengosongkan medan yang boleh bernilai null; medan bukan null akan menolaknya.
• Bolehkah kemas kini serentak menimpa satu sama lain? Prompt ini menolak penimpaan senyap dan memerlukan ETag/If-Match atau syarat versi pangkalan data.
• Adakah terdapat kesan sampingan? Pengindeksan carian, peristiwa audit, dan pemberitahuan mesti mengikut keadaan yang telah dikomit; kesan tak segerak bukan sebahagian daripada keatoman HTTP.

Jawapan 30 saat

“Saya mentakrifkan PUT sebagai menggantikan sumber dengan perwakilan lengkap, untuk klien yang memiliki snapshot penuh. PATCH membawa perubahan separa seperti kemas kini displayName. PATCH mesti mentakrifkan peninggalan berbanding null dan menolak versi lapuk daripada membiarkan borang lama menimpa data baharu. Pelayan mengesahkan keseluruhan dokumen dan melaksanakannya secara atomik dalam satu transaksi pangkalan data, kemudian mengeluarkan peristiwa tak segerak berversi. Klien mencuba semula dengan semantik permintaan yang sama dan If-Match. Jika perubahan itu adalah arahan dan bukannya kemas kini sumber, saya menggunakan titik akhir tindakan dan bukannya membebankan PATCH.”

Jawapan langkah demi langkah

Langkah 1: Tulis kedua-dua kaedah sebagai kontrak sumber

Ciri utama PUT bukanlah saiz badan; ia adalah tuntutan klien bahawa perwakilan itu lengkap. Jika klien hanya mengetahui beberapa medan tetapi menghantar PUT, pelayan mungkin mentafsir medan yang hilang sebagai pemadaman atau lalai. PATCH tidak selamat secara automatik: pengesahan, pembenaran, dan kesan sampingan masih terpakai.

Langkah 2: Takrifkan dokumen PATCH dan tiga keadaan medan

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

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

Prompt ini menggunakan gaya JSON Merge Patch: displayName diganti, avatarUrl: null mengosongkan medan yang boleh bernilai null, dan medan yang ditinggalkan kekal tidak berubah. Jika perniagaan memerlukan operasi tatasusunan peringkat elemen, pemindahan, atau ujian, gunakan senarai operasi JSON Patch yang dikekang sebagai ganti.

Huraikan dokumen terlebih dahulu, kemudian sahkan senarai dibenarkan, jenis, panjang, pembenaran, dan invarian domain. Jangan sekali-kali memetakan laluan JSON klien secara sewenang-wenangnya terus ke lajur pangkalan data. Medan yang tidak diketahui boleh ditolak atau diabaikan dalam kontrak berversi, tetapi tingkah laku tersebut mesti ditetapkan dan didokumenkan.

Langkah 3: Halang penimpaan senyap dengan syarat 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"}

Kemas kini pangkalan data membawa predikat versi: hanya versi 17 boleh menulis dan mara ke 18. Ketidakpadanan mengembalikan 412 Precondition Failed; klien membaca semula, menunjukkan konflik, atau menjana semula patch-nya. Ia tidak boleh memaksa versi lama ke atas data yang lebih baharu. Jika If-Match adalah mandatori dan hilang, 428 Precondition Required boleh menjadikan dasar konkurensi eksplisit.

PATCH juga mesti bersifat atomik sebagai dokumen: medan A berjaya manakala medan B gagal bukanlah kemas kini separuh yang boleh diterima. Transaksi, fasa pengesahan, dan kekangan unik menentukan sama ada perubahan dikomit. Peristiwa kesan sampingan harus ditulis ke outbox dan diterbitkan selepas komit dengan versi sumber.

Langkah 4: Kendalikan permintaan pendua dan hasil yang tidak diketahui

Permintaan PUT berulang dengan perwakilan lengkap yang sama menumpu kepada keadaan yang sama. PATCH mempunyai ciri tersebut hanya apabila operasi boleh diulang: menetapkan displayName adalah idempoten, manakala increment seats by 1 tidak. PATCH yang tidak idempoten memerlukan ID permintaan, syarat versi, atau operasi yang menyatakan keadaan sasaran.

Selepas kegagalan rangkaian, klien tidak tahu sama ada pelayan telah melakukan komit. Gunakan ID permintaan yang stabil dengan cap jari dan hasil yang direkodkan, atau cuba semula dengan If-Match dan keadaan sasaran. Jangan mainkan semula patch yang menambah kesan sampingan secara membuta tuli. Selepas sumber dikomit, pengguna peristiwa mengendalikan pengindeksan dan pemberitahuan serta menyahduplikasi mengikut ID peristiwa.

Langkah 5: Tentukan bila PUT/PATCH adalah bentuk yang salah

“Terbitkan profil,” “kira semula kebenaran,” dan “hantar jemputan” adalah arahan, bukan penggantian atau perwakilan sumber separa. Titik akhir tindakan seperti POST /profile:publish menyatakan kebenaran, audit, percubaan semula, dan keadaan tak segerak dengan lebih jelas. Arahan berbentuk PATCH menyebabkan klien salah memahami pelaksanaan pendua dan kesan sampingan.

Pertelingkahan tinggi atau transaksi merentas sumber juga mungkin memerlukan arahan domain. Menukar ahli daripada editor kepada pemilik memerlukan semakan kuota dan audit; menukar satu rentetan dengan PATCH tidak menyatakan invarian tersebut.

Contoh jawapan berkualiti tinggi

“Saya akan mendedahkan kedua-dua PUT dan PATCH dengan kontrak yang berbeza. PUT menerima perwakilan profil pasukan yang lengkap; medan yang ditinggalkan ialah ralat kontrak atau lalai eksplisit, tidak pernah ‘dibiarkan tidak berubah’ secara tidak sengaja. PATCH menerima Merge Patch yang terhad dan hanya medan yang tersenarai dibenarkan; peninggalan mengekalkan nilai dan null mengosongkannya hanya apabila medan tersebut boleh bernilai null.

“Kedua-dua kaedah menggunakan ETag dan If-Match. Pangkalan data melaksanakan kemas kini bersyarat versi dan mengembalikan 412 pada ketidakpadanan, jadi klien lama tidak boleh menimpa data yang lebih baharu. Dokumen PATCH disahkan sepenuhnya dan digunakan dalam satu transaksi; outbox menerbitkan peristiwa pengindeksan berversi selepas komit. PATCH penetapan medan boleh menjadi idempoten; kenaikan memerlukan ID permintaan, syarat, atau operasi keadaan sasaran. Menerbitkan dan menjemput adalah tindakan POST kerana ia mempunyai kesan sampingan yang eksplisit. Saya akan menguji pendua, respons yang hilang, peninggalan/null, konflik, medan yang tidak diketahui, kegagalan separa, dan keserasian klien lama.”

Kesilapan biasa

• Gejala → Memanggil PUT sebagai “kemas kini mana-mana medan” → Mengapa ia gagal → Pemanggil tidak dapat mengetahui sama ada medan yang ditinggalkan hilang → Pembaikan → Jadikan PUT sebagai perwakilan lengkap dan gunakan PATCH untuk perubahan separa.
• Gejala → Mendakwa PATCH sememangnya idempoten → Mengapa ia gagal → RFC 5789 tidak menjaminnya; kenaikan berulang mengubah keadaan → Pembaikan → Jadikan hanya patch keadaan sasaran boleh diulang dan tambahkan syarat atau penyahduplikasian pada operasi lain.
• Gejala → Memetakan kunci JSON sewenang-wenangnya ke lajur → Mengapa ia gagal → Pembenaran medan, pengesahan jenis, dan invarian rentas medan dipintas → Pembaikan → Gunakan senarai dibenarkan dan pengesahan domain eksplisit.
• Gejala → Membiarkan penulis terakhir menang selepas konflik versi → Mengapa ia gagal → Borang lama secara senyap menimpa data baharu → Pembaikan → Gunakan If-Match dan predikat versi, mengembalikan 412 pada konflik.
• Gejala → Memanggil perkhidmatan carian secara segerak selepas komit → Mengapa ia gagal → Respons yang hilang atau ranapan proses memisahkan sumber dan indeks → Pembaikan → Tulis outbox dalam transaksi dan terbitkan secara tak segerak dengan penyahduplikasian ID peristiwa.

Tindakan susulan dan respons

Bagaimana jika produk mahu medan PATCH yang ditinggalkan mengosongkan nilai?

Itu mengubah PATCH menjadi satu lagi kontrak perwakilan lengkap dan mengaburkannya dengan PUT. Gunakan PUT, atau tentukan jenis media penggantian set medan yang dinamakan dengan jelas; bahagian penting adalah menjadikan akibat daripada medan yang ditinggalkan itu eksplisit.

Bagaimana jika dua klien kedua-duanya membaca versi 17 dan mengedit medan yang berbeza?

Kembalikan 412 secara lalai dan biarkan klien menggabungkan dan mencuba semula, kerana pelayan tidak boleh menganggap pengeditan adalah bebas. Penggabungan peringkat medan adalah selamat hanya apabila domain membenarkannya secara eksplisit dan patch menyertakan versi medan atau operasi ujian.

Bagaimana jika PATCH mencetuskan pengebilan atau pemberitahuan?

Asingkan kemas kini sumber dan kesan sampingan kepada langkah yang boleh diaudit: komit sumber dan outbox bersama-sama, kemudian biarkan pengguna idempoten memproses peristiwa tersebut. Jika kesan sampingan memerlukan niat pengguna yang jelas, jadikannya arahan POST yang berasingan dengan status operasi tak segerak.