Perintah dan cakupan
Klien legacy mengirimkan deklarasi ekstensi HTTP, dan beberapa permintaan mewajibkan server untuk memahami ekstensi tersebut. Gateway mungkin meneruskan permintaan tersebut sementara origin tidak mendukungnya. Jelaskan 510 Not Extended, bandingkan dengan 501 dan 400, serta usulkan langkah-langkah kompatibilitas, observabilitas, migrasi, dan rollback.
RFC 2774 melabeli kerangka kerja ekstensi ini sebagai Historic. Pertanyaan ini menguji semantik protokol; ini tidak menyiratkan bahwa 510 umum diterapkan oleh API publik modern.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda mengetahui bahwa 510 berkaitan dengan persyaratan ekstensi HTTP yang tidak terpenuhi, bukan validasi bisnis biasa.
- Apakah Anda dapat membedakan origin yang tidak dapat memenuhi ekstensi (510) dari metode yang tidak didukung (501).
- Apakah Anda mengenali status historis RFC 2774 alih-alih memperlakukan 510 sebagai format error universal.
- Apakah desain Anda mencakup proxy, cache, kompatibilitas, dan bukti migrasi secara bersamaan.
Pertanyaan klarifikasi
- Apakah permintaan tersebut benar-benar mendeklarasikan ekstensi RFC 2774 wajib, atau hanya header bisnis yang tidak dikenal?
- Hop mana (klien, proxy, gateway, atau origin) yang dapat menginterpretasikan deklarasi ekstensi tersebut?
- Bisakah klien ditingkatkan (upgrade), dan apakah ada format permintaan alternatif yang stabil?
- Mungkinkah middlebox menulis ulang (rewrite), menyimpan dalam cache, atau membungkus respons 510?
- Apakah migrasi harus mendukung operasi baca (read) dan tulis (write)?
Jawaban 30 detik
“510 adalah respons RFC 2774 untuk ekstensi HTTP wajib yang tidak dapat dipenuhi oleh server. 501 berarti server tidak mendukung metode yang diminta, sedangkan 400 berarti permintaan tidak valid dalam sintaksis atau semantik umum. Karena RFC 2774 berstatus Historic, saya pertama-tama akan membuktikan bahwa lalu lintas menggunakan kerangka kerja ini, kemudian mempertahankan 510 sebagai sinyal kompatibilitas legacy: mengembalikan error yang dapat didiagnosis tetapi tidak sensitif, mencatat pengidentifikasi ekstensi dan path, serta memindahkan klien ke kontrak API berversi. Header bisnis yang tidak dikenal atau kegagalan validasi biasa tidak boleh menjadi 510.”
Desain langkah demi langkah
1. Verifikasi deklarasi ekstensi
Skenario RFC 2774 lebih spesifik daripada sekadar melihat header yang asing. Klien mendeklarasikan ekstensi dan pengidentifikasinya, dan dapat mewajibkan penerima untuk memahaminya. Konfirmasikan deklarasi dalam permintaan mentah (raw request), log penerusan proxy, dan log origin sebelum memutuskan bahwa 510 berlaku.
2. Pisahkan kode status yang berdekatan
510 berarti ekstensi yang diminta tidak dapat dipenuhi; 501 berarti server tidak mengimplementasikan metode yang diperlukan untuk memproses permintaan; 400 berarti permintaan tidak dapat diurai atau diproses di bawah semantik umum. Autentikasi, otorisasi, throttling, dan aturan bisnis layak mendapatkan kode status dan kode error stabil mereka sendiri.
3. Rancang respons yang dapat didiagnosis
Kembalikan jenis error yang stabil, ID permintaan, ringkasan aman dari pengidentifikasi ekstensi, dan dokumentasi migrasi. Jangan menggemakan kembali (echo) URI yang tidak divalidasi, nama komponen internal, atau data permintaan yang sensitif. Jika format error umum adalah application/problem+json, biarkan 510 mengidentifikasi penyebab protokol dan letakkan detail bisnis di anggota ekstensi.
HTTP/1.1 510 Not Extended
Content-Type: application/problem+json
Cache-Control: no-store
{"type":"https://api.example/problems/unsupported-extension","title":"Required extension is unsupported","status":510,"instance":"req-7f2"}4. Tangani proxy dan caching
Uji apakah proxy menghapus deklarasi ekstensi, menulis ulang 510 menjadi 400, atau menggunakan kembali error pada lapisan cache. Gunakan caching konservatif untuk respons yang bergantung pada identitas, kemampuan, atau informasi penyewa (tenant). Catat path, pengidentifikasi ekstensi, versi proxy, dan hasil origin tanpa menyimpan permintaan sensitif lengkap.
5. Rencanakan migrasi legacy
Ukur kegagalan berdasarkan versi klien dan pengidentifikasi ekstensi. Sediakan format permintaan berversi yang tidak bergantung pada ekstensi, dan publikasikan tanggal peralihan dalam dokumentasi dan SDK. Selama periode transisi, terima format lama dan baru dengan negosiasi kemampuan eksplisit dan ketentuan rollback. Hentikan (retire) path lama hanya setelah ambang batas cakupan peningkatan (upgrade coverage) terpenuhi.
6. Tentukan verifikasi dan rollback
Gunakan rantai proxy nyata dan pengujian kontrak untuk empat jalur: ekstensi yang didukung, ekstensi yang hilang, ekstensi yang dihilangkan oleh middlebox, dan header biasa yang tidak dikenal. Pantau rasio 510, 501, dan 400 bersamaan dengan peningkatan klien. Jika 510 melonjak setelah rilis konfigurasi, pulihkan path kompatibilitas terlebih dahulu lalu perbaiki penguraian; mencoba ulang (retry) ke origin saja tidak dapat menambahkan dukungan untuk ekstensi yang tidak ada.
Model jawaban berkualitas tinggi
“Saya akan mulai dengan tangkapan paket (packet captures) dan log proxy untuk membuktikan bahwa deklarasi ekstensi RFC 2774 wajib memang ada. Hanya origin yang tidak dapat memenuhi ekstensi tersebut yang boleh mengeluarkan 510; metode yang tidak didukung adalah 501, dan permintaan yang secara umum tidak valid adalah 400. Karena RFC 2774 berstatus Historic, saya akan membatasi 510 untuk kompatibilitas legacy, mengembalikan jenis error yang stabil, ID permintaan, dan dokumentasi migrasi, menggunakan caching konservatif, serta mencatat versi ekstensi, proxy, dan klien. Saya kemudian akan menawarkan API berversi bebas ekstensi, memverifikasi penerusan dan penulisan ulang dengan pengujian kontrak, menghentikan path lama berdasarkan cakupan peningkatan, dan mempertahankan sakelar rollback.”
Kesalahan umum
- Mengembalikan 510 untuk sembarang header yang tidak dikenal → tidak ada ekstensi wajib yang terbukti → uraikan deklarasi ekstensi dan persyaratannya terlebih dahulu.
- Memperlakukan 510 sebagai 501 → kegagalan ekstensi dan ketiadaan metode adalah hal yang berbeda → terapkan skenario RFC dan semantik metode secara terpisah.
- Menjadikan 510 konvensi API publik jangka panjang → kompatibilitas ekosistem menjadi rapuh → tandai dependensi Historic dan migrasikan berdasarkan versi.
- Mengizinkan shared caching untuk error → hasil kemampuan satu klien memengaruhi klien lain → atur kebijakan cache sesuai dengan identitas dan data negosiasi.
- Hanya mencoba ulang permintaan lama → percobaan ulang tidak dapat menciptakan dukungan ekstensi yang tidak didukung → tingkatkan, turunkan versi (downgrade), atau gunakan format alternatif.
Pertanyaan lanjutan dan tanggapan
Apa perbedaan satu kalimat antara 510 dan 501?
510 berkaitan dengan ekstensi HTTP yang dideklarasikan oleh permintaan yang tidak dapat dipenuhi; 501 berkaitan dengan server yang tidak mendukung metode yang diminta atau implementasi yang diperlukan untuk memprosesnya. Keduanya tidak menggantikan kode error bisnis biasa.
Haruskah header bisnis yang tidak dikenal menghasilkan 510?
Tidak secara langsung. Header yang tidak dikenal dapat diabaikan, ditolak oleh kontrak bisnis, atau ditangani sebagai 400; 510 memiliki dasar semantik hanya ketika permintaan secara eksplisit mewajibkan ekstensi bergaya RFC 2774 yang tidak dapat dipenuhi oleh server.
Mengapa status Historic pada RFC 2774 penting?
Ini menandakan terbatasnya implementasi dan ekosistem klien sehingga risiko interoperabilitas menjadi lebih tinggi. Jawaban wawancara yang kuat memperlakukan 510 sebagai batas protokol legacy dan mengendalikan risiko tersebut dengan observasi, pengujian kontrak, dan migrasi berversi daripada berasumsi bahwa setiap tumpukan (stack) HTTP modern mendukung kerangka kerja tersebut.