Kehendak soalan dan persekitaran
Satu API menyediakan dokumen dengan pengesah versi. Pelbagai klien boleh membaca dan menyuntingnya secara serentak, dan keperluannya adalah untuk menolak penulisan lapuk (stale writes) sambil mengekalkan API boleh dicuba semula dan boleh diperhatikan.
Perkara yang diuji oleh penemu duga
- Membezakan caching perwakilan daripada prasyarat penulisan.
- Memilih ETag yang kukuh dan menguatkuasakan
If-Matchpada kaedah mutasi. - Mengembalikan 412 pada versi lapuk dan menentukan laluan pemulihan klien yang selamat.
Soalan penjelasan sebelum menjawab
- Adakah ETag mewakili perwakilan tersimpan yang tepat atau hanya versi semantik yang lemah?
- Kaedah manakah yang memerlukan prasyarat: PUT, PATCH, DELETE, atau semua penulisan?
- Patutkah klien menggabungkan medan secara automatik, atau adakah manusia perlu menyelesaikan konflik?
- Adakah percubaan semula dihantar melalui API dengan pengimbangan beban dan satu stor data transaksional?
Rangka jawapan 30 saat
Saya akan mengembalikan ETag yang kukuh dengan setiap perwakilan yang boleh disunting. Klien menghantar nilai tersebut dalam If-Match pada PUT, PATCH, atau DELETE. Pelayan membandingkannya di dalam transaksi yang sama dengan kemas kini; ketidakpadanan mengembalikan 412 tanpa menggunakan mutasi. Respons harus merangkumi perwakilan semasa atau isyarat ambil semula (refetch), manakala metrik menjejaki konflik dan prasyarat yang tiada. Klien kemudian mengambil semula, menggabungkan secara sengaja, dan mencuba semula dengan ETag baharu.
Huraian mendalam langkah demi langkah
1. Mengeluarkan pengesah
Pada GET, kembalikan dokumen dan ETag yang diperoleh daripada versi kanonikal yang disimpan. Nombor semakan pangkalan data boleh menjadi lebih mudah daripada menghas payload yang besar, dengan syarat nilainya berubah setiap kali perwakilan yang berkaitan dengan penyuntingan berubah. Gunakan pengesah kukuh untuk If-Match; pengesah lemah tidak sesuai untuk melindungi keadaan penulisan yang tepat.
2. Menguatkuasakan prasyarat secara atomik
Kemas kini mesti menyemak versi yang dijangkakan dan menulis versi baharu sebagai satu operasi bersyarat. Secara konseptual:
UPDATE documents
SET body = :new_body, version = version + 1
WHERE id = :id AND version = :expected_version;Jika kiraan baris yang terjejas adalah sifar, kembalikan 412 dan jangan lakukan sebarang kesan sampingan. Menyemak ETag dalam memori aplikasi dan menulis kemudian mewujudkan keadaan perlumbaan (race condition) antara semakan dan komit.
3. Memisahkan 412 daripada kegagalan lain
412 bermakna prasyarat yang dibekalkan adalah palsu; ia adalah konflik konkurensi, bukan JSON yang salah bentuk dan bukan kegagalan pengesahan. Kembalikan 400 untuk bentuk permintaan yang tidak sah, 401 atau 403 untuk kebenaran, dan 404 apabila sumber tidak tersedia di bawah dasar API. Perbezaan ini membolehkan klien memilih ambil semula dan gabung (refetch-and-merge) berbanding pembetulan pengguna.
4. Mereka bentuk pemulihan klien
Selepas 412, ambil dokumen semasa dan tunjukkan medan yang berkonflik atau perbezaan (diff). Penggabungan automatik hanya selamat apabila semantik peringkat medan dan peraturan kebenaran menjadikannya selamat. Percubaan semula mesti menggunakan ETag baharu yang dikembalikan dan kekal idempoten pada peringkat sumber; jangan sekali-kali memainkan semula permintaan lapuk secara membuta tuli.
5. Memastikan cache dan replika kekal koheren
Hasilkan pengesah daripada keadaan terkomit yang boleh dilihat oleh laluan penulisan. Pembacaan daripada replika yang ketinggalan (lagging) boleh mengembalikan ETag lama dan menyebabkan konflik yang boleh dielakkan, manakala penulisan yang dihalakan ke nod lain mesti tetap menguatkuasakan versi dalam transaksi utama. Pancarkan metrik kadar konflik, kadar kehilangan If-Match, dan kadar kejayaan percubaan semula.
Contoh jawapan berkualiti tinggi
“Saya akan mengembalikan ETag yang kukuh untuk setiap dokumen yang boleh disunting dan memerlukan If-Match pada mutasi. Pelayan akan membandingkan teg dalam transaksi yang sama yang mengemas kini baris, menggunakan kemas kini versi bersyarat. Jika tiada baris yang sepadan, ia mengembalikan 412 dan tidak menggunakan kesan sampingan. Klien mengambil semula, membentangkan diff atau melakukan penggabungan yang ditakrifkan secara sempit, kemudian mencuba semula dengan ETag baharu. Saya akan membezakan 412 daripada ralat pengesahan dan kebenaran, serta memantau kadar bacaan lapuk, konflik, dan kejayaan percubaan semula.”
Kesilapan lazim
- Semak ETag, kemudian kemas kini dalam operasi berasingan → perlumbaan kekal wujud → laksanakan predikat versi dan penulisan secara atomik.
- Gunakan pengesah lemah untuk penulisan tepat → kandungan yang serupa secara semantik mungkin dibandingkan secara salah → gunakan pengesah kukuh.
- Kembalikan 409 untuk setiap penulisan lapuk → klien tidak dapat membezakan prasyarat protokol → gunakan 412 untuk syarat
If-Matchyang gagal. - Mencuba semula payload lapuk secara membata tuli → perubahan penyunting pertama boleh hilang → ambil semula, gabungkan secara sengaja, dan cuba semula dengan teg baharu.
Soalan susulan dan jawapan
Adakah ETag hanya untuk caching?
Tidak. If-None-Match lazimnya membolehkan pengesahan cache, manakala If-Match menjadikan penulisan bersyarat pada perwakilan semasa. Pengesah yang sama boleh memenuhi kedua-dua peranan jika kekuatan perbandingan dan dasar penjanaannya betul.
Bagaimana jika klien mengetepikan If-Match?
Bagi sumber yang memerlukan konkurensi optimistik, tolak mutasi dengan respons prasyarat diperlukan yang didokumenkan atau dasar 400 yang jelas. Menerima penulisan tanpa syarat secara senyap memperkenalkan semula masalah kemas kini yang hilang; dasar tersebut mesti konsisten merentas kaedah.
Patutkah pelayan mengembalikan dokumen terkini dalam respons 412?
Ia boleh berbuat demikian, jika kebenaran dan saiz payload membenarkan, tetapi kontrak masih perlu memerlukan pengambilan semula atau penyelesaian konflik yang jelas. Mengembalikan data tidak membenarkan klien menimpanya tanpa menggunakan pengesah terkini.