Wawancara umum: Kapan HTTP 208 Already Reported harus digunakan, dan bagaimana cara menghindari penyalahgunaannya?

Perintah dan ruang lingkup

Layanan WebDAV memungkinkan beberapa binding mengarah ke sumber daya yang sama. Klien mengirim PROPFIND dengan Depth infinity, dan server menemukan sumber daya tersebut berulang kali dalam satu respons 207 Multi-Status. Jelaskan 208 Already Reported, kapan harus memancarkannya, cara menangani klien lama, dan perbedaannya dari 508 Loop Detected.

Ini adalah ekstensi binding WebDAV RFC 5842. 208 bukanlah kode sukses REST generik untuk "already exists".

Apa yang sedang diuji oleh pewawancara

Mengidentifikasi 208 sebagai baris status di dalam respons 207 Multi-Status, bukan status respons HTTP mandiri.
Menghubungkan alias binding, identitas sumber daya, dan enumerasi berulang.
Membedakan sumber daya yang sudah dilaporkan dari loop binding nyata dan menggunakan 508 secara benar.
Merancang batas Depth, penanganan kemampuan klien, penguraian XML, dan observabilitas.

Pertanyaan klarifikasi

Apakah layanan mengimplementasikan metode binding RFC 5842 dan DAV:resource-id?
Apakah klien memahami 208, atau hanya respons WebDAV 207 dasar?
Apakah PROPFIND Depth bernilai 0, 1, atau infinity, dan batasan server apa yang berlaku?
Apakah pengulangan disebabkan oleh binding, symbolic link, atau siklus induk-anak yang nyata?
Haruskah produk mencantumkan setiap alias, atau hanya melaporkan setiap sumber daya satu kali?

Jawaban 30 detik

"208 menandai sumber daya yang sudah dilaporkan dalam respons 207 Multi-Status yang sama, umumnya ketika binding WebDAV menyebabkan enumerasi berulang. Saya melakukan deduplikasi berdasarkan identitas sumber daya yang stabil, mengembalikan propstat lengkap untuk kemunculan pertama, dan menggunakan 208 untuk binding berikutnya; loop binding yang tidak dapat dihentikan dengan aman adalah 508. Untuk klien yang tidak memahami 208, saya membatasi Depth atau mengembalikan 207 yang dapat diurai dalam kontrak WebDAV, dan mencatat alasan deduplikasi, kedalaman, loop, serta pemotongan. Saya tidak akan pernah menggunakan 208 untuk hasil REST biasa 'already exists'."

Desain langkah demi langkah

1. Konfirmasikan lapisan respons

Respons HTTP luar biasanya adalah 207 Multi-Status. Setiap respons berisi URI sumber daya dan satu atau lebih elemen propstat. 208 adalah baris status di dalam respons properti DAV yang relevan, yang menunjukkan bahwa sumber daya binding tersebut telah dilaporkan dalam respons Multi-Status ini. Jangan mengganti 207 luar dengan 208.

2. Deduplikasi berdasarkan identitas sumber daya

URI belum tentu merupakan identitas sumber daya. Binding yang berbeda dapat mengekspos URI yang berbeda untuk satu sumber daya. Gunakan DAV:resource-id atau ID internal yang stabil untuk himpunan yang telah dikunjungi per traversal. Pancarkan properti lengkap untuk pertemuan pertama, lalu 208 untuk binding berikutnya sambil mempertahankan hubungan masing-masing URI.

text

PROPFIND Depth: infinity
  /alias-a -> resource R: full propstat
  /alias-b -> resource R: 208 Already Reported
  /child   -> resource C: full propstat

3. Jaga 208 dalam konteks yang dimaksudkan

208 menghemat muatan properti 207 yang berulang dan mencegah enumerasi binding berkembang tanpa batas. Ini tidak berarti konflik penyisipan database, percobaan ulang idempoten berhasil, atau cache hit. API JSON biasa harus memilih semantik eksplisit 200, 201, 204, atau 409 sebagai gantinya.

4. Bedakan 508 Loop Detected

Jika penelusuran menemukan hubungan binding yang membentuk siklus alih-alih referensi kedua ke sumber daya yang sudah selesai, hentikan rekursi dan gunakan 508 Loop Detected. 208 berarti sumber daya berhasil dilaporkan sebelumnya; 508 berarti pemrosesan dihentikan untuk menghindari infinite loop. Uji alias, siklus nyata, dan batas kedalaman secara terpisah.

5. Tangani kompatibilitas dan batas sumber daya

Negosiasikan atau amati dukungan klien untuk 208. Untuk klien lama, batasi Depth infinity, tolak permintaan yang tidak aman, atau kembalikan konten propstat yang dapat dipahami tanpa melanggar semantik WebDAV. Batasi jumlah node, byte respons, waktu, dan memori himpunan yang dikunjungi sehingga graf binding yang berbahaya tidak dapat menghabiskan sumber daya layanan.

6. Amati dan pulihkan

Catat ID permintaan, Depth, jumlah sumber daya yang dikunjungi, jumlah 208, jumlah 508, alasan pemotongan, ukuran respons, dan kemampuan klien; jangan pernah mencatat konten file atau kredensial. Jika indeks deduplikasi gagal, potong dengan aman menggunakan pesan kesalahan eksplisit daripada memancarkan rekursi tanpa batas. Pertahankan graf binding yang dapat direproduksi untuk debugging identitas dan loop.

Model jawaban berkualitas tinggi

"Respons luar tetap 207 Multi-Status; 208 muncul dalam status propstat untuk menyatakan bahwa sumber daya yang sama telah dilaporkan sebelumnya. Untuk PROPFIND Depth infinity, saya membangun himpunan yang dikunjungi dari identitas sumber daya: binding pertama mengembalikan properti lengkap, dan alias berikutnya mengembalikan 208 sambil mempertahankan URI-nya. Siklus nyata berhenti dengan 508. Saya tidak akan menggunakan 208 untuk hasil already-exists atau retry pada API generik. Klien lama mendapatkan batas kedalaman atau penolakan yang aman, dan telemetri mencakup sumber daya, ukuran respons, 208, 508, dan pemotongan."

Kesalahan umum

Mengatur seluruh respons HTTP ke 208 → struktur 207 Multi-Status hilang → tempatkan 208 di status propstat yang relevan.
Menggunakan URI sebagai kunci sumber daya → alias masih menduplikasi sumber daya → lakukan deduplikasi berdasarkan ID sumber daya.
Menggunakan 208 untuk already-exists → klien REST generik salah menafsirkannya → gunakan 409 atau respons bisnis eksplisit.
Memperlakukan setiap duplikat sebagai 508 → alias normal terlihat seperti loop → pisahkan sumber daya yang dilaporkan dari siklus.
Tidak menetapkan batas Depth atau respons → graf binding dapat menghabiskan memori → batasi node, waktu, byte, dan ukuran himpunan yang dikunjungi.

Pertanyaan lanjutan dan tanggapan

Apakah entri 208 masih memerlukan URI?

Ya. Pertahankan respons untuk binding tersebut sehingga klien mengetahui URI mana yang ditelusuri, tetapi jangan ulangi muatan properti lengkap. XML harus mengikuti kontrak penguraian Multi-Status WebDAV.

Mengapa tidak menghapus entri duplikat sepenuhnya?

Penghapusan menyembunyikan fakta bahwa sebuah alias telah ditelusuri dan mungkin terlihat seperti kelalaian server. 208 mempertahankan bukti penelusuran sekaligus menghindari duplikasi data properti.

Kapan server harus menolak Depth infinity?

Tolak atau batasi ketika klien tidak dapat mengurai 208, graf binding melebihi batas sumber daya, atau himpunan yang dikunjungi yang andal tidak dapat dibangun. Respons yang dibatasi lebih aman daripada output yang tidak lengkap atau rekursi tanpa batas.