Wawancara Backend: Kapan HTTP 226 IM Used sebaiknya membawa delta?

Konteks dan cakupan

Sebuah API mengembalikan dokumen JSON berukuran besar dan klien menyimpan ETag sebelumnya. Jelaskan kapan HTTP 226 IM Used tepat digunakan, header apa saja yang dipertukarkan oleh klien dan server, serta bagaimana kebenaran data dipertahankan ketika delta tidak dapat diterapkan. Bahas negosiasi, caching, dan fallback; tidak diperlukan algoritma diff tertentu.

Yang sedang diuji oleh pewawancara

• Apakah Anda memahami bahwa 226 merepresentasikan delta untuk GET, bukan keberhasilan tidak lengkap yang arbitrer.
• Apakah Anda dapat menghubungkan A-IM, IM, ETag, dan Delta-Base opsional ke dalam satu pertukaran.
• Apakah Anda mengidentifikasi batasan base-version, konkurensi cache, biaya algoritma, dan batas kapan harus kembali ke full-200.
• Apakah Anda akan memverifikasi dukungan pada klien, perantara (intermediary), dan cache sebelum deployment.

Pertanyaan klarifikasi

1. Bisakah klien menerapkan algoritma instance-manipulation yang dinegosiasikan?
2. Apakah dokumen diidentifikasi secara kuat oleh ETag yang stabil, dan apakah pembuatan delta sebanding dengan biaya CPU-nya?
3. Akankah proksi menulis ulang atau menyimpan cache respons tersebut, dan bisakah proksi mempertahankan semantik delta?
4. Bisakah klien secara transparan mengambil representasi lengkap ketika basisnya sudah basi (stale) atau tidak valid?

Jawaban 30 detik

Saya akan menjadikan 226 sebagai optimasi negosiasi opsional. Klien mengirimkan A-IM dan If-None-Match dari representasi dasar. Server mengembalikan 226 hanya jika server mendukung algoritma tersebut dan memiliki basis yang tepat, mendeklarasikan algoritma di IM, ETag baru, dan Delta-Base jika berguna. Klien memverifikasi tag basis, menerapkan delta, dan memvalidasi entity tag yang dihasilkan. Ketidakcocokan, rasio biaya-manfaat yang buruk, klien yang tidak didukung, atau penggabungan (merge) yang gagal akan dialihkan ke 200 penuh. Cache hanya boleh menggunakan kembali delta jika basis dan metadata responsnya cocok.

Desain langkah demi langkah

1. Negosiasikan kapabilitas delta

A-IM mencantumkan algoritma instance-manipulation yang diterima oleh klien; server menyebutkan pilihannya di IM. Ini berbeda dari kompresi content-encoding: kompresi mengubah transfer coding, sedangkan delta mengubah bagaimana representasi diproduksi. Tanpa algoritma yang didukung bersama, gunakan 200.

2. Ikat basis ke suatu versi

Klien menggunakan If-None-Match untuk mengidentifikasi entity tag lokalnya. Server harus mengonfirmasi bahwa tag tersebut memetakan ke representasi dasar, bukan menebak dari timestamp atau versi yang diberikan klien. Respons membawa ETag baru; Delta-Base dapat secara eksplisit mengidentifikasi tag dasar. Klien memvalidasi hasil yang digabungkan terhadap tag baru tersebut.

3. Buat fallback yang aman

Jika basis tidak ditemukan, ukuran delta lebih besar daripada dokumen lengkap, algoritma mengalami timeout, penggabungan gagal validasi, atau perantara tidak aman, kembalikan 200. Klien harus membuang basis yang tidak dapat digunakan dan melakukan sinkronisasi ulang, sehingga delta yang rusak tidak merusak pembaruan berikutnya. Terapkan batasan ukuran, CPU, dan waktu.

4. Perlakukan cache key dan metrik sebagai bagian dari protokol

Cache key harus menyertakan URL, header negosiasi, dan kondisi yang memilih basis; delta yang valid untuk satu ETag bukanlah respons generik. Ukur hit rate 226, byte delta versus byte penuh, kegagalan merge, rasio fallback, dan latensi pembuatan untuk membuktikan bahwa optimasi ini sepadan dengan kompleksitasnya.

Contoh jawaban berkualitas tinggi

Saya akan menerapkannya sebagai optimasi dengan fallback eksplisit. Klien mengiklankan algoritma A-IM yang didukung dan mengirimkan If-None-Match untuk basisnya. Server memeriksa apakah basis tersebut ada dan apakah algoritma tersebut ada di daftar yang diizinkan (allowlisted), lalu membandingkan ukuran delta dan biaya pembuatan. Hanya setelah itu server mengembalikan 226, mendeklarasikan algoritma dengan IM, menerbitkan ETag baru untuk hasilnya, dan secara opsional mengidentifikasi basis dengan Delta-Base. Klien memverifikasi tag basis, menerapkan delta, dan memvalidasi entity tag baru sebelum mengganti dokumennya. Setiap ketidakcocokan versi, delta yang terlalu besar, kegagalan merge, atau jalur yang tidak didukung akan mengembalikan 200. Cache bervariasi berdasarkan negosiasi dan kondisi basis, sementara telemetri mencatat byte yang dihemat, CPU, kegagalan, dan fallback. Dukungan delta meningkatkan efisiensi transfer tanpa menjadi prasyarat untuk kebenaran data.

Kesalahan umum

• Memperlakukan 226 sebagai 206, padahal 206 merespons permintaan Range.
• Hanya mengirimkan nomor versi informal alih-alih mengikat basis yang tepat dengan ETag.
• Mengasumsikan setiap browser, proksi, dan cache memahami semantik delta.
• Melewatkan perbandingan antara ukuran delta dan ukuran dokumen penuh.
• Melanjutkan dari basis yang tidak valid setelah kegagalan merge alih-alih melakukan sinkronisasi ulang.
• Memperlakukan kompresi, JSON Patch, dan instance manipulation RFC 3229 sebagai lapisan protokol yang sama.

Pertanyaan lanjutan dan tanggapan

Apa perbedaan 226 dari 206 dan 304?

206 mengembalikan rentang byte yang diminta dengan Range; 304 menyatakan bahwa permintaan bersyarat tidak memerlukan representasi baru; 226 mengembalikan delta berdasarkan representasi yang sudah ada. Kondisi permintaan, pemrosesan klien, dan semantik cache ketiganya berbeda.

Bagaimana jika ETag basis sudah usang (stale)?

Jangan terapkan delta secara membabi buta. Kembalikan 200 penuh atau minta klien mengambil basis saat ini, membuang basis lokal yang tidak dapat digunakan, dan membangun kembali cachenya dari representasi yang lengkap.

Bagaimana cara mencegah peracunan cache delta (delta-cache poisoning)?

Ikat URL, algoritma yang dinegosiasikan, ETag basis, dan ETag respons; validasi IM dan Delta-Base; cegah perantara menggunakan kembali delta untuk basis lain; dan verifikasi integritas entitas yang digabungkan.