Gesaan dan skop
Reka bentuk perkhidmatan storan data luaran yang boleh saling kendali untuk pelbagai aplikasi. Klien mesti boleh menemui storan, meminta akses baca/tulis, mencipta sumber, dan melanggan perubahan. Terangkan pemodelan sumber, semantik HTTP, pengesahan, keserentakan, pemberitahuan, dan pembalikan (rollback).
W3C Linked Web Storage Protocol 1.0 kini merupakan Draf Kerja (Working Draft). Ia bertujuan untuk memberikan aplikasi akses yang selamat, berizin, dan boleh saling kendali kepada data yang disimpan secara luaran. Spesifikasi ini menggunakan hubungan Link untuk menemui storan dan sumber induk, mengurus metadata melalui linkset, dan memerlukan keatoman antara kemas kini metadata dan operasi sumber. Soalan ini menguji sempadan protokol dan pengendalian kegagalan tanpa menganggap draf tersebut sebagai piawaian yang stabil.
Perkara yang dinilai oleh penemu duga
Penemu duga mencari pemisahan antara sumber, keizinan, identiti, metadata, dan pemberitahuan, serta pengendalian yang betul bagi percubaan semula POST, PATCH serentak, respons 405/415, caching, dan pembatalan (revocation). Jawapan yang mantap mengakui ketidaktentuan Draf Kerja dan memilih antara suite identiti OpenID Connect, SAML, dan swapendudukan (self-signed) berdasarkan keperluan penggunaan.
Soalan penjelasan sebelum menjawab
- Siapakah yang mengendalikan pemilik data, aplikasi, dan perkhidmatan storan, dan di manakah sempadan kepercayaan?
- Apakah operasi yang diperlukan: baca, cipta, kemas kini, padam, perkongsian, atau langganan baca sahaja?
- Adakah keizinan diberikan mengikut pengguna, ejen, laluan sumber, tindakan, atau tetingkap masa?
- Adakah akses rentas wilayah, penggunaan luar talian, audit, pembatalan, dan pemberitahuan konsistensi akhirnya diperlukan?
- Bolehkah klien mengendalikan penemuan Link, ETag, respons 405/415, dan penyahduplikasian percubaan semula?
Kerangka jawapan 30 saat
“Saya akan memodelkan storan, bekas (container), sumber data, linkset, identiti, dan geran secara berasingan. Klien menemui storan dan induknya melalui hubungan Link, mengesahkan dengan suite yang diisytiharkan, dan menyerahkan permintaan yang mengandungi tindakan, subjek, sasaran, dan kekangan. Penciptaan menggunakan POST, tetapi kunci keidempotenan atau penyahduplikasian menghalang duplikasi percubaan semula; PATCH metadata memerlukan syarat keserentakan dan melakukan komit secara atomik dengan operasi sumber. Perkhidmatan ini menggunakan ETag, pengepala keupayaan, dan ralat berstruktur untuk konflik, manakala baris gilir yang boleh dicuba semula menghantar pemberitahuan yang akhirnya konsisten. Setiap kanari mengekalkan pembatalan, versi keizinan lama, dan pembalikan audit.”
Jawapan mendalam langkah demi langkah
1. Menetapkan model sumber dan penemuan
Asingkan storan, bekas, sumber data, dan linkset. Respons GET atau HEAD mendedahkan punca storan, induk, jenis, dan linkset melalui hubungan Link; klien tidak boleh menganggap susun atur URL sebagai kontrak protokol. Perihalan storan harus mengiklankan keupayaan pelayan dan jenis media supaya klien berunding sebelum menghantar PUT atau PATCH tertentu.
2. Memodelkan keizinan sebagai geran yang boleh diaudit
Sesuatu geran harus merangkumi penerima serah hak, tindakan, sasaran, kekangan, pengeluar, kesahan, dan status pembatalan. Perkhidmatan storan menyemak identiti pemanggil dan versi geran, kemudian menguatkuasakan hak istimewa paling sedikit untuk membaca, mencipta, mengemas kini, atau memadam. OpenID Connect, SAML, atau identiti swapendudukan boleh membuktikan identiti, tetapi pengesahan dan kebenaran sumber kekal berasingan; log masuk yang berjaya tidak membayangkan akses kepada setiap sumber.
3. Menentukan semantik penciptaan, kemas kini, dan keserentakan
Spesifikasi mencipta sumber dengan POST dan URI akhir yang ditetapkan oleh pelayan, mengembalikan 201 dan Location. POST tidak bersifat idempoten, jadi percubaan semula memerlukan pengecam permintaan unik atau rekod penyahduplikasian. PATCH linkset ialah kemas kini metadata utama; gunakan ETag, If-Match, atau semakan versi yang setara untuk mengelakkan kemas kini yang hilang. Kembalikan 405 untuk kaedah yang tidak disokong dan 415 untuk jenis media yang tidak disokong.
POST /alice/notes/ HTTP/2
Idempotency-Key: 7b3c...
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Content-Type: text/plain
meeting notes4. Memastikan sumber dan metadata konsisten
Penciptaan, keahlian bekas, dan metadata pelayan yang diperlukan mesti dikomit secara atomik; kegagalan tidak boleh meninggalkan sumber yang kelihatan tanpa hubungan induk atau linkset. Merentasi shard, gunakan log transaksi atau outbox untuk merekodkan keadaan. API baca boleh mendedahkan keadaan belum selesai, dikomit, atau gagal dan bukannya membuat inferens kejayaan komit daripada urutan pemberitahuan.
5. Mereka bentuk pemberitahuan dan perundingan keupayaan
Tulis peristiwa perubahan ke outbox yang boleh dicuba semula, kemudian hantarkannya ke inbox pelanggan. Sertakan storan, sumber, tindakan, dan versi; pengguna menyahduplikasi mengikut ID peristiwa dan menggunakan GET untuk mengesahkan keadaan semasa. Pulihkan pemberitahuan yang hilang dengan main semula atau penyesuaian berkala, dan pastikan pemprosesan pendua kekal idempoten. Perundingan Prefer, Link, dan jenis media membolehkan klien menerima pakai keupayaan secara berperingkat dan bukannya menganggap setiap pelayan menyokong satu model PATCH atau langganan.
6. Mengendalikan pengesahan, pembatalan, dan pembalikan
Sertakan penggiliran kunci, khalayak token, herotan jam (clock skew), dan laluan pembatalan dalam reka bentuk pengesahan. Tulis perubahan keizinan pada log audit berversi dan jadikan pembatalan berkesan selepas semakan kebenaran dan pembatalan cache. Lakukan penggunaan kanari pada penyewa berisiko rendah terlebih dahulu, memerhatikan 401/403, 405/415, kadar konflik, penciptaan pendua, kependaman pemberitahuan, dan kesempurnaan audit; hentikan sekiranya berlaku peningkatan keistimewaan atau data terbiar dan pulihkan dasar kebenaran lama.
Contoh jawapan berkualiti tinggi
Saya akan mengasingkan storan, bekas, sumber data, linkset, identiti, dan geran. Klien menemui punca storan, induk, jenis, dan linkset melalui hubungan Link pada GET/HEAD, kemudian berunding tentang keupayaan sebelum menulis. Sesuatu geran mengandungi subjek, tindakan, sasaran, kekangan, kesahan, dan pembatalan; OpenID Connect, SAML, atau identiti swapendudukan membuktikan identiti tetapi tidak memberikan akses sumber. POST mengembalikan 201 dan Location; oleh sebab ia tidak idempoten, klien menggunakan ID permintaan unik atau penyahduplikasian. PATCH linkset menggunakan ETag/If-Match untuk menghalang kemas kini serentak yang hilang, dan kaedah atau jenis media yang tidak disokong mengembalikan 405/415. Penciptaan, keahlian, dan metadata pelayan dikomit secara atomik. Peristiwa outbox dihantar ke inbox yang boleh dicuba semula, dan pengguna menyahduplikasi mengikut ID peristiwa dan menyesuaikan dengan GET. Pelancaran kanari memerhatikan 401/403, konflik, pendua, kependaman pemberitahuan, dan kesempurnaan audit; peningkatan keistimewaan, sumber terbiar, atau pembalikan yang gagal akan menghentikan pelancaran. Memandangkan protokol ini merupakan Draf Kerja, protokol akhir dan matriks ujian mesti mempunyai versi.
Kesilapan biasa
- Menganggap laluan URL sebagai keseluruhan kontrak protokol → penemuan dan perundingan keupayaan terjejas → bergantung pada hubungan Link, jenis media, dan pengepala keupayaan.
- Mencuba semula POST tanpa syarat → sumber pendua mungkin dicipta → gunakan kunci keidempotenan, rekod penyahduplikasian, dan bacaan keadaan akhir.
- Menyemak log masuk tetapi bukan kebenaran → identiti tidak membayangkan akses kepada sasaran → nilai subjek, tindakan, sasaran, dan kekangan.
- Mengkomit metadata secara berasingan daripada sumber → sumber terbiar atau linkset yang salah muncul → gunakan transaksi atomik atau outbox yang boleh dipulihkan.
- Menganggap setiap pelayan menyokong PUT/PATCH → klien menjadi rapuh → temui keupayaan dan kendalikan 405/415.
Soalan susulan dan respons
Mengapakah percubaan semula POST tidak boleh bergantung pada TCP atau HTTP sahaja?
Sambungan mungkin gagal selepas pelayan melakukan komit, menyebabkan klien tidak mengetahui keputusannya. ID permintaan unik dan pertanyaan status mengaitkan percubaan semula dengan komit asal.
Bagaimanakah anda mengelakkan kelengahan pembatalan daripada cache keizinan?
Gunakan geran berversi dengan TTL yang pendek, batalkan cache yang terjejas secara aktif selepas penulisan audit, dan semak semula versi kebenaran untuk penulisan kritikal.
Bagaimanakah anda memulihkan pemberitahuan yang hilang?
Kekalkan peristiwa dalam outbox, cuba semula penghantaran, simpan kursor pengguna, sesuaikan mengikut versi sumber, dan main semula log peristiwa apabila perlu.
Mengapakah kemas kini linkset mesti bersifat atomik?
Jika sumber berjaya tetapi metadata keahlian atau jenis gagal, penemuan, kebenaran, dan cache akan melihat keadaan yang tidak konsisten. Komit atomik menghalang sumber yang dicipta separuh jalan daripada kelihatan.
Bagaimanakah anda mengawal pelaburan semasa Draf Kerja?
Gunakan penyesuai terpencil dan matriks ujian berversi, uji pada trafik berisiko rendah sahaja, kekalkan protokol lama dan laluan migrasi, serta kembangkan selepas spesifikasi dan laporan pelaksanaan stabil.