کد وضعیت 200 OK نشان می‌دهد که سرور درخواست ارسال‌شده را به‌درستی دریافتتوسط سرور دریافت، درک و پردازش کردهشده و پاسخ مورداستاندارد انتظارحاوی داده‌های درخواست‌شده را بدون هیچ‌گونه خطا بازگردانده است.
به
طبق عبارتRFC 9110 دیگر،(HTTP زمانیSemantics, 2022)، این کد برای موفقیت عمومی تمام متدهای HTTP استفاده می‌شود؛ در پاسخ به GET معمولاً به معنی دریافت محتوای صحیح است، در PUT و DELETE به معنی انجام کامل عملیات است.
در صورت دریافت 200، کلاینت می‌تواند فرض کند که مرورگرهیچ خطایی در فرآیند ارتباط وجود نداشته و پاسخ معتبر است.
وضعیت 201 — Created
کد 201 Created نشان می‌دهد که درخواست با کدموفقیت 200انجام مواجهشده می‌شود، یعنی صفحهٔ وب یاو منبع درخواست‌شدهجدیدی به‌درستی بارگذاریایجاد شده است.
شما
بر بااساس مواجهRFC 9110، شدناین باپاسخ وضعیتاغلب 200برای بدونمتدهای هیچ مشکلی میتوانید دیتاهای مورد نظر خود را استخراج نمائیدPOST و بهگاهی فرایند خود ادامه دهید.
وضعیت 201
کد 201 به معنای موفقیت در ایجاد یک منبع جدید در وب توسط وب‌سرورPUT استفاده می‌شود. این کد وضعیت نشان‌دهنده این است که وب‌سرور بامی‌تواند موفقیتهدر درخواست POST (ایجاد منبع) یا PUT (به‌روزرسانی منبع)Location را پردازششامل کرده و یکURI منبع جدیدتازه ایجادایجادشده کردهبرگرداند است.تا اینکلاینت منبع معمولاً با یک URI (شناسه منابع یکتا) جدید معرفی می‌شود کهبتواند به عنوان پاسخ به کلاینت ارسال می‌شود. این URI معمولاً به کلاینت امکان می‌دهد که به سرعت به منبع جدیدآن دسترسی پیدا کند.
بطورنمونه: مثالهنگام درثبت زمانسفارش یا خرید بلیتبلیت، در صورتی که خرید شما بدون هیچ مشکلی صورت بگیرد وضعیت 201یه معنایاگر ایجاد این آیتم در وبپایگاه داده موفقیت‌آمیز باشد، سرور مرکزیوضعیت دریافت201 خواهد شد.بازمی‌گرداند.
وضعیت 204
— No Content
کد 204 اعلامNo می‌کندContentکهبه سرورمعنی موفقیت‌آمیز بودن درخواست کاربربدون رانیاز به خوبی برآورده کرده است اماارسال محتوای جدیدیجدید در پاسخ است.
این کد معمولاً در پاسخ به درخواستمتدهای PUT, PATCH, DELETE یا POST استفاده می‌شود، زمانی‌که عمل مورد‌نظر در دسترسسرور نیست.انجام شده ولی داده‌ای برای بازگرداندن وجود ندارد.
بطور مثال شما زمانی که ازمثال: API بازکردن قفلحذف رزرو استفاده میکنید در صورت موفق بودن پاسخحذف، برایبدون شمابدنهٔ باپاسخ، وضعیت 204 ارسال خواهد شد.می‌کند.
وضعیت 207
— Multi‑Status
کد 207 Multi‑StatusCodeبخشی از استاندارد WebDAV (RFC 4918) است.
این کد زمانی استفاده می‌شود که یک درخواست شامل چندین عملیات یا منبع باشد و پاسخ برای هر مورد جداگانه در قالب XML یا JSON شامل وضعیت مجزا ارائه گردد.
به‌طور مثال در یک درخواست جمعی برای بروزرسانی چند فایل، اگر بعضی پردازش شوند و بعضی خطا بدهند، پاسخ 207 Multi-Statusحاوی یکینتیجهٔ ازجزئی کدهایهر فایل ارسال می‌شود.
وضعیت پروتکل400 HTTP— Bad Request
کد 400 Bad Request نشان‌دهندهٔ آن است که سرور نمی‌تواند یا نمی‌خواهد درخواست را پردازش کند زیرا در نحو (syntax) یا ساختار داده‌های درخواست خطا وجود دارد.
این خطا ناشی از اشتباه سمت کلاینت است و معمولاً با پیام‌هایی نظیر 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 دقیقی انجام می‌دهند (مثلاً در فرم‌های مربوطثبت به WebDAVاطلاعات) استفاده می‌شود.
این
وضعیت 500 — Internal Server Error
کد نشان500 می‌دهدInternal کهServer Error بیانگر خطای عمومی در سمت سرور پاسخ‌هایاست، متعددیبدون رااشاره به علت دقیق.
معمولاً در اثر بروز استثنا (Exception)، نقص در پیکربندی، یا قطع ارتباط سرویس وابسته رخ می‌دهد.
این خطا قابل تشخیص برای یککلاینت نیست و صرفاً به معنی شکست درخواست واحددر بازگرداندهسطح سرور است.
درتوصیهٔ صورتیاستاندارد: کهبررسی شماlog مواردیسرور، را (بیشتر از یک آیتم)و در درخواستصورت خودنیاز جهتارائه انجامسرویس عملیات ارسال فرمائید. پاسخ شما در صورتی که با خطا اولیه مواجه نشود اما به هر دلیلی مانند تکراری بودن وپشتیبان یا هرfallback موردendpoint دیگریبرای ارسالحفظ شدهپایداری باشد وضعیت کد 207 دریافت می شود و این به این معناست که قسمتی از درخواست انجام شده و قسمتی دیگر بنا به دلایل مشخص رد شده است.ارتباط.
کدوضعیت روشی برای اطلاع‌رسانی شما در مورد وضعیت درخواست است. این کد وضعیت معمولاً به دو صورت ارسال می‌شود. وضعیت 200 که نشان‌دهنده درست بودن همه مراحل درخواست و پاسخ سرور است و کد وضعیت 500 یا Error 500 که نشان‌دهنده بروز مشکل در پاسخ به درخواست است و یا کدهای دیگر که در زیر به جزئیات آن پرداخته ایم.
وضعیت 500
ارور 500 یک کد خطای HTTP status code است به این معنی که مشکلی در سرور وب‌سایت رخ داده، اما سرور نمی‌تواند بگوید مشکل دقیقاً چیست. کد وضعیت 500 (ارور داخلی سرور) نشان می‌دهد که سرور با شرایط غیرمنتظره‌ای مواجه شده که مانع از انجام درخواست شما می‌شود. هنگامی که از یک وب‌سایت بازدید میکنید، مرورگر شما درخواستی را به سروری که سایت در آن میزبانی می‌شود ارسال می‌کند. سرور این درخواست را دریافت کرده، آن را پردازش کرده و منابع درخواستی را به همراه یک هدر HTTP باز می‌فرستد. این هدر کد وضعیت HTTP (response code in the Hypertext Transfer Protocol) را نیز شامل می‌شود.
جهت حفظ ارتباط پایدار در صورتی که با این خطا مواجه شده اید، لطفا از طریق Base URL پشتیبان درخواست خود را ارسال نمائید. قابل ذکر است استفاده از سرور پشتیبان در شرایط معمولی توصیه نمیگردد. سرور پشتیبان روشی جامع و کامل جهت ایجاد ارتباطی پایدار می باشد.
این خطا در صورتی که سرور اصلی پاسخگو نباشد ایجاد میگردد.
وضعیت 400
ارور 400 که به Bad Request 400 نیز معروف است به عنوان خطای کاربر یا کلاینت توسط سرور مرکزی شناخته می‌شود. زمانی که کاربران یک درخواست اشتباه را به سرور ارسال می‌کنند و سرور نمی‌تواند جوابی برای آن درخواست پیدا کند این خطا را به کاربر نشان می‌دهد. در واقع ارور 400 به کاربران نشان می‌دهد که درخواست آنها با موفقیت به سرور ارسال نشده است یا درخواست آنها نادرست بوده است. سرور نمی‌تواند درخواست کاربر را به دلیل وجود خطای کلاینت پردازش کند. به همین دلیل این موضوع را با ارسال پیام‌های مانند invalid request message framing یا deceptive request routing به کاربر نشان می‌دهد. دلایل مختلفی وجود دارد که باعث ایجاد خطا در ارسال درخواست کاربران به سرورها می‌شود.
وضعیت 404
ارور 404 خطای عدم یافتن مسیر و یا صفحه مورد نظر می باشد. در سرویس API ما در صورتی که شما آدرس URL مورد نظر را بصورت صحیح وارد ننمائید با این خطا مواجه میشوید.
در صورت بروز این خطا لطفا یکبار دیگر آدرس URL ارسالی خود را بررسی فرمائید.
در بعضی از شرایط امکان این وجود دارد که در مهلت تعیین شده جهت جابجایی آدرس Base شما اقدام نکرده باشید و سرور مورد نظر دیگر در آن ورژن پاسخگو درخواست های شما نباشد.
وضعیت 405
ارور 405 نشان دهنده این موضوع است که سرور مرکزی متد ارسالی مورد استفاده را نپذیرفته است و یکی از ارورهای سمت کلاینت به شمار می رود. به عبارتی این ارور نشان می دهد که درخواست به دسترسی ارسال شده است و وب سرور نیز این درخواست را تشخیص داده است اما متد به کار رفته را قبول نکرده است که در نتیجه کاربر قادر به مشاهده صفحه مورد نظر نخواهد بود و با ارور Method Not Allowed مواجه خواهد شد.
وضعیت 409
Status Code 409 Conflict یکی از کدهای وضعیت HTTP است که به معنای وجود تعارض یا مشکل در درخواست ارسالی توسط کلاینت است. این کد نشان‌دهنده‌ی این است که درخواست کلاینت نمی‌تواند به‌درستی اجرا شود زیرا با وضعیت جاری سرور یا منابع موجود تعارض دارد.
به طور مثال در صورتی که شما آیتمی تکراری جهت ثبت ارسال نمائید با وضعیت کد 409 مواجه می شود و این به معنی تکراری بودن آیتم می باشد.
وضعیت 422
Status Code 422 Unprocessable Entity یکی از کدهای وضعیت HTTP است که به معنای “موجودیتی که قابل پردازش نیست” است. این کد معمولاً زمانی استفاده می‌شود که درخواست ارسال‌شده از نظر ساختاری صحیح است (یعنی درخواست به درستی فرمت شده و اطلاعات ضروری را شامل می‌شود)، اما سرور قادر به پردازش آن نیست به دلیل اینکه داده‌های درخواست با مشکلات منطقی یا اعتبارسنجی مواجه هستند.
