Klien menghantar permintaan yang salah, API memulangkan 500 dengan stack trace panjang. Pengguna tidak tahu apa perlu dibetulkan, sementara butiran dalaman terdedah. Di sisi lain, respons Something went wrong untuk semua keadaan juga membuat pembangun sukar menyiasat. Ralat yang baik perlu jelas pada perkara yang boleh dilakukan dan berhati-hati pada perkara yang patut dirahsiakan.
Gunakan status HTTP yang sesuai: input tidak sah berbeza daripada sumber tiada atau sistem sementara gagal. Sediakan format respons yang konsisten, medan yang bermasalah jika boleh, dan ID rujukan untuk mencari log. Problem Details dalam ASP.NET Core menyediakan bentuk standard yang boleh dijadikan asas.
Uji jalan gagal seperti jalan berjaya
Hantar input kosong, ID yang tidak wujud dan request tanpa kebenaran. Semak mesej pada telefon atau UI sebenar, bukan hanya Postman. Jangan pulangkan mesej pangkalan data mentah atau token. Log dalaman boleh menyimpan konteks teknikal yang diperlukan, tetapi perlu menjaga data peribadi juga.
Bagi ralat validasi, uji dari UI sebenar: adakah pengguna tahu medan mana perlu dibetulkan tanpa kehilangan data yang telah diisi? Respons API yang cantik di Postman boleh menjadi pengalaman buruk jika frontend hanya memaparkan “gagal”. Kedua-dua lapisan perlu bersetuju pada bentuk ralat yang bermakna.
Apabila ralat jelas, pasukan sokongan dapat memberi jawapan lebih cepat dan pengguna tidak perlu meneka. Ia bahagian daripada reka bentuk produk, bukan kerja tambahan selepas API “siap”.