‼️استانداردسازی خطاهای REST API با Problem Details (RFC 7807)
‼️استانداردسازی خطاهای REST API با Problem Details (RFC 7807)
وقتی بحث طراحی REST API میاد وسط، خیلیا فقط به CRUD فکر میکنن و اینکه یه سری endpoint که دیتا میگیرن و کوئری پاسخ میدن. اینکه API کار کنه و خطا نده کافی نیست، اگر استاندارد نباشه مشکلاتی متعاقب خودش به بار میاره که مفصله. استانداردهای طراحی API کمک میکنن که APIها قابل پیشبینی، خوانا و سازگار باشن. برای همین هم REST APIهای اصولی، معمولاً از الگوهای استاندارد استفاده میکنن.
یکی از مشکلات رایج طراحی API، مدیریت و ارسال خطاهاست. خیلی از APIها به شکلهای مختلف خطا برمیگردونن؛ یکی JSON میده، یکی XML، یکی فقط یه متن ساده، و بعضیها هم فقط یه HTTP Status Code. اینجاست که RFC 7807 وارد میشه!
تعریف RFC 7807: استاندارد کردن جزئیات خطاها توی REST API
در حقیقت RFC 7807 استانداردیه که توش تعریف شده چطور APIها میتونن جزئیات خطاها (Problem Details) رو به صورت JSON یا XML برگردونن، بهجای این که هر کی واسه خودش یه فرمتی اختراع کنه. فرمت پیشنهادی این شکلیه:
{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"status": 403,
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/transactions/67890"
}
✅ اجزای کلیدی:
الف: type: یه URL که نشون میده این نوع خطا چیه (میشه مستندات مربوطه رو اینجا گذاشت)
ب: title: یه توضیح کوتاه و ثابت دربارهی نوع خطا
پ: status: همون HTTP Status Code که برمیگرده
ت: detail: توضیح دقیقتر در مورد این خطای خاص
ث: instance: آدرسی که خطا در اون رخ داده
✅ مزایای استفاده از Problem Details
*️⃣استاندارد بودن: همه جا یه فرمت ثابت داریم -> نرمافزار مونیتورینگ لاگ براش فرقی نمیکنه API از کجا و چه زبونی اومده، جزئیات خطا رو درست تشخیص میده
*️⃣توسعهپذیری: میتونیم فیلدهای سفارشی اضافه کنیم
*️⃣مستندسازی بهتر: فرمت مشخص باعث میشه مستندات بهتری داشته باشیم
*️⃣پشتیبانی فریمورکها: اکثر فریمورکهای مدرن ازش پشتیبانی میکنن
*️⃣قابلیت اتوماسیون: ابزارها میتونن به راحتی خطاها رو پردازش کنن
🔗 متن استاندارد
💬 نظر شما چیه؟ از Problem Details استفاده میکنید؟ اگر کد مثال میتونه کمک کنه: ⚙️
#API_Design