Forwarded from TheAliBigdeli Channel
مدیریت خطا و پیامها
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
{
"error": {
"status": 404,
"code": "OBJECT_NOT_FOUND",
"message": "آبجکت مورد نظر یافت نشد",
"detail": "Object matching query does not exist.",
"timestamp": "2025-10-03T12:30:45Z"
}
}
رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
✍4