GET اور POST HTTP درخواست کے طریقوں کے درمیان بنیادی فرق کیا ہیں؟

مقصد

• GET ایک وسائل کی نمائندگی کی درخواست کرتا ہے۔ تفصیلات کے مطابق یہ صرف پڑھنے کے لیے ہے: کلائنٹ کو سرور کی حالت میں کسی تبدیلی کی توقع نہیں ہے۔ RFC 9110 نوٹ کرتا ہے کہ GET کی درخواست میں باڈی بھیجنے میں غیر متعینہ الفاظ ہیں، لہذا GET کو باڈی نہیں رکھنی چاہیے۔
• POST ٹارگٹ ریسورس سے درخواست کے باڈی میں بند ڈیٹا کو اس وسائل کے اپنے الفاظ کے مطابق پروسیس کرنے کے لیے کہتا ہے (ریکارڈ بنائیں، فارم جمع کروائیں، فائل اپ لوڈ کریں وغیرہ)۔

ڈیٹا کہاں جاتا ہے۔

• GET URL استفسار کے اسٹرنگ میں پیرامیٹرز رکھتا ہے (? کے بعد، فارمیٹ شدہ key=value&... )۔ یہ ایڈریس بار میں نظر آتے ہیں اور براؤزر کی سرگزشت اور سرور لاگز میں ریکارڈ ہوتے ہیں، اور یو آر ایل کی لمبائی کی عملی حد سے منسلک ہوتے ہیں۔
• POST درخواست کے باڈی میں ڈیٹا رکھتا ہے۔ قسم Content-Type ہیڈر کے ذریعہ دی گئی ہے۔ HTML فارمز عام طور پر application/x-www-form-urlencoded (پہلے سے طے شدہ) یا multipart/form-data (فائلوں کے لیے) استعمال کرتے ہیں۔ پروٹوکول کی سطح کے سائز کی کوئی مقررہ حد نہیں ہے، لیکن سرورز اور پراکسی اپنی اپنی زیادہ سے زیادہ ترتیب دیتے ہیں (جیسے Nginx client_max_body_size )۔

پراپرٹیز فی RFC 9110

• محفوظ: GET محفوظ ہے (صرف پڑھنے کے لیے)؛ POST نہیں ہے۔
• بے ضابطہ: ایک درخواست ناقابل تسخیر ہے اگر اسے N بار بنانے کا سرور کی حالت پر وہی اثر پڑتا ہے جیسا کہ اسے ایک بار کرنا ہے۔ GET کمزور ہے؛ POST نہیں ہے — اسے دہرانے سے ڈپلیکیٹس بن سکتے ہیں، جیسے کہ دو ایک جیسے آرڈر۔ Idempotent محفوظ جیسا نہیں ہے (PUT اور DELETE idempotent ہیں لیکن محفوظ نہیں ہیں)، اور یہ جوابی جسم کے یکساں ہونے کے بارے میں کچھ نہیں کہتا ہے۔
• کیچ ایبل: GET جوابات بطور ڈیفالٹ کیش ایبل ہوتے ہیں۔ POST کے جوابات صرف اس صورت میں قابل ذخیرہ ہوتے ہیں جب ان میں واضح تازگی کی معلومات اور ایک مماثل Content-Location ہیڈر شامل ہوتا ہے، جو کہ عملی طور پر نایاب ہے۔

عملی مضمرات

• بازیافت اور نیویگیشن کے لیے GET استعمال کریں۔ نتائج کو محفوظ طریقے سے دہرایا جا سکتا ہے، بُک مارک کیا جا سکتا ہے، اور پہلے سے تیار کیا جا سکتا ہے، اور GET صفحہ کو تازہ کرنا بے ضرر ہے۔
• ریاست کو تبدیل کرنے والی کارروائیوں اور حساس یا بڑے پے لوڈ بھیجنے کے لیے POST کا استعمال کریں۔ تازہ کاری یا POST صفحہ پر واپس جانے سے براؤزر کی "فارم دوبارہ جمع کرانے کی تصدیق کریں" کی وارننگ متحرک ہوتی ہے۔
• کبھی بھی GET کے ذریعے پاس ورڈ نہ بھیجیں - وہ URL، لاگز اور تاریخ میں اتریں گے۔ یہ حفظان صحت ہے، خفیہ کاری نہیں: HTTPS ٹرانزٹ میں URL اور باڈی دونوں کو خفیہ کرتا ہے، لیکن URL پھر بھی لاگ ان ہے۔

عام فالو اپس

• محفوظ طریقے GET, HEAD, OPTIONS ہیں۔ کمزور طریقے GET, HEAD, PUT, DELETE ہیں۔ POST بھی نہیں ہے۔
• دونوں طریقوں کو ایچ ٹی ایم ایل فارمز (method وصف) سے تعاون حاصل ہے۔
• RFC کے معنی میں "محفوظ" کا مطلب ہے کوئی ریاستی تبدیلی نہیں، ڈیٹا کا تحفظ نہیں۔
• ایپلیکیشن لیول POST آئیڈیمپوٹینسی اکثر آئیڈیمپوٹینسی کیز کا استعمال کرتے ہوئے نافذ کی جاتی ہے۔