Temu duga backend: Bagaimanakah HTTP Prefer sepatutnya merundingkan respons tanpa merosakkan keidempotenan dan pembenaman cache?

Kehendak soalan dan skop

Satu API penulisan kelompok melayani klien dengan matlamat lebar jalur dan kependaman yang berbeza: ada yang hanya memerlukan status, ada yang memerlukan perwakilan sumber yang lengkap, dan ada yang sanggup menunggu beberapa saat untuk mengelakkan pengundian (polling). Dengan menggunakan RFC 7240, reka bentuk pengepala permintaan Prefer, pengepala respons Preference-Applied, pengendalian ralat, pembenaman cache, dan tingkah laku sandaran.

Prefer ialah keutamaan permintaan, bukannya mandat pelayan. Soalan ini menguji semantik protokol dan kontrak API; ia tidak menganggap setiap proksi mengekalkan pengepala keutamaan.

Perkara yang diuji oleh penemu duga

Sama ada anda membezakan keutamaan klien daripada janji pelayan dan melaporkan perkara yang sebenarnya digunakan.
Sama ada anda menggunakan return=minimal, return=representation, respond-async, dan wait dengan betul.
Sama ada anda mengambil kira varian respons, Vary, kunci cache, dan keserasian proksi.
Sama ada percubaan semula, kunci keidempotenan, dan keadaan tugas tak segerak kekal selamat apabila sesuatu keutamaan tidak dipenuhi.

Soalan penjelasan

Adakah API tersebut merupakan bacaan selamat atau penulisan dengan kesan sampingan (side-effecting), dan adakah ia sudah mempunyai kunci keidempotenan?
Apakah saiz, kos penjanaan, dan masa menunggu maksimum untuk perwakilan penuh?
Bolehkah klien menerima 202 dan sumber status, pengundian, atau panggilan balik (callback)?
Adakah middlebox akan memajukan Prefer, dan bolehkah cache dikongsi?
Medan stabil manakah yang mesti dilihat oleh klien apabila sesuatu keutamaan tidak dipenuhi?

Jawapan 30 saat

“Prefer menyatakan keutamaan klien yang boleh diabaikan atau digunakan sebahagiannya oleh pelayan; Preference-Applied melaporkan perkara yang telah digunakan. Operasi penulisan boleh menggunakan return=minimal untuk mengurangkan respons, pemanggil segerak boleh meminta return=representation, dan operasi yang panjang boleh menggunakan respond-async dengan wait yang berbatas. Saya akan mereka bentuk kunci keidempotenan, sumber status 202, Vary cache, dan sandaran klien secara bersama: tanpa Preference-Applied, huraikan respons lalai dan jangan sekali-kali menganggap keutamaan tersebut telah berjaya.”

Reka bentuk langkah demi langkah

1. Anggap keutamaan sebagai perundingan yang boleh diabaikan

RFC 7240 mentakrifkan pengepala permintaan Prefer dan pengepala respons Preference-Applied. Pelayan boleh menolak sesuatu keutamaan, jadi badan dan kod status memerlukan kontrak lalai yang stabil. Klien tidak boleh melangkau penghuraian semata-mata kerana ia telah menghantar Prefer.

2. Pilih token keutamaan yang betul

return=minimal sesuai untuk penulisan yang hanya memerlukan pengesahan; return=representation sesuai untuk pemanggil segerak yang memerlukan sumber yang dikemas kini. respond-async menyatakan bahawa klien menerima pemprosesan tak segerak, manakala wait=n memberikan belanjawan masa menunggu. Ini adalah petunjuk, bukannya jaminan SLA.

3. Sahkan hasil dalam respons

Hantar Preference-Applied apabila keutamaan digunakan. Apabila ia tidak digunakan, pengepala tersebut mungkin tiada dan kontrak lalai diguna pakai. Laluan tak segerak mengembalikan 202, URI status, dan ID yang boleh dijejaki; selepas belanjawan masa menunggu segerak tamat, operasi tersebut kekal boleh ditanya dan bukannya menyebabkan klien menghantar semula kesan sampingan.

http

POST /v1/imports HTTP/1.1
Prefer: return=minimal, respond-async, wait=3
Idempotency-Key: imp-8f2

HTTP/1.1 202 Accepted
Preference-Applied: respond-async
Location: https://api.example/imports/jobs/42
Cache-Control: no-store

4. Kendalikan varian cache

Jika perwakilan GET yang selamat berbeza-beza mengikut Prefer, isytiharkan Vary dengan betul atau jauhkan respons yang bergantung pada keutamaan daripada cache yang dikongsi. Operasi penulisan biasanya menggunakan no-store. Sumber status tak segerak harus mentakrifkan pembenaman cache yang singkat, ETag, atau syarat pengundian yang eksplisit supaya middlebox tidak mengembalikan kemajuan yang basi.

5. Kekalkan keidempotenan dan sandaran

Prefer tidak mengubah semantik operasi, jadi percubaan semula masih memerlukan keidempotenan. Gunakan kunci keidempotenan atau penyahduplikasian perniagaan untuk operasi penulisan. Jika klien melihat 202, tamat masa, atau ketiadaan Preference-Applied, ia harus menanya tugas tersebut atau mengikut kontrak respons lalai dan bukannya mencipta semula sumber tersebut.

6. Tetapkan kebolehcerapan dan had

Rekodkan token keutamaan, sama ada ia telah digunakan, tempoh menunggu, saiz respons, kadar 202, dan laluan proksi. Hadkan wait, dengan menolak atau memotong nilai yang berlebihan. Abaikan dan rekodkan keutamaan yang tidak diketahui daripada menukar rentetan klien yang sewenang-wenangnya menjadi laluan pelaksanaan yang mahal.

Model jawapan berkualiti tinggi

“Saya akan menganggap Prefer sebagai keutamaan klien yang boleh diabaikan, bukan satu janji. Operasi penulisan secara lalai menghasilkan status yang stabil; klien yang mahukan respons kecil menghantar return=minimal, yang memerlukan sumber menghantar return=representation, dan tugas yang panjang menggunakan respond-async dengan wait yang berbatas. Pelayan hanya menghantar Preference-Applied apabila ia menggunakan keutamaan tersebut; hasil tak segerak ialah 202 dengan Location dan ID tugas. Operasi penulisan menggunakan kunci keidempotenan, respons menggunakan no-store jika bersesuaian, dan perbezaan perwakilan diasingkan dengan Vary atau dasar cache. Tanpa Preference-Applied, klien mengikut penghurai lalai dan menanya tugas, tanpa menduplikasi kesan sampingan sama sekali.”

Kesilapan lazim

Menganggap Prefer sebagai mandatori → pelayan dan proksi mungkin mengabaikannya → gunakan kontrak lalai dan Preference-Applied.
Menganggap wait sebagai jaminan penyelesaian → tugas yang panjang masih boleh melebihi had tersebut → hadkan belanjawan dan sediakan sumber status 202.
Menghantar semula selepas tamat masa tak segerak → mengakibatkan kesan sampingan pendua → gunakan kunci keidempotenan dan tanya status terlebih dahulu.
Mengabaikan varian cache → klien menerima perwakilan yang tidak sepadan → tetapkan Vary atau asingkan cache.
Melaksanakan keutamaan tidak diketahui yang sewenang-wenangnya → penyerang boleh meningkatkan kos sumber → abaikan, rekod, dan hadkan token.

Soalan susulan dan jawapan

Adakah ketiadaan Preference-Applied bermaksud permintaan itu gagal?

Tidak. Pelayan boleh memilih tingkah laku lalainya atau mengabaikan keutamaan tersebut. Klien harus menghuraikan kontrak lalai yang stabil dan hanya menganggapnya sebagai kegagalan apabila protokol atau keadaan perniagaan menyatakan ia gagal.

Bolehkah setiap penulisan menggunakan return=minimal?

Tidak. Ia hanya menyatakan bahawa klien tidak memerlukan perwakilan penuh. Jika klien memerlukan versi, digest, atau pautan seterusnya yang dijana oleh pelayan, ia harus meminta perwakilan tersebut atau mengambil sumber tersebut dan bukannya menyimpulkan medan daripada respons yang kosong.

Adakah wait=5 menyebabkan pelayan menyekat (block) selama lima saat?

Tiada jaminan mutlak diberikan. Ia merupakan had keutamaan masa menunggu klien; pelayan mungkin selesai lebih awal, mengabaikannya, atau beralih kepada mod tak segerak. Had masa tamat pelayan, had keserentakan, dan belanjawan sumber masih diguna pakai.