Gesaan dan konteks
Dua klien menyunting dokumen yang sama. Pelayan memerlukan kemas kini bersyarat: ia mengembalikan 428 apabila syarat tiada dan 412 apabila syarat yang dibekalkan tidak lagi sepadan. Terangkan cara ETag, If-Match, caching, dan percubaan semula bekerjasama supaya penulisan yang terkemudian tidak dapat menulis ganti penulisan terdahulu secara senyap.
Perkara yang dinilai oleh penemu duga
- Membezakan 428 sebagai keperluan dasar daripada 412 sebagai syarat ternilai yang gagal.
- Menggunakan ETag kukuh dan If-Match untuk kawalan keserentakan optimistik.
- Mereka bentuk langkah baca, sunting, serah, paparan konflik, dan gabung.
- Mengendalikan caching, keidempotetan, kebolehikutan audit, dan sempadan percubaan semula.
Soalan untuk dijelaskan sebelum menjawab
- Sumber dan kaedah penulisan manakah yang memerlukan syarat, dan adakah
If-Match: *dibenarkan? - Adakah ETag itu kukuh atau lemah, dan adakah ia berubah dengan setiap kemas kini perwakilan yang dilindungi?
- Bagaimanakah klien harus mengendalikan 428, 412, 404, dan 409 masing-masing?
- Adakah konflik digabungkan mengikut medan, dipilih oleh pengguna, atau diabaikan?
- Apakah keperluan cache, versi, kunci keidempotetan, dan audit?
Rangka kerja jawapan 30 saat
Klien melakukan GET pada sumber dan menyimpan ETagnya, kemudian menyerahkan suntingan dengan If-Match. Syarat yang tiada menerima 428, memberitahu klien untuk menambahkannya; ketidakpadanan menerima 412, memberitahunya bahawa sumber telah berubah. Klien membaca semula, menunjukkan perbezaan, menggabungkan, dan menyerahkan dengan ETag baharu dan bukannya menulis ganti secara membuta tuli. Pelayan membandingkan ETag kukuh secara atomik, merekodkan versi dan data audit, serta memisahkan caching bersyarat daripada perlindungan penulisan.
Perincian langkah demi langkah
Langkah 1: Asingkan 428 dan 412
428 ialah respons dasar pelayan: permintaan tersebut tertinggal prasyarat yang diperlukan. 412 bermaksud syarat yang dibekalkan telah dinilai dan keadaan sumber semasa tidak memenuhinya. Kedua-duanya tidak bermakna untuk mencuba semula permintaan asal tanpa perubahan.
Langkah 2: Hasilkan versi sumber
Pelayan mengeluarkan ETag kukuh dan mengubahnya setiap kali perwakilan yang dilindungi berubah. Klien menyimpan ETag daripada GET tersebut sebagai garis dasar penyuntingannya dan bukannya hanya bergantung pada cap masa tempatan.
Langkah 3: Serahkan If-Match
Klien menghantar If-Match dengan PUT, PATCH, atau kemas kini lain yang mempunyai kesan sampingan. Sebelum menggunakan penulisan, pelayan membandingkan ETag semasa secara atomik; hanya padanan yang diteruskan, manakala ketidakpadanan mengembalikan 412 dan membiarkan sumber tidak berubah.
GET /documents/42
ETag: "v17"
PUT /documents/42
If-Match: "v17"Langkah 4: Selesaikan konflik
Selepas 412, lakukan GET sekali lagi dan tunjukkan versi pelayan di samping perubahan tempatan. Gabungkan medan apabila dasar membenarkan; jika tidak, minta pengguna untuk memilih. Jangan sekali-kali menghantar semula nilai If-Match yang lapuk.
Langkah 5: Reka bentuk tingkah laku cache
GET bersyarat boleh menggunakan If-None-Match dan menerima 304, manakala perlindungan penulisan menggunakan If-Match. Cache tidak boleh menganggap ETag lama sebagai semasa atau menyimpan ralat dalam cache dengan cara yang mendedahkan keadaan sumber.
Langkah 6: Kendalikan kegagalan dan percubaan semula
Selepas tamat masa rangkaian, jangan mainkan semula penulisan bukan idempoten secara membuta tuli. Buat pertanyaan versi sumber atau gunakan kunci keidempotetan untuk menentukan hasilnya. 428 memerlukan prasyarat; 412 memerlukan bacaan semula dan penggabungan.
Langkah 7: Rekod dan sahkan
Jejak versi, ETag, bilangan konflik, kadar gabungan automatik, dan pengabaian pengguna. Ujian kemas kini serentak harus menunjukkan seorang penulis berjaya dan seorang lagi menerima 412, dengan jejak audit untuk setiap perubahan versi.
Contoh jawapan berkualiti tinggi
Saya akan mengembalikan ETag kukuh seperti "v17" daripada GET dan meminta klien mengekalkannya semasa menyunting. PUT tanpa If-Match mengembalikan 428 dengan arahan untuk menggunakan kemas kini bersyarat; ETag yang lapuk gagal dalam perbandingan atomik dan mengembalikan 412. Klien kemudiannya mendapatkan versi terkini melalui GET, memaparkan perbezaan, menggabungkan, dan mencuba semula dengan ETag baharu dan bukannya memainkan semula syarat lapuk. If-None-Match dan 304 mengoptimumkan bacaan tetapi tidak melindungi penulisan. Penulisan yang tamat masa disemak mengikut versi atau kunci keidempotetan sebelum sebarang percubaan semula, dan kami memantau kadar konflik dan gabungan.
Kesilapan biasa
- Menganggap kedua-dua 428 dan 412 sebagai ralat sementara dan mencuba semula tanpa henti.
- Menggantikan perbandingan ETag kukuh dengan cap masa klien.
- Menulis ganti versi pelayan selepas menerima 412.
- Mengelirukan pengesahan cache If-None-Match dengan perlindungan penulisan If-Match.
- Memainkan semula penulisan berkesan sampingan tanpa syarat selepas tamat masa.
Soalan susulan dan respons
Susulan 1: Mengapa tidak menggunakan Last-Modified?
Ketepatan cap masa dan isu jam boleh menyebabkan dua versi kelihatan sama. ETag kukuh terikat terus kepada versi perwakilan dan lebih baik untuk menghalang kemas kini hilang.
Susulan 2: Bilakah If-Match: * berguna?
Ia menyatakan bahawa sumber mesti wujud atau menghalang penciptaan atau penggantian terhadap versi yang tidak diketahui, bergantung pada kontrak API. Ia bukan penulisan tanpa syarat.
Susulan 3: Bagaimanakah 412 berbeza daripada 409?
412 bermaksud prasyarat HTTP tidak dipenuhi. 409 bermaksud permintaan bercanggah dengan keadaan sumber semasa pada peringkat perniagaan. API boleh menggunakan kedua-duanya tetapi harus menyatakan tindakan pemulihan.
Susulan 4: Bagaimanakah anda akan menggabungkan pada peringkat medan?
Muatkan garis dasar sepunya, versi pelayan, dan versi tempatan, kemudian gabungkan mengikut dasar medan. Hantar konflik medan yang sama kepada pengguna dan serahkan hasilnya dengan ETag baharu.
Susulan 5: Bagaimana jika cache mengembalikan ETag lama?
Gunakan kawalan cache atau pengesahan semula yang sesuai sebelum menyunting dan paksa pembacaan asal selepas kemas kini yang gagal. Perbandingan atomik pelayan dengan versi semasa kekal berwibawa.
Susulan 6: Bagaimanakah anda menguji keselamatan keserentakan?
Minta dua klien membaca satu ETag dan menulis secara serentak. Sahkan tepat satu yang berjaya dan satu lagi menerima 412, kemudian rangkumi percubaan semula, tamat masa, cache, dan laluan audit.