تفاوت های اصلی بین روش های درخواست HTTP GET و POST چیست؟

هدف

• GET نمایش یک منبع را درخواست می کند. براساس مشخصات، فقط خواندنی است: کلاینت انتظار تغییر حالت سرور را ندارد. RFC 9110 اشاره می کند که ارسال یک بدن در یک درخواست GET دارای معنایی تعریف نشده است، بنابراین GET نباید دارای بدنه باشد.
• POST از منبع هدف می خواهد که داده های محصور شده در بدنه درخواست را بر اساس معنای آن منبع پردازش کند (ایجاد رکورد، ارسال فرم، آپلود یک فایل و غیره).

جایی که داده ها می روند

• GET پارامترها را در رشته جستجوی URL (بعد از ?، فرمت شده به عنوان key=value&...) حمل می کند. این موارد در نوار آدرس قابل مشاهده هستند و در تاریخچه مرورگر و گزارش‌های سرور ثبت می‌شوند و با محدودیت طول URL عملی محدود می‌شوند.
• POST داده ها را در بدنه درخواست حمل می کند. نوع توسط هدر Content-Type داده می شود. فرم‌های HTML معمولاً از application/x-www-form-urlencoded (پیش‌فرض) یا multipart/form-data (برای فایل‌ها) استفاده می‌کنند. هیچ محدودیت اندازه ثابت در سطح پروتکل وجود ندارد، اما سرورها و پراکسی ها حداکثرهای خود را پیکربندی می کنند (به عنوان مثال Nginx client_max_body_size).

خواص در RFC 9110

• ایمن: GET امن است (فقط خواندنی). POST نیست.
• Idempotent: یک درخواست در صورتی که N بار آن را انجام دهید همان تاثیری را که یک بار انجام می دهید بر وضعیت سرور داشته باشد، بی قدرت است. GET ناتوان است. POST نیست - تکرار آن ممکن است موارد تکراری ایجاد کند، مانند دو سفارش یکسان. Idempotent همان ایمن نیست (PUT و DELETE ضعیف هستند اما ایمن نیستند) و چیزی در مورد یکسان بودن بدنه پاسخ نمی گوید.
• قابل ذخیره سازی: پاسخ های GET به طور پیش فرض قابل ذخیره سازی هستند. پاسخ‌های POST تنها زمانی قابل ذخیره‌سازی هستند که حاوی اطلاعات تازه بودن صریح و هدر Content-Location باشند که در عمل نادر است.

مفاهیم عملی

• از GET برای بازیابی و ناوبری استفاده کنید. نتایج را می توان با خیال راحت تکرار کرد، نشانک گذاری کرد و از قبل واکشی کرد و تازه کردن صفحه GET بی ضرر است.
• از POST برای اعمال تغییر وضعیت و برای ارسال محموله های حساس یا بزرگ استفاده کنید. بازخوانی یا بازگشت به صفحه POST هشدار "تأیید ارسال مجدد فرم" را در مرورگر ایجاد می کند.
• هرگز رمزهای عبور را از طریق GET ارسال نکنید - آنها در URL، گزارش‌ها و تاریخچه قرار می‌گیرند. این بهداشت است، نه رمزگذاری: HTTPS هم URL و هم بدن در حال انتقال را رمزگذاری می‌کند، اما URL هنوز ثبت شده است.

پیگیری های متداول

• روش های ایمن عبارتند از GET، HEAD، OPTIONS. روش های idempotent عبارتند از GET، HEAD، PUT، DELETE. POST هیچ کدام نیست.
• هر دو روش توسط فرم های HTML (ویژگی method) پشتیبانی می شوند.
• "ایمن" در معنای RFC به معنای عدم تغییر وضعیت است، نه حفاظت از داده ها.
• ناتوانی POST در سطح برنامه اغلب با استفاده از کلیدهای عدم توانایی اعمال می شود.