Petunjuk dan skenario
Sebuah API menyajikan dokumen dengan validator versi. Beberapa klien dapat membaca dan mengeditnya secara bersamaan, dan persyaratannya adalah menolak penulisan yang usang (stale writes) sambil menjaga API tetap dapat dicoba ulang dan dapat diobservasi.
Hal yang diuji oleh pewawancara
- Membedakan caching representasi dari prasyarat penulisan.
- Memilih ETag yang kuat dan memberlakukan
If-Matchpada metode mutasi. - Mengembalikan 412 pada versi yang usang dan menentukan jalur pemulihan klien yang aman.
Pertanyaan klarifikasi sebelum menjawab
- Apakah ETag mewakili representasi tersimpan yang tepat atau hanya versi semantik yang lemah?
- Metode mana yang memerlukan prasyarat: PUT, PATCH, DELETE, atau semua penulisan?
- Haruskah klien menggabungkan (merge) kolom secara otomatis, atau harus manusia yang menyelesaikan konflik?
- Apakah percobaan ulang dikirim melalui API dengan load balancing dan satu datastore transaksional?
Kerangka jawaban 30 detik
Saya akan mengembalikan ETag kuat bersama setiap representasi yang dapat diedit. Klien mengirimkan nilai tersebut dalam If-Match pada PUT, PATCH, atau DELETE. Server membandingkannya di dalam transaksi yang sama dengan pembaruan; ketidakcocokan akan mengembalikan 412 tanpa menerapkan mutasi. Respons harus menyertakan representasi saat ini atau sinyal untuk mengambil ulang (refetch), sementara metrik melacak konflik dan prasyarat yang hilang. Klien kemudian mengambil ulang, menggabungkan secara sengaja, dan mencoba lagi dengan ETag yang baru.
Pembahasan mendalam langkah demi langkah
1. Menerbitkan validator
Pada GET, kembalikan dokumen dan ETag yang diturunkan dari versi kanonikal yang disimpan. Nomor revisi database bisa lebih sederhana daripada melakukan hashing pada payload yang besar, asalkan nilainya berubah setiap kali representasi yang relevan dengan pengeditan berubah. Gunakan validator yang kuat untuk If-Match; validator lemah tidak cocok untuk melindungi status penulisan yang tepat.
2. Terapkan prasyarat secara atomik
Pembaruan harus memeriksa versi yang diharapkan dan menulis versi baru sebagai satu operasi bersyarat. Secara konseptual:
UPDATE documents
SET body = :new_body, version = version + 1
WHERE id = :id AND version = :expected_version;Jika jumlah baris yang terpengaruh adalah nol, kembalikan 412 dan jangan lakukan efek samping apa pun. Memeriksa ETag di memori aplikasi lalu menulisnya kemudian akan menciptakan kondisi race condition antara pemeriksaan dan commit.
3. Pisahkan 412 dari kegagalan lainnya
412 berarti prasyarat yang diberikan salah; ini adalah konflik konkurensi, bukan JSON yang salah format dan bukan kegagalan autentikasi. Kembalikan 400 untuk bentuk permintaan yang tidak valid, 401 atau 403 untuk otorisasi, dan 404 jika sumber daya tidak tersedia berdasarkan kebijakan API. Perbedaan ini memungkinkan klien memilih antara mengambil ulang lalu menggabungkan (refetch-and-merge) versus koreksi manual oleh pengguna.
4. Rancang pemulihan klien
Setelah 412, ambil dokumen saat ini dan tampilkan kolom yang berkonflik atau sebuah diff. Penggabungan otomatis hanya aman jika semantik tingkat kolom dan aturan otorisasi menjadikannya aman. Percobaan ulang harus menggunakan ETag baru yang dikembalikan dan tetap idempoten pada tingkat sumber daya; jangan pernah memutar ulang permintaan usang secara membabi buta.
5. Jaga koherensi cache dan replika
Hasilkan validator dari status ter-commit yang terlihat oleh jalur penulisan. Pembacaan dari replika yang tertinggal (lagging) dapat mengembalikan ETag lama dan menyebabkan konflik yang seharusnya dapat dihindari, sementara penulisan yang diarahkan ke node lain harus tetap memberlakukan versi tersebut dalam transaksi utama. Publikasikan metrik tingkat konflik, tingkat ketiadaan If-Match, dan tingkat keberhasilan percobaan ulang.
Contoh jawaban berkualitas tinggi
“Saya akan mengembalikan ETag kuat untuk setiap dokumen yang dapat diedit dan mewajibkan If-Match pada mutasi. Server akan membandingkan tag tersebut dalam transaksi yang sama yang memperbarui baris, menggunakan pembaruan versi bersyarat. Jika tidak ada baris yang cocok, server mengembalikan 412 dan tidak menerapkan efek samping. Klien mengambil ulang data, menyajikan diff atau melakukan penggabungan yang didefinisikan secara ketat, lalu mencoba lagi dengan ETag yang baru. Saya akan membedakan 412 dari kesalahan validasi dan otorisasi, serta memantau tingkat pembacaan usang, konflik, dan keberhasilan percobaan ulang.”
Kesalahan umum
- Memeriksa ETag, lalu memperbarui dalam operasi terpisah → race condition tetap ada → lakukan predikat versi dan penulisan secara atomik.
- Menggunakan validator lemah untuk penulisan yang tepat → konten yang mirip secara semantik dapat dibandingkan secara keliru → gunakan validator kuat.
- Mengembalikan 409 untuk setiap penulisan usang → klien tidak dapat membedakan prasyarat protokol → gunakan 412 untuk kondisi
If-Matchyang gagal. - Mencoba ulang payload yang usang secara membabi buta → perubahan editor pertama dapat hilang → ambil ulang, gabungkan dengan sengaja, dan coba lagi dengan tag baru.
Pertanyaan lanjutan dan jawabannya
Apakah ETag hanya untuk caching?
Tidak. If-None-Match umumnya memungkinkan validasi cache, sedangkan If-Match membuat penulisan bersyarat pada representasi saat ini. Validator yang sama dapat melayani kedua peran jika kekuatan perbandingan dan kebijakan pembuatannya benar.
Bagaimana jika klien menghilangkan If-Match?
Untuk sumber daya yang memerlukan konkurensi optimis, tolak mutasi dengan respons precondition-required yang terdokumentasi atau kebijakan 400 yang jelas. Menerima penulisan tanpa syarat secara diam-diam akan memunculkan kembali masalah pembaruan yang hilang (lost updates); kebijakan harus konsisten di seluruh metode.
Haruskah server mengembalikan dokumen terbaru dalam respons 412?
Bisa saja, jika otorisasi dan ukuran payload memungkinkan, tetapi kontrak harus tetap memerlukan pengambilan ulang atau penyelesaian konflik eksplisit. Mengembalikan data tidak memberi wewenang kepada klien untuk menimpanya tanpa menggunakan validator terbaru.