Apa yang dievaluasi oleh pewawancara
API multi-tenant menghasilkan error dari gateway, aplikasi, dan asynchronous job, sehingga klien tidak dapat mengurai kegagalan secara andal. Menggunakan RFC 9457, rancang kontrak error bersama dan jelaskan kode status, tipe media, URI tipe, validasi batch, percobaan ulang, redaksi data, dan kompatibilitas versi.
Konteks dan batasan
- Sebuah permintaan dapat melewati CDN, API gateway, layanan bisnis, dan antrean (queue).
- Klien harus membedakan error input yang dapat diperbaiki, kegagalan otorisasi, pembatasan laju (throttling), dan kesalahan sementara (transient faults).
- Detail tidak boleh mengekspos stack trace, kunci, data isolasi tenant, atau hostname internal.
- Klien yang ada saat ini mengurai field legacy, sehingga migrasi harus tetap kompatibel ke belakang (backward compatible).
Memisahkan semantik HTTP dari detail bisnis
Status HTTP mengekspresikan hasil pada tingkat protokol; body Problem Details menjelaskan penyebabnya. Pilih 400, 401, 403, 404, 409, 429, dan 5xx berdasarkan semantiknya daripada mengembalikan 200 untuk setiap kegagalan. Gunakan URI yang stabil pada type untuk klasifikasi mesin, title untuk presentasi, dan detail yang spesifik untuk permintaan tersebut.
Mendefinisikan kontrak minimal yang dapat diperluas
Anggota inti adalah type, title, status, detail, dan instance. Beri nama ekstensi secara eksplisit, seperti errors untuk masalah field dan retryAfter untuk petunjuk waktu tunggu klien. Dokumentasi untuk setiap tipe harus menyatakan maknanya, kode status yang diizinkan, dan tindakan klien; klien tidak boleh membuat percabangan logika berdasarkan judul bahasa alami.
Berbagi batasan error lintas layer
Error batas waktu (timeout), autentikasi, dan throttling yang dihasilkan oleh gateway menggunakan tipe media yang sama tetapi tidak boleh menyamar sebagai tipe bisnis aplikasi. Layanan menyimpan kode error internal untuk telemetri sambil hanya mengekspos tipe yang disetujui. Propagasikan ID korelasi (correlation ID) lintas layanan tanpa menyalin teks detail yang sensitif.
Pertanyaan klarifikasi sebelum menjawab
- Apakah klien membuat percabangan berdasarkan status,
type, ataucodelegacy? Ini menentukan adaptor migrasi. - Bisakah satu respons memuat beberapa kegagalan validasi field? Ini menentukan bentuk dan jaminan urutan dari
errors. - Apakah gateway dapat memahami error bisnis, atau hanya mentranspor dan membuat error infrastruktur? Ini menentukan kepemilikan tipe.
Kerangka jawaban 30 detik
"Saya akan mempertahankan status HTTP yang benar dan mengembalikan application/problem+json dengan type, title, status, detail yang stabil, serta instance opsional. Klien membuat percabangan berdasarkan status dan type, tidak pernah berdasarkan teks prosa; gateway hanya memiliki tipe error miliknya sendiri. Validasi, petunjuk retry, ID korelasi, dan aturan redaksi menjadi kontrak berversi yang diverifikasi melalui matriks kompatibilitas dan jalur permintaan yang sebenarnya."
Pembahasan mendalam langkah demi langkah
Mulailah dengan registri tipe error. Setiap tipe memiliki URI, anggota publik, status yang diizinkan, tindakan klien, dan tingkat keamanan. Kegagalan validasi menggunakan 400 dengan masalah field di bawah errors; identitas yang hilang dan izin yang tidak memadai tetap 401 dan 403; konflik optimistic-concurrency menggunakan 409; throttling menggunakan 429 dengan petunjuk tunggu yang dapat ditindaklanjuti; kesalahan yang tidak diketahui menggunakan 500 atau 503 dan tipe publik generik.
Jaga agar Content-Type konsisten dengan representasinya. Nilai instance dapat mengidentifikasi satu permintaan untuk kebutuhan dukungan (support), tetapi detail tidak boleh memuat URL lengkap, SQL, stack trace, atau pengidentifikasi tenant. Log menyimpan penyebab internal, ID korelasi, dan field audit keamanan; klien hanya menerima konten yang telah difilter berdasarkan kebijakan.
Untuk validasi batch, tentukan apakah beberapa masalah diperbolehkan, bagaimana path field ditulis, dan jumlah entri maksimum. Klien mengabaikan anggota ekstensi yang tidak dikenal. Anggota baru bersifat aditif; mengubah arti dari type yang ada memerlukan URI baru. Asynchronous job mengekspos kegagalannya melalui resource job alih-alih membocorkan internal antrean secara sinkron.
Model jawaban berkualitas tinggi
"Saya akan mengelola registri tipe dan membuat gateway, layanan sinkron, serta asynchronous job memancarkan application/problem+json yang kompatibel dengan RFC 9457. Status menyampaikan semantik protokol, type menyampaikan kategori yang stabil, dan detail hanya mendeskripsikan permintaan ini. Validasi field menggunakan ekstensi errors yang dibatasi; 429 memiliki petunjuk tunggu yang dapat di-parse; 500 dan 503 menggunakan tipe publik generik sementara stack trace tetap berada di log. Selama migrasi, saya mempertahankan code legacy, lalu mengalihkan klien melalui pengujian kontrak, matriks kompatibilitas, dan audit redaksi."
Kesalahan umum
- Mengembalikan 200 dengan field kegagalan bisnis, menyebabkan cache, monitor, dan sistem retry menganggapnya berhasil.
- Melakukan percabangan pada
titleataudetail, sehingga terjemahan atau perubahan kata-kata merusak klien. - Membiarkan setiap layanan membuat URI
typesendiri, menghalangi agregasi yang konsisten. - Mengembalikan stack trace, SQL, domain internal, atau pengidentifikasi tenant lengkap dalam
detail. - Mengubah timeout gateway menjadi error bisnis, menyebabkan retry yang salah atau panduan pengguna yang keliru.
Gejala kegagalan dan perbaikan
Ketika klien tidak dapat memutuskan apakah harus mencoba lagi (retry), biasanya status, tipe, dan panduan retry saling bertentangan. Bangun registri terlebih dahulu, petakan setiap layer ke kumpulan publik yang kecil, tentukan default yang aman untuk tipe yang tidak dikenal, dan telusuri penyebab internal dengan ID korelasi.
Implementasi produksi
Pusatkan serialisasi dalam library bersama atau edge adapter sambil mempertahankan pemilihan status di batas layanan. Validasi skema membatasi panjang ekstensi, jumlah array, dan format URI; lakukan redaksi sebelum serialisasi daripada hanya mempercayai gateway. Tentukan exponential backoff, jitter, dan kondisi idempoten secara terpisah untuk 429, 503, dan timeout jaringan guna menghindari badai retry (retry storms).
Checklist verifikasi
Pengujian kontrak mencakup status setiap tipe publik, tipe media, anggota wajib, dan ekstensi. Pengujian integrasi melintasi gateway, layanan, dan antrean serta memvalidasi ID korelasi dan redaksi data. Pengujian kompatibilitas menggunakan klien legacy untuk memverifikasi toleransi terhadap anggota yang tidak dikenal dan code yang dipertahankan. Pengujian beban mengukur latensi serialisasi, sampling log, dan amplifikasi retry di bawah kondisi throttling.
Pertanyaan lanjutan dan jawaban
Mengapa tidak mendefinisikan satu kode error bisnis saja?
Satu kode tunggal tidak dapat mengekspresikan semantik caching HTTP, autentikasi, throttling, dan retry. Status memungkinkan infrastruktur generik berperilaku dengan benar; type membawa kategori bisnis yang stabil. Keduanya memiliki tanggung jawab yang berbeda.
Haruskah URI type dapat diakses (reachable)?
Spesifikasi mengizinkan URI relatif atau absolut. Pilih bentuk yang stabil dan dapat didokumentasikan, tetapi jangan jadikan ketersediaan halaman dokumentasi sebagai prasyarat penanganan oleh klien.
Bagaimana Anda mencegah isi pesan error membocorkan data?
Gunakan daftar izin (allowlist) untuk anggota publik, batas panjang, dan pemindaian pola sensitif. Petakan exception internal ke tipe generik dan pertahankan hanya ID korelasi untuk kebutuhan support. Pengujian keamanan mencakup kueri lintas tenant, kegagalan otorisasi, dan alur exception.
Rubrik penilaian
- Akurasi semantik: membedakan arti status HTTP dari anggota Problem Details.
- Desain kontrak: mengusulkan tipe yang stabil, ekstensi, dan penerapan versi.
- Kesadaran batas (boundary): mencakup gateway, job, redaksi, dan badai retry.
- Kemampuan implementasi: mencakup registri, batas serialisasi, matriks kompatibilitas, dan pengujian.
- Pengendalian risiko: menghindari kebocoran data dan tidak memperlakukan tipe yang tidak dikenal sebagai dapat di-retry secara default.
Pemeriksaan kepatuhan
Konfirmasikan bahwa kode status, field tipe, redaksi data, dan batasan retry tetap konsisten.
Checklist jawaban wawancara
Mulailah dengan semantik status, lalu jelaskan bahwa type adalah pengidentifikasi stabil untuk mesin dan detail bukan merupakan kunci kontrak. Tambahkan bukti kepemilikan gateway, validasi, retry, redaksi, dan kompatibilitas.
Kesimpulan satu kalimat
Standardisasi error dengan membuat status mengekspresikan semantik protokol, type mengekspresikan klasifikasi yang stabil, dan ekstensi mengekspresikan detail yang dapat ditindaklanjuti, dengan pengujian keamanan dan kompatibilitas yang melindungi batas sistem.