Perintah dan cakupan
Sebuah API publik memerlukan response field Features yang berisi nama kapabilitas, prioritas, dan parameter eksperimen. Klien, CDN, gateway, dan SDK dalam beberapa bahasa akan membacanya; klien lama hanya dapat mengabaikan field yang tidak dikenal. Rancang format field, aturan serialisasi dan parsing, kebijakan kompatibilitas, serta rencana verifikasi.
Ini adalah pertanyaan kontrak API backend. Kuncinya adalah mengubah "header mirip string" menjadi protokol yang dapat dioperasikan secara bersama (interoperable). RFC 8941 mendefinisikan model umum Item, List, Dictionary, dan parameter, dan RFC 9651 adalah revisinya. RFC 9110 mewajibkan field baru untuk menentukan tata bahasanya dan menolak karakter kontrol yang berbahaya. Anda tidak perlu mengimplementasikan setiap algoritma RFC, tetapi Anda harus mendefinisikan batas-batasnya.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin melihat apakah Anda mendefinisikan semantik sebelum memilih List, Dictionary, atau Item daripada menggabungkan teks yang dipisahkan koma. Jawaban yang kuat mencakup serialisasi pengirim, parsing penerima, anggota yang tidak dikenal, penggabungan field duplikat, batas ukuran, dan telemetri.
Jawaban yang lemah hanya menunjukkan satu contoh nilai. Jawaban yang kuat menjelaskan mengapa set kapabilitas adalah sebuah Dictionary, mengapa kunci parameter menggunakan huruf kecil, mengapa teks non-ASCII arbitrer tidak boleh disembunyikan dalam String, dan bagaimana kegagalan parsing mencegah pengaktifan fitur secara tidak sengaja. Panduan wawancara API backend saat ini juga menekankan kontrak yang stabil, kompatibilitas mundur, dan mode kegagalan.
Pertanyaan untuk diklarifikasi terlebih dahulu
Semantik field dan batas kepercayaan
Konfirmasikan apakah ini merupakan petunjuk (hint), keputusan otorisasi, atau fakta bisnis. Jika ini memengaruhi izin, penagihan, atau keamanan, server tetap menjadi otoritas tertinggi dan tidak boleh memercayai pantulan (echo) dari klien. Tanyakan apakah field tersebut boleh di-cache dan apakah nilainya bervariasi berdasarkan pengguna.
Tipe dan cakupan kompatibilitas
Tanyakan apakah nilainya berupa set kapabilitas tanpa urutan, daftar prioritas berurutan, atau satu pengenal versi. Konfirmasikan apakah klien lama harus tetap berfungsi, apakah parameter baru mungkin muncul, dan apakah gateway menggabungkan baris field yang duplikat. Jawaban-jawaban tersebut menentukan tipe kontainer dan kebijakan anggota yang tidak dikenal.
Anggaran kegagalan dan sumber daya
Tentukan apakah input yang tidak valid menyebabkan seluruh field, satu anggota, atau seluruh respons diabaikan. Tetapkan batas byte, anggota, penyarangan (nesting), dan waktu parsing; pilihan-pilihan ini menjadi bagian dari batas mitigasi DoS.
Kerangka jawaban 30 detik
"Saya akan mendefinisikannya sebagai kontrak mesin yang dapat diberi versi, bukan JSON yang disembunyikan dalam string. Set kapabilitas menggunakan Dictionary, dengan setiap kunci membawa Item boolean atau berparameter; kunci dan parameter mengikuti aturan serialisasi RFC, dan anggota yang tidak dikenal diabaikan. Server memancarkan ASCII terbatas serta memberlakukan batas ukuran total dan batas anggota. Penerima menggunakan tata bahasa yang sama, memperlakukan sintaksis tidak valid sebagai ketiadaan field, dan tidak pernah menyimpulkan bahwa suatu fitur aktif. Saya akan menguji penggabungan field duplikat dan variasi cache di gateway, melakukan shadow-parsing terlebih dahulu, dan membandingkan kegagalan parsing, ukuran field, serta pengaktifan fitur yang tidak disengaja sebelum peluncuran."
Solusi langkah demi langkah
Langkah 1: Modelkan nilai sebelum memilih kontainer
Gunakan Dictionary untuk sakelar kapabilitas, seperti search;v=2, upload=?1. Gunakan List ketika setiap anggota memiliki urutan atau parameter yang bermakna. Gunakan Item untuk satu versi atau nama kebijakan. Jangan menempatkan JSON di dalam header hanya demi kenyamanan: perantara dan SDK tetap memerlukan parser khusus.
Langkah 2: Definisikan field yang dapat diperluas
Definisikan kunci seperti search dan upload; parameter seperti v=2 dan tier="pro" hanya menggunakan tipe yang diizinkan oleh tata bahasa structured field. Kunci parameter menggunakan huruf kecil. Simpan teks tampilan di luar field, atau gunakan ekstensi Display String yang didukung secara eksplisit setelah memeriksa setiap perantara. Dokumentasikan semantik setiap anggota, nilai default, dan konsekuensi nilai tidak valid.
Features: search;v=2, upload=?1Serialisasi harus deterministik sehingga nilai yang setara tidak menghasilkan perbedaan cache-key atau tanda tangan yang tidak perlu. Penerima tidak boleh mengganti parser yang sadar tata bahasa dengan split(','); koma, tanda kurung, tanda kutip, dan parameter memiliki batas yang telah ditentukan.
Langkah 3: Tentukan penanganan field duplikat dan anggota tidak dikenal
Pertama, nyatakan apakah baris yang berulang diizinkan. Jika field tersebut adalah Dictionary, middleware dapat menggabungkan baris-baris tersebut, sehingga kontrak harus mendefinisikan makna gabungan dan aturan konflik untuk kunci duplikat. Abaikan kunci yang tidak dikenal dan parameter opsional secara default. Untuk kunci yang dikenal dengan tipe tidak valid, hapus anggota tersebut atau seluruh field, tetapi jadikan pilihan tersebut normatif. Sakelar keamanan tidak boleh menjadi aktif hanya karena parsing gagal.
Langkah 4: Bangun batas parsing yang ketat namun dapat digunakan
Batasi total byte, anggota, kedalaman penyarangan, dan waktu CPU sebelum melakukan parsing mendalam. Tolak CR, LF, NUL, dan karakter lain di luar tata bahasa field. Input eksternal tidak memerlukan parsing waktu konstan, tetapi jalur eksepsi tidak boleh mem-parsing nilai yang sangat besar secara berulang. Catat kegagalan yang dikategorikan tanpa mencatat seluruh isi field yang berpotensi sensitif ke dalam log.
Langkah 5: Tangani caching, tanda tangan, dan evolusi
Jika field bervariasi berdasarkan pengguna atau kohort eksperimen, gunakan perilaku respons Vary yang benar atau private caching; jika tidak, CDN dapat mengekspos kapabilitas satu pengguna ke pengguna lain. Jika field dicakup oleh HTTP Message Signatures, penandatangan dan pemverifikasi memerlukan nilai terstruktur kanonikal yang sama. Penambahan kunci dan parameter opsional harus tetap dapat diabaikan oleh klien lama; menghapus atau mengubah semantik memerlukan versi baru atau jendela migrasi.
Langkah 6: Buktikan desain dengan peluncuran dan contoh kontra
Lakukan shadow-parsing terlebih dahulu tanpa mengubah perilaku, lalu aktifkan untuk kohort internal kecil. Uji kunci duplikat, daftar kosong, tanda kutip rusak, parameter tidak dikenal, field yang melebihi ukuran, penggabungan oleh proxy, dan ketidakcocokan cache. Bandingkan keberhasilan parsing, pengaktifan tidak sengaja, byte respons, CPU, cache hit, dan versi SDK dengan dan tanpa field tersebut. Setiap kegagalan parsing harus kembali ke nilai default yang aman.
Contoh jawaban berkualitas tinggi
Saya akan memperlakukan ini sebagai masalah desain protokol. Pertama, saya akan mengonfirmasi apakah field tersebut hanya berupa petunjuk kapabilitas; jika mengontrol otorisasi, server tetap menjadi otoritas utama. Untuk set kapabilitas, saya akan memilih Structured Field Dictionary dan mendefinisikan setiap kunci sebagai Item boolean atau berparameter. Saya tidak akan menggunakan List untuk kapabilitas yang tidak berurutan. Kontrak akan menentukan serialisasi, tipe parameter, baris duplikat, anggota tidak dikenal, dan konsekuensi nilai tidak valid.
Pengirim memancarkan ASCII terbatas dan memberlakukan batas ukuran field serta jumlah anggota. Penerima menggunakan parser yang kompatibel dengan RFC alih-alih memisahkan string berdasarkan koma, menolak karakter kontrol, mengabaikan kunci tidak dikenal, dan memperlakukan kunci dikenal dengan tipe yang salah sebagai tidak ada. Gateway memiliki satu aturan penggabungan duplikat yang pasti, tidak pernah membiarkan aturan "nilai terakhir yang menang" terjadi secara tidak sengaja.
Saya juga akan meninjau perilaku cache dan tanda tangan: kapabilitas spesifik pengguna memerlukan Vary, private caching, atau tanpa caching, dan kedua sisi tanda tangan harus menormalkan nilai secara identik. Saya akan melakukan shadow-parsing, kemudian menerapkan canary release untuk field tersebut sambil memantau kegagalan parsing, pengaktifan tidak sengaja, ukuran, dan CPU. Klien lama akan terus mengabaikan field tersebut; hanya klien yang secara eksplisit mendukung versi tersebut yang mengaktifkan perilaku baru.
Kesalahan umum
- Menempatkan JSON dalam string header → Proxy dan SDK tetap memerlukan parsing kustom, dengan escaping yang tidak konsisten dan semantik duplikat yang ambigu → Gunakan model RFC Item, List, atau Dictionary dan dokumentasikan arti setiap anggota.
- Mem-parsing dengan
split(',')→ Tanda kutip, inner list, dan pembatas parameter terpotong secara tidak benar → Gunakan parser yang sadar tata bahasa dan uji dengan sintaksis tidak valid. - Gagal pada setiap parameter yang tidak dikenal → Pengirim baru tidak dapat beroperasi dengan klien lama → Abaikan parameter ekstensi kecuali jika batasan keamanan yang diketahui dilanggar.
- Mengaktifkan fitur setelah kegagalan parsing → Pemotongan atau manipulasi perantara dapat berubah menjadi eksperimen atau hak akses yang tidak disengaja → Kembalikan ke default yang aman dan catat kegagalan yang dikategorikan.
- Mengabaikan variasi cache → CDN dapat menggunakan kembali kapabilitas yang dipersonalisasi untuk pengguna lain → Tetapkan
Vary, gunakan private caching, atau jangan cache respons tersebut.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa tidak menaruh ini di JSON respons?
JSON mungkin lebih baik ketika kapabilitas hanya berupa data bisnis di dalam body. Structured Fields berguna ketika metadata HTTP, gateway, dan kebijakan cache perlu memeriksa nilai sebelum membaca body. Jangan memberikan otoritas independen pada kedua representasi; jika keduanya ada, tentukan urutan prioritas dan deteksi ketidaksesuaian.
Pertanyaan lanjutan 2: Bagaimana jika beberapa proxy menggabungkan field tersebut?
Tentukan apakah baris berulang valid dan normalkan menjadi satu input parser pada batas yang tepercaya. Untuk Dictionary, tolak kunci duplikat atau tentukan aturan konflik yang eksplisit; jangan bergantung pada nilai mana pun yang kebetulan berada di posisi terakhir. Pengujian integrasi harus mencakup baris berulang HTTP/1.1, representasi field HTTP/2, dan jalur CDN yang sebenarnya.
Pertanyaan lanjutan 3: Bagaimana jika parameter baru memerlukan teks non-ASCII?
Jangan menempatkan UTF-8 secara langsung dalam tipe String yang dibatasi oleh tata bahasa yang dipilih. Definisikan dan verifikasi ekstensi Display String yang didukung, atau simpan teks tampilan di dalam body dan bawa pengenal stabil di dalam field. Aktifkan hanya setelah setiap perantara dan SDK mendukung tipe tersebut.
Pertanyaan lanjutan 4: Parser menyebabkan lonjakan CPU. Apa yang Anda lakukan?
Segera perketat batas byte, anggota, penyarangan, dan jumlah parameter, serta perlakukan field yang melebihi batas sebagai tidak ada. Simpan hash input dan kategori kegagalan untuk diagnosis, bukan nilai lengkapnya. Memindahkan parsing ke worker yang terisolasi dapat mengurangi dampak kerusakan (blast radius), tetapi tidak dapat menggantikan batasan tata bahasa dan rollback canary.