متدهای HTTP به زبان ساده دستوراتی هستند که به سرور می گوید با یک منبع مشخص چه کاری انجام دهد: آن را بخواند، بسازد، ویرایش کند یا حذف کند. هر بار که یک صفحه وب را باز می کنید، در پشت صحنه یکی از همین متدها در حال اجراست.
در این مطلب از پیام رسان متدهای HTTP را دقیق و کاربردی بررسی کنیم؛ از GET و POST گرفته تا PUT، PATCH، DELETE و حتی HEAD و OPTIONS که کمتر به چشم می آیند.
پیشنهاد خواندنی: بد نیست قبل از آشنایی با متدهای HTTP ابتدا با معماری API REST آشنا شوید؛ چون این متدها بخشی از همین معماری هستند.
متدهای HTTP در یک نگاه
قبل از اینکه وارد جزئیات شویم، بهتر است یک نمای کلی از مهم ترین متدها داشته باشید. جدول زیر خلاصه ای از پرکاربردترین متدهاست:
| متد | کاربرد اصلی | دارای بادی | Idempotent |
|---|---|---|---|
| GET | خواندن و دریافت اطلاعات | خیر | بله |
| POST | ایجاد منبع جدید یا ارسال داده | بله | خیر |
| PUT | جایگزینی کامل یک منبع | بله | بله |
| PATCH | ویرایش جزئی یک منبع | بله | معمولاً خیر |
| DELETE | حذف یک منبع | معمولاً خیر | بله |
اگر با دنیای برنامه نویسی آشنا نباشید، احتمالاً مفهوم بعضی از ستون های جدول را متوجه نشده اید. اما نگران نباشید، در ادامه درباره بادی و Idempotent صحبت خواهیم کرد.
جالب است بدانید که وظایف متدها را با کلمه اختصاری CRUD نمایش می دهند که شامل ابتدای چهار کلمه Create (ایجاد)، Read (خواندن)، Update (بروزرسانی) و Delete (حذف کردن) است.
متد HTTP دقیقاً چکار می کند؟
هر درخواست HTTP همیشه به یک منبع یا Resource مرتبط است. یعنی چیزهایی مثل یک پیامک، یک کاربر یا یک سفارش که آدرس مشخصی در سرور دارند.
متد همان فعلی است که مشخص می کند با آن منبع چه کاری انجام می شود.
حالا متدهای HTTP یا همان HTTP Methods مشخص می کنند که می خواهید با آن منبع چکار کنید. هر کدام از این متدها نیز با هدف خاصی پیاده می شوند:
- GET برای دریافت اطلاعات منبع
- POST برای ایجاد یک منبع جدید یا ارسال داده به یک منبع
- PUT و PATCH برای به روزرسانی منبع
- DELETE برای حذف منبع
تمام آنچه در ادامه این مقاله می خوانید، در همین چهار مفهوم ساده خلاصه می شوند.

متد، هدر و بادی چیست؟ ساختار یک درخواست HTTP
یک درخواست HTTP فقط از متد تشکیل نمی شود. برای فهم بهتر رفتار متدها، بهتر است اجزای اصلی یک درخواست و پاسخ آن را بشناسید که در مقاله Request و Response به طور کامل توضیح داده شده اند.
به طور خلاصه، هر درخواست از چهار بخش تشکیل می شود:
- خود متد که در ادامه مقاله به طور کامل بررسی می کنیم.
- هدرهای درخواست که اطلاعاتی درباره درخواست، نوع داده، احراز هویت و موارد دیگر است.
- آدرس منبع که نشان می دهد دستورات متد مربوط به کدام منبع است.
- بادی درخواست که شامل داده های مورد نیاز برای سرور است (وجود این بخش ضروری نیست).
انواع متدهای HTTP که باید بشناسید
خب، حال که با مفاهیم اولیه متدهای HTTP آشنا شدید، وقت آن است که برویم سراغ اصل مطلب و آن ها را معرفی کنیم. ازآنجایی که ما در پیام رسان یک وب سرویس پیامکی را مدیریت می کنیم، مثال هایی که می زنیم هم مربوط به همین حوزه هستند.
GET برای خواندن اطلاعات
متد GET صرفاً برای دریافت اطلاعات استفاده می شود و هیچ تغییری در سرور ایجاد نمی کند. به همین دلیل به آن متد Safe یا امن گفته هم می شود. برای مثال در یک وب سرویس پیامکی وظیفه GET این است که از پیامک های ارسال شده گزارش بگیرید و مشخص کند که آیا به مخاطب رسیده اند یا نه. البته این فقط یکی از وظایفی است که اجرا می کند.
POST برای ساخت منبع جدید یا ارسال داده
متد POST برای ایجاد چیزی جدید یا ارسال داده به سرور استفاده می شود. بنابراین معمولاً تغییری در وضعیت سرور ایجاد می کند. رایج ترین کاربرد POST در وب سرویس پیامکی همان لحظه ای است که یک پیامک جدید می سازید و برای ارسال به سرور می فرستید. پس هر بار که یک پیام تازه می فرستید، یک درخواست POST در پشت پرده مشغول کار است.
PUT برای جایگزینی کامل منابع
متد PUT کل منبع هدف را با محتوای درخواستی جایگزین می کند و اگر منبعی در آن آدرس وجود نداشته باشد، آن را می سازد. مثلاً اگر بخواهید کل پروفایل یک الگوی پیامکی (متن، نام و وضعیت) را یک جا با نسخه جدید جایگزین کنید، آن وقت باید به سراغ متد PUT بروید.
PATCH برای ویرایش جزئی منبع
متد PATCH فقط تغییرات جزئی روی یک منبع اعمال می کند و برخلاف PUT که کل منبع را جایگزین می کرد، PATCH فقط فیلدهای مشخص شده را تغییر می دهد. فرض کنید در پنل پیامکی فقط می خواهید عنوان یک الگوی پیامک را عوض کنید، بدون آنکه به متن یا وضعیت آن دست بزنید؛ اینجا PATCH وارد عمل می شود.
DELETE برای حذف منبع
متد DELETE منبع هدف و تمام نمایش های آن را از سرور حذف می کند. مثال آن در وب سرویس پیامکی می تواند حذف یک شماره از دفترچه تلفن یا حذف یک الگوی پیامکی قدیمی از پنل باشد.
متدهای کمتر شناخته شده HEAD و OPTIONS
خانواده متدهای HTTP دو عضو کوچک دارند که مثل بچه های وسط خانواده می مانند و کمتر مورد توجه هستند.
متد HEAD و کاربردهای آن
درخواست HEAD باید Safe و Idempotent باشد و معمولاً برای بررسی وجود یک فایل حجیم پیش از دانلود، اعتبارسنجی تازگی کش یا ارزیابی در دسترس بودن یک Endpoint استفاده می شود. در عمل، HEAD همان GET است، با این تفاوت که بدنه پاسخ را برنمی گرداند و فقط هدرها را می دهد.
OPTIONS و نقش آن در CORS
OPTIONS متدها و گزینه های ارتباطی پشتیبانی شده توسط یک آدرس مشخص را برمی گرداند. این متد به طور گسترده در درخواست های پیش بررسی (preflight) مربوط به CORS استفاده می شود. اگر تا به حال هنگام فراخوانی یک API از مرورگر با پیغام مرموزی مواجه شده اید، احتمالاً موضوع به خطای CORS مربوط است که متد OPTIONS نقش مهمی در رفع مشکل دارد.
مفاهیم Safe و Idempotent چه معنایی دارند؟
این دو کلمه را قبلاً در بخش های مختلف مقاله دیدید، ولی شاید معنی شان را ندانید:
- Safe متدی است که اجرای آن تغییری در وضعیت سرور ایجاد نمی کند.
- Idempotent متدی است که اگر چند بار اجرا شود، در نهایت همان نتیجه اجرای اول را دارد.
متدهای GET، HEAD و OPTIONS متدهای Safe هستند و متدهای GET، HEAD، PUT، DELETE و OPTIONS هم اثر یکسانی دارند؛ چه یک بار اجرا شوند چه چندبار. بنابراین این متدها در دسته Idempotent قرار می گیرند.

GET و POST چه تفاوتی دارند؟
یکی از رایج ترین سوالاتی که برنامه نویسان تازه کار می پرسند، تفاوت دقیق متد GET و POST در روش انتقال داده است. این تفاوت را باید در جایی جستجو کنید که داده ها قرار می گیرند.
- در GET، پارامترها معمولاً داخل Query String یعنی همان بخش انتهایی آدرس بعد از علامت سوال (?) ارسال می شوند.
- در POST داده ها داخل بادی درخواست جای می گیرند و در آدرس دیده نمی شوند. همین تفاوت ساده، پیامدهای امنیتی بزرگی دارد.
نکته امنیتی خیلی مهم!
هرگز کلید API را در Query String قرار ندهید. آدرس هایی که شامل Query String هستند معمولاً در لاگ سرور، تاریخچه مرورگر و حتی ابزارهای آنالیز ذخیره می شوند؛ یعنی اگر YOUR_API_KEY را در همان بخش بگذارید، عملاً آن را در چند جای غیرقابل کنترل افشا کرده اید. راه حل درست این است که کلید را در هدرهای HTTP یا بادی درخواست POST قرار دهید.
به همین دلیل هم هست که فرم های ورود اطلاعات حساس در وب معمولاً از متد POST استفاده می کنند، نه GET؛ چون داده های حساس نباید در آدرس قابل مشاهده باشند.

تفاوت PUT و PATCH با یک مثال ساده
تفاوت میان PUT و PATCH هم از آن سوالاتی است که خیلی داستان دارد. ولی ما کارمان را سخت نمی کنیم و همه چیز را با یک مثال ساده پیش می بریم:
فرض کنید در سیستم شما یک مخاطب (منبع) با این اطلاعات ذخیره شده: نام «علی» و شهر «تهران».
- اگر بخواهید کل منبع را با اطلاعات تازه جایگزین کنید (نام و شهر هر دو عوض شوند) از PUT استفاده می کنید.
- اگر فقط بخواهید نام را به «علی رضایی» تغییر دهید و شهر دست نخورده بماند، به سراغ PATCH می روید.
همین تفاوت کوچک باعث می شود انتخاب متد اشتباه، داده هایی را که نباید تغییر کنند هم بازنویسی کند.

خطای رایج هنگام استفاده از متدهای HTTP
یکی از رایج ترین اشتباهات توسعه دهندگان تازه کار، فراخوانی یک Endpoint با متد نادرست است. مثلاً ارسال درخواست GET به آدرسی که فقط POST را می پذیرد. در این حالت سرور باید یک Status Code (خطای ۴۰۵) به همراه هدر Allow برگرداند تا کلاینت بداند چه متدهایی مجاز هستند.
راهنمایی: اگر هنگام اتصال به وب سرویس پیامکی با خطای 405 مواجه شدید، اولین کاری که باید انجام دهید بررسی مستندات API و اطمینان از تطابق متد ارسالی با متد مورد انتظار Endpoint است.
جمع بندی
در این مطلب خواندید که متدهای HTTP زبان مشترکی هستند که مشخص می کنند با یک منبع چه کاری انجام شود. همین طور با کاربردهای هر متد آشنا شدید و دانستید که از GET برای خواندن، POST برای ساختن، PUT برای جایگزینی، PATCH برای ویرایش و DELETE برای حذف منابع استفاده می شود.
حالا وقت عمل است! اگر می خواهید نتیجه استفاده از متدهای مختلف را در عمل و در یک وب سرویس پیامکی واقعی مشاهده کنید، در پیام رسان ثبت نام و پیامک هدیه دریافت کنید.
اگر نیاز به مشاوره داشتید میتوانید فرم زیر را پر کنید تا کارشناسان ما با شما تماس بگیرند.
نام و شماره تماس خود را ثبت کنید تا کارشناسان ما در سریعترین زمان با شما تماس بگیرند.

