Perintah dan cakupan
Pertanyaan backend ini menguji kontrak API dan batasan kegagalan. Tujuannya bukan untuk membungkus setiap exception ke dalam satu objek JSON, melainkan memungkinkan klien mengambil tindakan yang stabil sementara log, tracing, izin akses, dan teks untuk pengguna tetap berada pada lapisan yang terpisah.
Apa yang sedang dievaluasi oleh pewawancara
- Apakah Anda memahami hubungan antara
application/problem+jsondan kode status HTTP. - Apakah validasi, autentikasi, otorisasi, konflik, rate limit, kegagalan sementara, dan error yang tidak dikenal dibedakan dengan jelas.
- Apakah Anda merancang error tingkat field, instance yang dapat dilacak, dan anggota ekstensi yang terkontrol.
- Apakah Anda menghindari mengekspos stack, ID internal, data pribadi, dan raw exception yang tidak tepercaya.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Pastikan apakah klien memerlukan keputusan mesin atau hanya teks tampilan, apakah lokalisasi, validasi batch, dan tugas asinkron tersedia, apakah tipe dibagikan di seluruh layanan, status mana yang dapat dicoba ulang (retryable), serta apa yang dicatat dalam log, ditampilkan, dan digunakan untuk korelasi permintaan oleh gateway, layanan, dan klien.
Struktur jawaban 30 detik
Gunakan application/problem+json bersama type, title, status, detail, dan instance sebagai dasar yang stabil. Tambahkan ekstensi terkontrol untuk kode, path field, waktu percobaan ulang, dan versi dokumentasi. Status HTTP membawa semantik umum dan type membawa kategori yang dapat diprogram; penyebab internal tetap berada di log sementara respons berisi informasi yang aman dan dapat ditindaklanjuti.
Jawaban mendalam
1. Menetapkan batasan status dan tipe
Gunakan 400 untuk kegagalan sintaks atau permintaan umum, 401 untuk autentikasi yang hilang, 403 untuk permintaan yang dikenali tetapi tidak diizinkan, 404 untuk sumber daya yang tidak ditemukan, 409 untuk konflik status saat ini, 429 untuk rate limiting, dan 5xx untuk kegagalan server atau dependensi. Buat type sebagai URI yang stabil dan terdokumentasi; klien sebaiknya tidak mem-parsing teks title atau detail yang mudah berubah.
2. Merancang field Problem Details
type mengklasifikasikan masalah, title adalah ringkasan manusia yang stabil, status mencerminkan respons, detail menjelaskan permintaan ini, dan instance mengidentifikasi kejadian ini. Ekstensi dapat mencakup kode, path field, nama parameter, waktu percobaan ulang, atau versi dokumentasi, dengan kosakata dan panjang yang dibatasi. Validasi batch dapat mengembalikan array di mana setiap item menunjuk ke lokasi input.
3. Menangani validasi, konflik, dan percobaan ulang
Kegagalan validasi harus memberi tahu klien cara memperbaiki suatu field dan tidak boleh meminta percobaan ulang. Konflik memerlukan pembacaan ulang atau tindakan bisnis yang berbeda. 429 atau kegagalan dependensi sementara dapat menyertakan Retry-After, namun klien tetap memerlukan backoff dan batas percobaan. Buat kemampuan percobaan ulang secara eksplisit alih-alih meminta klien menyimpulkannya dari tumpukan respons 200.
4. Melindungi batasan keamanan dan privasi
Jangan pernah menyertakan stack, SQL, kunci, hostname internal, detail lintas-penyewa (cross-tenant), atau catatan pribadi lengkap. Detail hanya boleh menyatakan fakta yang dapat ditindaklanjuti; instance harus berupa referensi yang tidak dapat diprediksi atau terkontrol. Korelasikan raw exception di log internal dengan ID permintaan. Hindari kebocoran enumerasi akun dalam error autentikasi dan filter error field berdasarkan izin akses.
5. Berkembang di seluruh layanan dan versi
Tempatkan tipe, status, dan ekstensi bersama dalam dokumentasi berversi dan uji kontrak; gateway tidak boleh menulis ulang semantik layanan. Tambahkan field secara kompatibel dan berikan periode migrasi untuk tipe yang dihentikan. Klien harus melakukan fallback ke status dan detail yang aman untuk tipe yang tidak dikenal. Pantau distribusi tipe, keberhasilan percobaan ulang, titik masalah error field, dan ketertelusuran ID permintaan.
Contoh jawaban yang kuat
Saya akan mendeklarasikan setiap error sebagai application/problem+json dengan type URI, title, status, detail, dan instance yang stabil. Bedakan 400/401/403/404/409/429 dan 5xx berdasarkan semantik HTTP; tambahkan path field dan kode yang aman untuk validasi, serta Retry-After untuk rate limiting atau kegagalan dependensi sementara. Klien menggunakan type untuk memutuskan apakah akan memperbaiki, mengambil ulang, melakukan backoff, atau menghubungi dukungan daripada mem-parsing detail yang mudah berubah. Log internal menyimpan stack, status dependensi, dan ID permintaan, sementara respons mengecualikan SQL, kunci, data penyewa, dan catatan pribadi. Tipe berversi dan uji kontrak melindungi evolusi lintas-layanan; tipe yang tidak dikenal melakukan fallback ke status. Pantau tipe error, hasil percobaan ulang, dan titik masalah field setelah peluncuran.
Kesalahan umum
- Mengembalikan 200 dan sebuah kalimat untuk setiap error, membuat klien tidak dapat mengambil keputusan secara terprogram.
- Membuat klien bergantung pada kata-kata harfiah title atau detail, sehingga penerjemahan merusak perilaku sistem.
- Melabeli validasi, konflik, rate limit, dan kegagalan sementara sebagai 500.
- Mengembalikan stack, SQL, hostname internal, atau data pengguna lengkap di dalam detail.
- Mengekspos nama kelas exception internal sebagai tipe publik dan membekukan detail implementasi ke dalam kontrak.
- Tidak memiliki fallback untuk tipe yang tidak dikenal atau pengujian kontrak lintas-layanan.
Pertanyaan lanjutan
Haruskah type berupa URL yang dapat dijangkau?
Itu harus berupa URI yang stabil dan dapat mengarah ke dokumentasi penjelasan, tetapi klien tidak boleh memerlukan permintaan jaringan untuk menanganinya. Properti yang penting adalah identitas semantik, penerapan versi, dan panduan migrasi.
Haruskah detail dilokalisasi?
Biarkan field mesin dan type tetap stabil dan render teks pengguna di sisi klien sesuai dengan bahasa dan konteksnya. Jika server harus mengembalikan detail, gunakan templat yang aman dan negosiasi bahasa; jangan pernah mengekspos exception internal yang tidak diterjemahkan.
Haruskah gateway menulis ulang setiap error?
Gateway dapat menambahkan ID permintaan, error batas waktu (timeout), dan kegagalan tingkat protokol, tetapi harus mempertahankan tipe bisnis. Penulisan ulang memerlukan aturan berversi dan observabilitas, jika tidak, klien akan melihat semantik yang tidak lagi cocok dengan penyebab sebenarnya.
Bagaimana Anda menangani keberhasilan parsial dalam permintaan batch?
Tentukan hasil batch dengan status per item, lokasi input, dan kemampuan percobaan ulang, serta nyatakan apa arti status HTTP secara keseluruhan. Detail yang tidak jelas tidak dapat mengekspresikan keberhasilan parsial, dan klien tidak boleh mengirim ulang item yang sudah berhasil.