Konteks dan cakupan
Rancang layanan penyimpanan data eksternal yang dapat dioperasikan bersama (interoperable) untuk beberapa aplikasi. Klien harus dapat menemukan penyimpanan, meminta akses baca/tulis, membuat sumber daya, dan berlangganan perubahan. Jelaskan pemodelan sumber daya, semantik HTTP, autentikasi, konkurensi, notifikasi, dan rollback.
W3C Linked Web Storage Protocol 1.0 saat ini berstatus Working Draft. Protokol ini bertujuan untuk memberi aplikasi akses yang aman, berizin, dan dapat dioperasikan bersama ke data yang disimpan secara eksternal. Spesifikasi ini menggunakan relasi Link untuk menemukan penyimpanan dan sumber daya induk (parent), mengelola metadata melalui linkset, serta membutuhkan atomisitas antara pembaruan metadata dan operasi sumber daya. Pertanyaan ini menguji batasan protokol dan penanganan kegagalan tanpa memperlakukan draf tersebut sebagai standar yang sudah stabil.
Apa yang dinilai oleh pewawancara
Pewawancara mencari pemisahan antara sumber daya, izin, identitas, metadata, dan notifikasi, ditambah penanganan yang benar terhadap percobaan ulang POST, PATCH yang konkuren, respons 405/415, caching, dan pencabutan izin (revocation). Jawaban yang kuat mengakui ketidakpastian Working Draft dan memilih antara suite identitas OpenID Connect, SAML, dan self-signed berdasarkan kebutuhan deployment.
Pertanyaan klarifikasi sebelum menjawab
- Siapa yang mengoperasikan pemilik data, aplikasi, dan layanan penyimpanan, serta di mana batas kepercayaannya (trust boundaries)?
- Operasi apa saja yang diperlukan: baca, buat, perbarui, hapus, berbagi, atau langganan baca-saja?
- Apakah izin diberikan berdasarkan pengguna, agen, path sumber daya, tindakan, atau jendela waktu?
- Apakah akses lintas wilayah (cross-region), penggunaan luring, audit, pencabutan izin, dan notifikasi konsistensi akhir (eventual notification) diperlukan?
- Apakah klien dapat menangani discovery Link, ETag, respons 405/415, dan deduplikasi percobaan ulang?
Kerangka jawaban 30 detik
“Saya akan memodelkan penyimpanan, kontainer, sumber daya data, linkset, identitas, dan grant secara terpisah. Klien menemukan penyimpanan dan induknya melalui relasi Link, melakukan autentikasi dengan suite yang dideklarasikan, dan mengirimkan permintaan yang berisi tindakan, subjek, target, serta batasan. Pembuatan menggunakan POST, tetapi kunci idempoten atau deduplikasi mencegah duplikasi akibat percobaan ulang; PATCH metadata membutuhkan kondisi konkurensi dan dikomit secara atomik bersama operasi sumber daya. Layanan menggunakan ETag, header kapabilitas, dan pesan kesalahan terstruktur untuk konflik, sementara antrean yang dapat dicoba ulang mengirimkan notifikasi yang konsisten secara bertahap (eventually consistent). Setiap canary mempertahankan pencabutan izin, versi izin lama, dan rollback audit.”
Jawaban mendalam langkah demi langkah
1. Menetapkan model sumber daya dan discovery
Pisahkan penyimpanan, kontainer, sumber daya data, dan linkset. Respons GET atau HEAD mengekspos root penyimpanan, induk, tipe, dan linkset melalui relasi Link; klien tidak boleh memperlakukan struktur URL sebagai kontrak protokol. Deskripsi penyimpanan harus mengiklankan kapabilitas server dan tipe media sehingga klien bernegosiasi sebelum mengirimkan PUT atau PATCH tertentu.
2. Memodelkan izin sebagai grant yang dapat diaudit
Sebuah grant harus mencakup pihak yang diberi izin (assignee), tindakan, target, batasan, penerbit, masa berlaku, dan status pencabutan. Layanan penyimpanan memeriksa identitas pemanggil dan versi grant, lalu menerapkan prinsip hak akses terendah (least-privilege) untuk membaca, membuat, memperbarui, atau menghapus. OpenID Connect, SAML, atau identitas self-signed dapat membuktikan identitas, tetapi autentikasi dan otorisasi sumber daya tetap terpisah; keberhasilan login tidak berarti memiliki akses ke setiap sumber daya.
3. Menentukan semantik pembuatan, pembaruan, dan konkurensi
Spesifikasi membuat sumber daya dengan POST dan URI akhir yang ditetapkan oleh server, mengembalikan 201 dan Location. POST tidak bersifat idempoten, sehingga percobaan ulang memerlukan pengidentifikasi permintaan unik atau catatan deduplikasi. PATCH linkset adalah pembaruan metadata utama; gunakan ETag, If-Match, atau pemeriksaan versi yang setara untuk mencegah pembaruan yang hilang (lost updates). Kembalikan 405 untuk metode yang tidak didukung dan 415 untuk tipe media yang tidak didukung.
POST /alice/notes/ HTTP/2
Idempotency-Key: 7b3c...
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Content-Type: text/plain
meeting notes4. Menjaga konsistensi sumber daya dan metadata
Pembuatan, keanggotaan kontainer, dan metadata server yang diperlukan harus dikomit secara atomik; kegagalan tidak boleh meninggalkan sumber daya yang terlihat tanpa relasi induk atau linkset. Di seluruh shard, gunakan log transaksi atau outbox untuk mencatat status. API baca dapat mengekspos status pending, committed, atau failed daripada menyimpulkan keberhasilan komit dari urutan notifikasi.
5. Merancang notifikasi dan negosiasi kapabilitas
Tulis peristiwa perubahan ke outbox yang dapat dicoba ulang, lalu kirimkan ke inbox pelanggan. Sertakan penyimpanan, sumber daya, tindakan, dan versi; konsumen melakukan deduplikasi berdasarkan ID peristiwa dan menggunakan GET untuk memverifikasi status saat ini. Pulihkan notifikasi yang hilang dengan pemutaran ulang (replay) atau rekonsiliasi berkala, dan jaga agar pemrosesan duplikat tetap idempoten. Negosiasi Prefer, Link, dan tipe media memungkinkan klien mengadopsi kapabilitas secara bertahap alih-alih mengasumsikan setiap server mendukung satu model PATCH atau langganan yang sama.
6. Menangani autentikasi, pencabutan izin, dan rollback
Sertakan rotasi kunci, audiens token, clock skew, dan jalur pencabutan izin dalam desain autentikasi. Tulis perubahan izin ke log audit berversi dan buat pencabutan izin berlaku efektif setelah pemeriksaan otorisasi dan pembatalan cache (cache invalidation). Lakukan rilis canary pada tenant berisiko rendah terlebih dahulu, amati respons 401/403, 405/415, tingkat konflik, pembuatan duplikat, latensi notifikasi, dan kelengkapan audit; hentikan rilis jika terjadi eskalasi hak istimewa atau data tanpa induk (orphaned data) dan pulihkan kebijakan otorisasi lama.
Contoh jawaban berkualitas tinggi
Saya akan memisahkan penyimpanan, kontainer, sumber daya data, linkset, identitas, dan grant. Klien menemukan root penyimpanan, induk, tipe, dan linkset melalui relasi Link pada GET/HEAD, lalu menegosiasikan kapabilitas sebelum melakukan penulisan. Sebuah grant berisi subjek, tindakan, target, batasan, masa berlaku, dan pencabutan; OpenID Connect, SAML, atau identitas self-signed membuktikan identitas tetapi tidak memberikan akses sumber daya secara langsung. POST mengembalikan 201 dan Location; karena tidak idempoten, klien menggunakan ID permintaan unik atau deduplikasi. PATCH linkset menggunakan ETag/If-Match untuk mencegah hilangnya pembaruan konkuren, dan metode atau tipe media yang tidak didukung mengembalikan 405/415. Pembuatan, keanggotaan, dan metadata server dikomit secara atomik. Peristiwa outbox dikirim ke inbox yang dapat dicoba ulang, dan konsumen melakukan deduplikasi berdasarkan ID peristiwa serta merekonsiliasi dengan GET. Peluncuran canary memantau 401/403, konflik, duplikasi, latensi notifikasi, dan kelengkapan audit; eskalasi hak istimewa, sumber daya tanpa induk, atau kegagalan rollback akan menghentikan peluncuran. Karena protokol ini berstatus Working Draft, protokol akhir dan matriks pengujian harus diberi versi.
Kesalahan umum
- Memperlakukan path URL sebagai keseluruhan kontrak protokol → discovery dan negosiasi kapabilitas menjadi rusak → bergantunglah pada relasi Link, tipe media, dan header kapabilitas.
- Mencoba ulang POST tanpa syarat → sumber daya duplikat dapat tercipta → gunakan kunci idempoten, catatan deduplikasi, dan pembacaan status akhir.
- Memeriksa login tetapi tidak memeriksa otorisasi → identitas tidak berarti memiliki akses ke target → evaluasi subjek, tindakan, target, dan batasan.
- Mengomit metadata secara terpisah dari sumber daya → muncul sumber daya tanpa induk atau linkset yang salah → gunakan transaksi atomik atau outbox yang dapat dipulihkan.
- Mengasumsikan setiap server mendukung PUT/PATCH → klien menjadi rapuh → temukan kapabilitas terlebih dahulu dan tangani 405/415.
Pertanyaan lanjutan dan tanggapan
Mengapa percobaan ulang POST tidak dapat hanya mengandalkan TCP atau HTTP saja?
Koneksi dapat terputus setelah server melakukan komit, sehingga klien tidak mengetahui hasilnya. ID permintaan unik dan kueri status mengaitkan percobaan ulang dengan komit yang asli.
Bagaimana cara menghindari keterlambatan pencabutan izin (revocation lag) dari cache izin?
Gunakan grant berversi dengan TTL pendek, batalkan cache yang terpengaruh secara aktif setelah penulisan audit, dan periksa kembali versi otorisasi untuk operasi penulisan kritis.
Bagaimana cara memulihkan notifikasi yang hilang?
Simpan peristiwa di outbox, coba lagi pengiriman, simpan kursor konsumen, rekonsiliasi berdasarkan versi sumber daya, dan putar ulang log peristiwa jika diperlukan.
Mengapa pembaruan linkset harus bersifat atomik?
Jika sumber daya berhasil dibuat tetapi metadata keanggotaan atau tipe gagal, maka discovery, otorisasi, dan cache akan mengamati status yang tidak konsisten. Komit atomik mencegah sumber daya yang baru dibuat sebagian terlihat oleh publik.
Bagaimana cara mengontrol investasi selama status Working Draft?
Gunakan adaptor terisolasi dan matriks pengujian berversi, uji coba hanya pada traffic berisiko rendah, pertahankan protokol lama dan jalur migrasi, lalu lakukan ekspansi setelah spesifikasi dan laporan implementasi stabil.