Temu duga Backend: Bilakah HTTP 226 IM Used patut membawa delta?

Gesaan dan skop

Satu API mengembalikan dokumen JSON yang besar dan klien menyimpan ETag sebelumnya. Terangkan bilakah HTTP 226 IM Used sesuai, pengepala manakah yang dipertukarkan oleh klien dan pelayan, serta bagaimana ketepatan dipelihara apabila delta tidak dapat digunakan. Rangkumi perundingan, caching, dan sandaran; tiada algoritma diff khusus diperlukan.

Perkara yang diuji oleh penemu duga

• Sama ada anda tahu 226 mewakili delta untuk GET, bukan kejayaan tidak lengkap yang sebarangan.
• Sama ada anda boleh menghubungkan A-IM, IM, ETag, dan Delta-Base pilihan ke dalam satu pertukaran.
• Sama ada anda mengenal pasti sempadan versi asas, konkurensi cache, kos algoritma, dan 200 penuh.
• Sama ada anda akan mengesahkan sokongan dalam klien, perantara (intermediaries), dan cache sebelum pelaksanaan.

Soalan penjelasan

1. Bolehkah klien menggunakan algoritma manipulasi tika (instance-manipulation) yang dirundingkan?
2. Adakah dokumen tersebut dikenal pasti secara kukuh oleh ETag yang stabil, dan adakah penjanaan delta berbaloi dengan kos CPU-nya?
3. Adakah proksi akan menulis semula atau menyimpan respons dalam cache, dan bolehkah ia mengekalkan semantik delta?
4. Bolehkah klien mengambil perwakilan penuh secara telus apabila asasnya lapuk atau tidak sah?

Jawapan 30 saat

Saya akan menjadikan 226 sebagai pengoptimuman yang dirundingkan secara pilihan. Klien menghantar A-IM dan If-None-Match perwakilan asas. Pelayan mengembalikan 226 hanya apabila ia menyokong sesuatu algoritma dan mempunyai asas yang tepat itu, dengan mengisytiharkan algoritma tersebut dalam IM, ETag baharu, dan Delta-Base jika berguna. Klien mengesahkan teg asas, menggunakan delta, dan mengesahkan teg entiti yang terhasil. Ketidakpadanan, faedah kos yang lemah, klien yang tidak disokong, atau penggabungan yang gagal akan berundur (fallback) kepada 200 penuh. Cache mesti hanya menggunakan semula delta apabila asas dan metadata responsnya sepadan.

Reka bentuk langkah demi langkah

1. Rundingkan keupayaan delta

A-IM menyenaraikan algoritma manipulasi tika yang diterima oleh klien; pelayan menamakan pilihannya dalam IM. Ini berbeza daripada pemampatan pengekodan kandungan: pemampatan mengubah pengekodan pemindahan, manakala delta mengubah cara perwakilan dihasilkan. Tanpa algoritma yang disokong bersama, gunakan 200.

2. Ikatkan asas kepada sesuatu versi

Klien menggunakan If-None-Match untuk mengenal pasti teg entiti tempatannya. Pelayan mesti mengesahkan bahawa teg tersebut dipetakan kepada perwakilan asas, dan bukannya meneka daripada cap masa atau versi yang disediakan oleh klien. Respons membawa ETag baharu; Delta-Base boleh mengenal pasti teg asas secara eksplisit. Klien mengesahkan hasil yang digabungkan terhadap teg baharu tersebut.

3. Jadikan sandaran selamat

Jika asas tiada, delta lebih besar daripada dokumen penuh, algoritma tamat masa, penggabungan gagal dalam pengesahan, atau perantara tidak selamat, kembalikan 200. Klien harus membuang asas yang tidak boleh digunakan dan menyegerakkan semula, supaya delta yang rosak tidak mencemari kemas kini terkemudian. Gunakan belanjawan saiz, CPU, dan masa.

4. Anggap kunci cache dan metrik sebagai sebahagian daripada protokol

Kunci cache mesti menyertakan URL, pengepala perundingan, dan syarat-syarat yang memilih asas; delta yang sah untuk satu ETag bukanlah respons generik. Ukur kadar hit 226, bait delta berbanding bait penuh, kegagalan penggabungan, nisbah sandaran, dan kependaman penjanaan untuk membuktikan bahawa pengoptimuman tersebut berbaloi dengan kerumitannya.

Contoh jawapan berkualiti tinggi

Saya akan melancarkannya sebagai pengoptimuman dengan sandaran yang jelas. Klien mengiklankan algoritma A-IM yang disokong dan menghantar If-None-Match untuk asasnya. Pelayan menyemak bahawa asas itu wujud dan algoritma tersebut tersenarai putih, kemudian membandingkan saiz delta dan kos penjanaan. Hanya selepas itu ia mengembalikan 226, mengisytiharkan algoritma dengan IM, mengeluarkan ETag baharu untuk hasilnya, dan secara pilihan mengenal pasti asas dengan Delta-Base. Klien mengesahkan teg asas, menggunakan delta, dan mengesahkan teg entiti baharu sebelum menggantikan dokumennya. Sebarang ketidakpadanan versi, delta bersaiz terlampau besar, kegagalan penggabungan, atau laluan yang tidak disokong akan mengembalikan 200. Cache berbeza mengikut syarat perundingan dan asas, manakala telemetri merekodkan bait yang dijimatkan, CPU, kegagalan, dan sandaran. Sokongan delta meningkatkan kecekapan pemindahan tanpa menjadi prasyarat ketepatan.

Kesilapan lazim

• Menganggap 226 sebagai 206, walaupun 206 menjawab permintaan Range.
• Menghantar nombor versi tidak formal sahaja dan bukannya mengikat asas yang tepat dengan ETag.
• Menganggap setiap pelayar, proksi, dan cache memahami semantik delta.
• Melangkau perbandingan antara saiz delta dan saiz dokumen penuh.
• Meneruskan daripada asas yang tidak sah selepas kegagalan penggabungan dan bukannya menyegerakkan semula.
• Menganggap pemampatan, JSON Patch, dan manipulasi tika RFC 3229 sebagai lapisan protokol yang sama.

Soalan susulan dan respons

Bagaimanakah 226 berbeza daripada 206 dan 304?

206 mengembalikan julat bait yang diminta dengan Range; 304 menyatakan permintaan bersyarat tidak memerlukan perwakilan baharu; 226 mengembalikan delta berdasarkan perwakilan yang sedia ada. Syarat permintaan, pemprosesan klien, dan semantik cache masing-masing adalah berbeza.

Bagaimana jika ETag asas sudah lapuk?

Jangan gunakan delta secara membabi buta. Kembalikan 200 penuh atau minta klien mendapatkan asas semasa, buang asas tempatan yang tidak boleh digunakan, dan bina semula cachenya daripada perwakilan yang lengkap.

Bagaimanakah anda menghalang pencemaran cache delta (delta-cache poisoning)?

Ikatkan URL, algoritma yang dirundingkan, ETag asas, dan ETag respons; sahkan IM dan Delta-Base; halang perantara daripada menggunakan semula delta untuk asas yang lain; dan sahkan integriti entiti yang digabungkan.