Skip to main content
#P1202

Status Code – کدهای وضعیتی درخواست ها

 وضعیت 200 — OK

کد وضعیت 200 OK نشان می‌دهد که درخواست به‌درستی توسط سرور دریافت، درک و پردازش شده و پاسخ استاندارد حاوی داده‌های درخواست‌شده را بازگردانده است.

طبق RFC 9110 (HTTP Semantics, 2022)، این کد برای موفقیت عمومی تمام متدهای HTTP استفاده می‌شود؛ در پاسخ به GET معمولاً به معنی دریافت محتوای صحیح است، در PUT و DELETE به معنی انجام کامل عملیات است.

در صورت دریافت 200، کلاینت می‌تواند فرض کند که هیچ خطایی در فرآیند ارتباط وجود نداشته و پاسخ معتبر است.


 وضعیت 201 — Created

کد 201 Created نشان می‌دهد که درخواست با موفقیت انجام شده و منبع جدیدی ایجاد شده است.

بر اساس RFC 9110، این پاسخ اغلب برای متدهای POST و گاهی PUT استفاده می‌شود. سرور می‌تواند هدر Location را شامل URI منبع تازه ایجادشده برگرداند تا کلاینت بتواند به آن دسترسی پیدا کند.

نمونه: هنگام ثبت سفارش یا خرید بلیت، اگر ایجاد آیتم در پایگاه داده موفقیت‌آمیز باشد، سرور وضعیت 201 بازمی‌گرداند.


 وضعیت 204 — No Content

کد 204 No Content به معنی موفقیت‌آمیز بودن درخواست بدون نیاز به ارسال محتوای جدید در پاسخ است.

این کد معمولاً در پاسخ به متدهای PUT, PATCH, DELETE یا POST استفاده می‌شود، زمانی‌که عمل مورد‌نظر در سرور انجام شده ولی داده‌ای برای بازگرداندن وجود ندارد.

مثال: API حذف رزرو در صورت موفق بودن حذف، بدون بدنهٔ پاسخ، وضعیت 204 ارسال می‌کند.


 وضعیت 207 — Multi‑Status

کد 207 Multi‑Status بخشی از استاندارد WebDAV (RFC 4918) است.

این کد زمانی استفاده می‌شود که یک درخواست شامل چندین عملیات یا منبع باشد و پاسخ برای هر مورد جداگانه در قالب XML یا JSON شامل وضعیت مجزا ارائه گردد.

به‌طور مثال در یک درخواست جمعی برای بروزرسانی چند فایل، اگر بعضی پردازش شوند و بعضی خطا بدهند، پاسخ 207 حاوی نتیجهٔ جزئی هر فایل ارسال می‌شود.


 وضعیت 400 — Bad Request

کد 400 Bad Request نشان‌دهندهٔ آن است که سرور نمی‌تواند یا نمی‌خواهد درخواست را پردازش کند زیرا در نحو (syntax) یا ساختار داده‌های درخواست خطا وجود دارد.

علل رایج: بدنه غیرقابل parse شدن، مقادیر ناقص، هدرهای نادرست یا شناسهٔ توکن نامعتبر.

این خطا ناشی از اشتباه سمت کلاینت است و معمولاً با پیام‌هایی نظیر invalid JSON یا missing parameter همراه می‌شود.


 وضعیت 404 — Not Found

کد 404 Not Found زمانی برگردانده می‌شود که منبع یا مسیر مورد نظر در سرور وجود ندارد یا حذف شده است.

از دید API یعنی Endpoint یا URI درخواستی شناسایی نمی‌شود.

دلایل معمول: آدرس غلط، تغییر نسخهٔ سرویس، پایان پشتیبانی از مسیر قبلی (deprecated endpoint).

راه‌حل: بررسی مجدد URL و در صورت نیاز به‌روزرسانی URI مورد استفاده.


 وضعیت 405 — Method Not Allowed

کد 405 Method Not Allowed یعنی URI مورد درخواست معتبر است، اما متد (مثلاً POST یا DELETE) توسط سرور برای آن مسیر مجاز نیست.

در پاسخ معمولاً هدر Allow شامل لیستی از متدهای مجاز مثل GET, PUT برگردانده می‌شود.

این خطا از نوع کلاینت است و نشانهٔ استفاده از متد غیرفعال برای endpoint خاص می‌باشد.


 وضعیت 409 — Conflict

کد 409 Conflict به معنی وجود تعارض در وضعیت فعلی منبع است که مانع انجام عملیات می‌شود.

این خطا زمانی بازگردانده می‌شود که درخواست در تضاد با داده‌های موجود باشد، مثلاً تلاش برای ایجاد رکورد تکراری یا بروزرسانی نسخهٔ قدیمی شیء.

در سيستم‌های دارای نسخه‌بندی و کنترل همزمان (مثل وب‌سایت رزرو یا فرم ثبت آیتم تکراری) کاربرد دارد.


 وضعیت 422 — Unprocessable Entity

کد 422 Unprocessable Content (نام جدید در RFC 9110، ‌قبلاً Unprocessable Entity در RFC 4918 بود) زمانی ارسال می‌شود که درخواست از نظر نحوی درست است ولی داده‌های آن از نظر منطقی یا اعتبارسنجی نامعتبر است.

مثلاً فیلدهای الزامی خالی‌اند یا مقادیر بعضی پارامترها خارج از محدودهٔ مجاز هستند.

این کد معمولاً در APIهایی که قبل از پردازش داده، validation دقیقی انجام می‌دهند (مثلاً در فرم‌های ثبت اطلاعات) استفاده می‌شود.


 وضعیت 500 — Internal Server Error

کد 500 Internal Server Error بیانگر خطای عمومی در سمت سرور است، بدون اشاره به علت دقیق.

معمولاً در اثر بروز استثنا (Exception)، نقص در پیکربندی، یا قطع ارتباط سرویس وابسته رخ می‌دهد.

این خطا قابل تشخیص برای کلاینت نیست و صرفاً به معنی شکست درخواست در سطح سرور است.

توصیهٔ استاندارد: بررسی log سرور، و در صورت نیاز ارائه سرویس پشتیبان یا fallback endpoint برای حفظ پایداری ارتباط.