HTTP مجموعه‌ای از روش‌های درخواست را تعریف می‌کند تا عمل مورد نظر برای یک منبع خاص را مشخص کند. اگرچه این روش‌های درخواست می‌توانند به صورت اسم نیز باشند، اما گاهی اوقات به عنوان افعال HTTP نیز شناخته می‌شوند. هر یک از این روش‌ها دارای معنای متفاوتی هستند، اما برخی ویژگی‌های مشترک بین گروهی از آن‌ها وجود دارد؛ به عنوان مثال، یک روش درخواست می‌تواند ایمن، idempotent (عدم تغییر حالت سرور با تکرار درخواست)، یا قابل ذخیره در کش (cacheable) باشد.

1. GET

روش GET برای درخواست داده از سرور استفاده می‌شود. این نوع درخواست، فقط داده‌ها را بازیابی می‌کند و تغییری در سرور ایجاد نمی‌کند.

مثال:

GET /index.html HTTP/1.1
Host: www.example.com

ویژگی‌ها:

• idempotent (عدم تغییر حالت سرور)
• می‌تواند cache شود
• داده‌ها در URL ارسال می‌شوند

2. POST

روش POST برای ارسال داده به سرور به منظور ایجاد یا به‌روزرسانی منبع استفاده می‌شود. داده‌های ارسالی در بدنه درخواست قرار می‌گیرند.

مثال:

POST /submit-form HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded

name=John&age=30

ویژگی‌ها:

• داده‌ها در بدنه درخواست ارسال می‌شوند
• مناسب برای ارسال فرم‌ها
• ممکن است تغییرات در سرور ایجاد کند

3. PUT

روش PUT برای به‌روزرسانی یک منبع موجود یا ایجاد یک منبع جدید در سرور استفاده می‌شود. این روش idempotent است.

مثال:

PUT /users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
"name": "John Doe",
"age": 30
}

ویژگی‌ها:

• idempotent
• داده‌ها در بدنه درخواست ارسال می‌شوند
• برای به‌روزرسانی یا ایجاد منابع استفاده می‌شود

4. DELETE

روش DELETE برای حذف یک منبع از سرور استفاده می‌شود. این روش نیز idempotent است.

مثال:

DELETE /users/123 HTTP/1.1
Host: www.example.com

ویژگی‌ها:

• idempotent
• منبع مشخص شده را حذف می‌کند

5. HEAD

روش HEAD مشابه روش GET است، با این تفاوت که فقط هدرهای پاسخ را دریافت می‌کند و هیچ بدنه‌ای ندارد. این روش برای بررسی متادیتای منابع بدون دانلود آن‌ها استفاده می‌شود.

مثال:

HEAD /index.html HTTP/1.1
Host: www.example.com

ویژگی‌ها:

• مشابه GET، اما بدون بدنه پاسخ
• برای بررسی وضعیت منابع و متادیتا

6. PATCH

روش PATCH برای به‌روزرسانی بخشی از یک منبع موجود در سرور استفاده می‌شود. برخلاف PUT، که کل منبع را جایگزین می‌کند، PATCH فقط بخش‌های مشخصی را به‌روزرسانی می‌کند.

مثال:

PATCH /users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
"age": 31
}

ویژگی‌ها:

• برای به‌روزرسانی بخشی از منبع استفاده می‌شود
• داده‌ها در بدنه درخواست ارسال می‌شوند

روش‌های درخواست HTTP بخش مهمی از ارتباطات وب هستند. انتخاب روش مناسب برای هر عملیات می‌تواند کارایی و امنیت برنامه‌های وب را بهبود بخشد. آگاهی از تفاوت‌ها و ویژگی‌های هر یک از این روش‌ها می‌تواند به توسعه‌دهندگان کمک کند تا برنامه‌های بهتری ایجاد کنند.

کدهای وضعیت HTTP

در هر درخواست HTTP، سرور با یک کد وضعیت (Status Code) پاسخ می‌دهد که نشان‌دهنده وضعیت پردازش درخواست است. این کدها به توسعه‌دهندگان و کاربران کمک می‌کنند تا بفهمند درخواست‌ها چگونه پردازش شده‌اند و آیا مشکلی وجود دارد یا خیر.

دسته‌بندی کدهای وضعیت

کدهای وضعیت HTTP به پنج دسته اصلی تقسیم می‌شوند:

1. 1xx: اطلاعاتی Informational responses (100 – 199)
2. 2xx: موفقیت‌آمیز Successful responses (200 – 299)
3. 3xx: تغییر مسیر Redirection messages (300 – 399)
4. 4xx: خطای کلاینت Client error responses (400 – 499)
5. 5xx: خطای سرور Server error responses (500 – 599)

1. کدهای وضعیت 1xx: اطلاعاتی

این کدها نشان‌دهنده این هستند که درخواست دریافت شده و پردازش آن ادامه دارد.

100 Continue این پاسخ موقت نشان می‌دهد که کلاینت باید درخواست را ادامه دهد یا اگر درخواست قبلاً تکمیل شده است، پاسخ را نادیده بگیرد.

101 Switching Protocols این کد در پاسخ به هدر درخواست Upgrade از کلاینت ارسال می‌شود و نشان می‌دهد که سرور در حال تغییر پروتکل است.

102 Processing (WebDAV) این کد نشان می‌دهد که سرور درخواست را دریافت و پردازش می‌کند، اما هنوز پاسخی در دسترس نیست.

103 Early Hints این کد وضعیت عمدتاً برای استفاده با هدر Link طراحی شده است، که به کاربر اجازه می‌دهد تا منابع را پیش‌بارگذاری کند در حالی که سرور در حال آماده‌سازی پاسخ است یا اتصال پیشینی به یک منبع که صفحه به آن نیاز خواهد داشت برقرار کند.

2. کدهای وضعیت 2xx: موفقیت‌آمیز

این کدها نشان‌دهنده این هستند که درخواست با موفقیت دریافت، فهمیده و پردازش شده است.

200 OK درخواست موفقیت‌آمیز بوده است. معنای “موفقیت” بسته به روش HTTP متفاوت است:

• GET: منبع دریافت و در بدنه پیام ارسال شده است.
• HEAD: هدرهای نمایش در پاسخ گنجانده شده‌اند بدون هیچ بدنه پیامی.
• PUT یا POST: منبع توصیف کننده نتیجه عمل در بدنه پیام ارسال شده است.
• TRACE: بدنه پیام حاوی پیام درخواست به همان صورتی است که توسط سرور دریافت شده است.

201 Created درخواست موفقیت‌آمیز بوده و یک منبع جدید به عنوان نتیجه ایجاد شده است. این پاسخ معمولاً پس از درخواست‌های POST یا برخی از درخواست‌های PUT ارسال می‌شود.

202 Accepted درخواست دریافت شده اما هنوز اقدامی روی آن صورت نگرفته است. این پاسخ تعهدی نمی‌دهد، زیرا در HTTP راهی برای ارسال پاسخ غیر همزمان جهت اعلام نتیجه درخواست وجود ندارد. این پاسخ برای مواردی است که فرآیند یا سرور دیگری درخواست را پردازش می‌کند، یا برای پردازش دسته‌ای.

203 Non-Authoritative Information این کد پاسخ به این معنی است که متادیتای بازگشتی دقیقاً همان چیزی نیست که از سرور مبدأ در دسترس است، بلکه از یک نسخه محلی یا کپی از یک منبع دیگر جمع‌آوری شده است. این کد عمدتاً برای آینه‌ها یا پشتیبان‌های منابع دیگر استفاده می‌شود. به جز در این مورد خاص، پاسخ 200 OK ترجیح داده می‌شود.

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

205 Reset Content به عامل کاربر می‌گوید که سندی که این درخواست را ارسال کرده است را بازنشانی کند.

206 Partial Content این کد پاسخ زمانی استفاده می‌شود که هدر Range از سمت کلاینت ارسال شده باشد تا فقط بخشی از یک منبع را درخواست کند.

207 Multi-Status (WebDAV) اطلاعات مربوط به منابع متعدد را منتقل می‌کند، برای موقعیت‌هایی که کدهای وضعیت متعدد ممکن است مناسب باشند.

208 Already Reported (WebDAV) در داخل عنصر dav:propstat استفاده می‌شود تا از شمارش مکرر اعضای داخلی چندین بایندینگ به یک مجموعه مشابه جلوگیری کند.

226 IM Used (HTTP Delta encoding) سرور یک درخواست GET برای منبع را انجام داده است و پاسخ نمایشی از نتیجه یک یا چند عملیات دستکاری شده بر روی نسخه فعلی است.

3. کدهای وضعیت 3xx: تغییر مسیر

این کدها نشان‌دهنده این هستند که کلاینت باید اقدام اضافی انجام دهد تا درخواست تکمیل شود.

300 Multiple Choices درخواست بیش از یک پاسخ ممکن دارد. عامل کاربر یا کاربر باید یکی از آن‌ها را انتخاب کند. (هیچ روش استانداردی برای انتخاب یکی از پاسخ‌ها وجود ندارد، اما توصیه می‌شود که لینک‌های HTML به امکانات مختلف داده شوند تا کاربر بتواند انتخاب کند.)

301 Moved Permanently آدرس URL منبع درخواست شده به طور دائمی تغییر کرده است. URL جدید در پاسخ داده می‌شود.

302 Found این کد پاسخ به این معنی است که URI منبع درخواست شده به طور موقت تغییر کرده است. تغییرات بیشتری در URI ممکن است در آینده ایجاد شود. بنابراین، کلاینت باید در درخواست‌های آینده از همین URI استفاده کند.

303 See Other سرور این پاسخ را ارسال کرده است تا کلاینت را به URI دیگری با یک درخواست GET برای دریافت منبع درخواست شده هدایت کند.

304 Not Modified این کد برای اهداف ذخیره‌سازی (caching) استفاده می‌شود. به کلاینت می‌گوید که پاسخ تغییر نکرده است، بنابراین کلاینت می‌تواند از همان نسخه ذخیره شده پاسخ استفاده کند.

305 Use Proxy (Deprecated) در نسخه قبلی مشخصات HTTP تعریف شده بود که نشان دهد پاسخ درخواست باید از طریق یک پروکسی دسترسی پیدا کند. به دلیل نگرانی‌های امنیتی در مورد پیکربندی پروکسی درون باند منسوخ شده است.

306 Unused این کد پاسخ دیگر استفاده نمی‌شود؛ فقط به عنوان رزرو شده باقی مانده است. این کد در نسخه قبلی مشخصات HTTP/1.1 استفاده می‌شد.

307 Temporary Redirect سرور این پاسخ را ارسال می‌کند تا کلاینت را به URI دیگری با همان روش استفاده شده در درخواست قبلی هدایت کند. این کد همان معنای پاسخ HTTP 302 Found را دارد، با این تفاوت که عامل کاربر نباید روش HTTP استفاده شده را تغییر دهد: اگر یک POST در درخواست اول استفاده شده است، باید یک POST در درخواست دوم نیز استفاده شود.

308 Permanent Redirect این به این معنی است که منبع اکنون به طور دائمی در یک URI دیگر واقع شده است، که توسط هدر Location: در پاسخ HTTP مشخص شده است. این کد همان معنای پاسخ HTTP 301 Moved Permanently را دارد، با این تفاوت که عامل کاربر نباید روش HTTP استفاده شده را تغییر دهد: اگر یک POST در درخواست اول استفاده شده است، باید یک POST در درخواست دوم نیز استفاده شود.

4. کدهای وضعیت 4xx: خطای کلاینت

این کدها نشان‌دهنده این هستند که مشکلی در درخواست کلاینت وجود دارد.

400 Bad Request سرور نمی‌تواند یا نمی‌خواهد درخواست را پردازش کند به دلیل چیزی که به عنوان خطای کلاینت درک می‌شود (مثلاً نحو درخواست نادرست، قاب‌بندی پیام درخواست نامعتبر، یا مسیریابی فریبنده درخواست).

401 Unauthorized اگرچه استاندارد HTTP این را “غیرمجاز” مشخص کرده است، از نظر معنایی این پاسخ به معنی “احراز هویت نشده” است. یعنی کلاینت باید برای دریافت پاسخ درخواست احراز هویت کند.

402 Payment Required (Experimental) این کد پاسخ برای استفاده‌های آینده رزرو شده است. هدف اولیه از ایجاد این کد استفاده از آن برای سیستم‌های پرداخت دیجیتال بود، با این حال این کد وضعیت به ندرت استفاده می‌شود و هیچ کنوانسیون استانداردی وجود ندارد.

403 Forbidden کلاینت دسترسی به محتوای درخواست شده ندارد؛ یعنی، غیرمجاز است، بنابراین سرور از ارائه منبع درخواست شده خودداری می‌کند. برخلاف 401 Unauthorized، هویت کلاینت برای سرور شناخته شده است.

404 Not Found سرور نمی‌تواند منبع درخواست شده را پیدا کند. در مرورگر، این به معنی آن است که URL شناسایی نمی‌شود. در یک API، این می‌تواند به این معنا باشد که نقطه پایانی معتبر است اما خود منبع وجود ندارد. سرورها ممکن است این پاسخ را به جای 403 Forbidden ارسال کنند تا وجود منبع را از یک کلاینت غیرمجاز پنهان کنند. این کد پاسخ احتمالاً به دلیل وقوع مکرر آن در وب، معروف‌ترین کد وضعیت است.

405 Method Not Allowed روش درخواست توسط سرور شناخته شده است اما توسط منبع هدف پشتیبانی نمی‌شود. برای مثال، یک API ممکن است اجازه ندهد که از روش DELETE برای حذف یک منبع استفاده شود.

406 Not Acceptable این پاسخ زمانی ارسال می‌شود که سرور وب پس از انجام مذاکره محتوای هدایت شده توسط سرور، هیچ محتوایی که با معیارهای ارائه شده توسط عامل کاربر سازگار باشد، پیدا نکند.

407 Proxy Authentication Required این پاسخ مشابه 401 Unauthorized است، اما احراز هویت باید توسط یک پروکسی انجام شود.

408 Request Timeout این پاسخ بر روی یک اتصال بیکار توسط برخی سرورها ارسال می‌شود، حتی بدون هیچ درخواست قبلی توسط کلاینت. این به معنی آن است که سرور می‌خواهد این اتصال بلااستفاده را ببندد. این پاسخ بیشتر استفاده می‌شود چون برخی مرورگرها مانند Chrome، Firefox 27+، یا IE9 از مکانیزم‌های پیش‌اتصال HTTP برای سرعت بخشیدن به گشت و گذار استفاده می‌کنند. همچنین توجه داشته باشید که برخی سرورها تنها اتصال را می‌بندند بدون ارسال این پیام.

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

410 Gone این پاسخ زمانی ارسال می‌شود که محتوای درخواست شده به طور دائمی از سرور حذف شده است، بدون هیچ آدرس انتقالی. از کلاینت‌ها انتظار می‌رود که حافظه پنهان و لینک‌های خود به منبع را حذف کنند. مشخصات HTTP قصد دارد که از این کد وضعیت برای “خدمات تبلیغاتی موقت” استفاده کند. API‌ها نباید احساس کنند که موظف به نشان دادن منابعی که حذف شده‌اند با این کد وضعیت هستند.

411 Length Required سرور درخواست را رد کرد زیرا فیلد هدر Content-Length تعریف نشده است و سرور به آن نیاز دارد.

412 Precondition Failed کلاینت پیش‌شرط‌هایی را در هدرهای خود نشان داده است که سرور آنها را برآورده نمی‌کند.

413 Payload Too Large موجودیت درخواست بزرگتر از محدودیت‌های تعریف شده توسط سرور است. سرور ممکن است اتصال را ببندد یا فیلد هدر Retry-After را برگرداند.

414 URI Too Long آدرس URI درخواست شده توسط کلاینت طولانی‌تر از آن است که سرور حاضر به تفسیر آن باشد.

415 Unsupported Media Type فرمت رسانه‌ای داده‌های درخواست شده توسط سرور پشتیبانی نمی‌شود، بنابراین سرور درخواست را رد می‌کند.

416 Range Not Satisfiable محدوده مشخص شده توسط فیلد هدر Range در درخواست قابل برآورده شدن نیست. ممکن است محدوده خارج از اندازه داده‌های URI هدف باشد.

417 Expectation Failed این کد پاسخ به این معناست که انتظار نشان داده شده توسط فیلد هدر Expect درخواست نمی‌تواند توسط سرور برآورده شود.

418 I’m a teapot سرور از تلاش برای دم کردن قهوه با یک قوری امتناع می‌کند.

421 Misdirected Request درخواست به یک سرور هدایت شده است که قادر به تولید پاسخ نیست. این می‌تواند توسط یک سرور ارسال شود که برای تولید پاسخ‌ها برای ترکیب اسکیم و اختیاراتی که در URI درخواست درج شده‌اند پیکربندی نشده است.

422 Unprocessable Content (WebDAV) درخواست به خوبی شکل گرفته است اما به دلیل خطاهای معنایی نمی‌تواند دنبال شود.

423 Locked (WebDAV) منبعی که به آن دسترسی می‌شود قفل شده است.

424 Failed Dependency (WebDAV) درخواست به دلیل شکست یک درخواست قبلی شکست خورده است.

425 Too Early (Experimental) نشان می‌دهد که سرور حاضر نیست ریسک پردازش درخواستی را که ممکن است دوباره ارسال شود بپذیرد.

426 Upgrade Required سرور از انجام درخواست با استفاده از پروتکل فعلی خودداری می‌کند اما ممکن است پس از ارتقاء کلاینت به یک پروتکل دیگر، این درخواست را انجام دهد. سرور یک هدر Upgrade در یک پاسخ 426 ارسال می‌کند تا پروتکل‌های مورد نیاز را نشان دهد.

428 Precondition Required سرور مبدأ درخواست را نیازمند به شرطی بودن می‌داند. این پاسخ برای جلوگیری از مشکل “به‌روزرسانی گمشده” طراحی شده است، جایی که یک کلاینت حالت یک منبع را دریافت می‌کند، آن را تغییر می‌دهد و دوباره به سرور می‌فرستد، در حالی که در همین حین یک طرف سوم حالت را در سرور تغییر داده است که منجر به تضاد می‌شود.

429 Too Many Requests کاربر تعداد زیادی درخواست در یک بازه زمانی معین ارسال کرده است (“rate limiting“).

431 Request Header Fields Too Large سرور حاضر به پردازش درخواست نیست زیرا فیلدهای هدر آن خیلی بزرگ هستند. درخواست ممکن است پس از کاهش اندازه فیلدهای هدر درخواست دوباره ارسال شود.

451 Unavailable For Legal Reasons عامل کاربر یک منبعی را درخواست کرده است که ارائه آن به طور قانونی امکان‌پذیر نیست، مانند یک صفحه وب که توسط دولت سانسور شده است.

5. کدهای وضعیت 5xx: خطای سرور

این کدها نشان‌دهنده این هستند که سرور در پردازش درخواست دچار مشکل شده است.

500 Internal Server Error سرور با شرایطی مواجه شده است که نمی‌داند چگونه آن را اداره کند.

501 Not Implemented روش درخواست توسط سرور پشتیبانی نمی‌شود و نمی‌تواند پردازش شود. تنها روش‌هایی که سرورها موظف به پشتیبانی از آن‌ها هستند (و بنابراین نباید این کد را برگردانند) GET و HEAD هستند.

502 Bad Gateway این پاسخ خطا به این معناست که سرور، در حالی که به عنوان یک دروازه عمل می‌کند تا پاسخی را برای پردازش درخواست دریافت کند، یک پاسخ نامعتبر دریافت کرده است.

503 Service Unavailable سرور آماده پردازش درخواست نیست. دلایل رایج شامل سروری است که برای تعمیرات از کار افتاده یا بار زیادی دارد. توجه داشته باشید که همراه با این پاسخ، باید یک صفحه کاربر پسند که مشکل را توضیح می‌دهد نیز ارسال شود. این پاسخ باید برای شرایط موقت استفاده شود و هدر HTTP Retry-After در صورت امکان باید حاوی زمان تخمینی برای بازیابی سرویس باشد. مدیر وب همچنین باید به هدرهای مرتبط با کش که همراه با این پاسخ ارسال می‌شوند توجه کند، زیرا این پاسخ‌های شرایط موقت معمولاً نباید ذخیره شوند.

504 Gateway Timeout این پاسخ خطا زمانی داده می‌شود که سرور به عنوان یک دروازه عمل می‌کند و نمی‌تواند به موقع پاسخی دریافت کند.

505 HTTP Version Not Supported نسخه HTTP استفاده شده در درخواست توسط سرور پشتیبانی نمی‌شود.

506 Variant Also Negotiates سرور دارای یک خطای پیکربندی داخلی است: منبع واریانتی که انتخاب شده است برای مذاکره محتوای شفاف پیکربندی شده است و بنابراین نقطه پایانی مناسب در فرآیند مذاکره نیست.

507 Insufficient Storage (WebDAV) روش نمی‌تواند روی منبع اجرا شود زیرا سرور قادر به ذخیره نمایشی که برای تکمیل موفقیت‌آمیز درخواست لازم است، نیست.

508 Loop Detected (WebDAV) سرور یک حلقه بی‌نهایت را در حین پردازش درخواست تشخیص داده است.

510 Not Extended گسترش‌های بیشتری به درخواست برای تکمیل آن توسط سرور مورد نیاز است.

511 Network Authentication Required نشان می‌دهد که کلاینت باید برای دسترسی به شبکه احراز هویت شود.