@5 سالپتار کوواچویچ
مهندس نرم افزار
معرفی TL ؛ DR: این پست مجموعه ای از مواردی است که من برای پاک کردن (برای خودم یا دیگران) در مورد کدهای وضعیت HTTP در هنگام ساخت یک API RESTful لازم داشتم. ممکن است برای سبک معماری که خیلی به مشخصات HTTP متکی نباشد منطقی نباشد.
احتمالاً به راحتی می توان گفت که اکثر برنامه های تحت وب (مبتنی بر HTTP) API های سرور خود را طراحی می کنند تا حدی از دستورالعمل های REST پیروی کنند. آنهایی که API خود را فقط به صورت تماس عملکردی از طریق HTTP (RPC) ایجاد نمی کنند ، یا از یک سبک معماری استفاده می کنند که یک لایه انتزاعی اضافی را ارائه می دهد که ویژگی های اضافی و پیچیده تری را از آنچه پروتکل استاندارد HTTP ارائه می دهد (به عنوان مثال GraphQL ، صابون)
همه آنقدرها به قابلیتهای HTTP اعتماد ندارند. بیشتر فقط استفاده می شود
GETو
POST، یا فقط
POSTدرخواست ها ، و پاسخ های آنها را با موارد اصلی نشان می دهد
x00کدهای پاسخ حتی برخی خطاهای کلاینت را به عنوان یک درخواست موفق HTTP نشان می دهند زیرا مدیریت خطا در لایه دیگری از برنامه انجام می شود. به شخصه ، من از دیدن چیزی که در برگه شبکه بیشتر از یک درخواست که دارای عنوان باشد ، متنفر نیستم
200اما در محموله خود خطایی دارد اما برای برخی از معماری ها یک روش معتبر است.
با در نظر گرفتن همه این موارد ، این پست به پاسخ HTTP متمرکز خواهد شد …