GET और POST HTTP अनुरोध विधियों के बीच मुख्य अंतर क्या हैं?

उद्देश्य

• GET किसी संसाधन की एक प्रतिनिधि प्रति माँगता है। विनिर्देशन के अनुसार यह केवल-पठन है: क्लाइंट किसी सर्वर-स्थिति परिवर्तन की अपेक्षा नहीं करता। RFC 9110 नोट करता है कि GET अनुरोध में बॉडी भेजने के अर्थ परिभाषित नहीं हैं, इसलिए GET में बॉडी नहीं होनी चाहिए।
• POST लक्ष्य संसाधन से अनुरोध करता है कि वह अनुरोध बॉडी में शामिल डेटा को उस संसाधन की अपनी semantics के अनुसार संसाधित करे (रिकॉर्ड बनाना, फ़ॉर्म सबमिट करना, फ़ाइल अपलोड करना, आदि)।

डेटा कहाँ जाता है

• GET पैरामीटर URL क्वेरी स्ट्रिंग में ले जाता है (? के बाद, जिसका स्वरूप key=value&... होता है)। ये एड्रेस बार में दिखाई देते हैं और ब्राउज़र इतिहास तथा सर्वर लॉग में दर्ज होते हैं, और व्यावहारिक URL-लंबाई सीमा से बंधे होते हैं।
• POST डेटा को अनुरोध बॉडी में ले जाता है; प्रकार Content-Type हेडर द्वारा दिया जाता है। HTML फ़ॉर्म सामान्यतः application/x-www-form-urlencoded (डिफ़ॉल्ट) या multipart/form-data (फ़ाइलों के लिए) का उपयोग करते हैं। प्रोटोकॉल-स्तर पर कोई निश्चित आकार सीमा नहीं है, लेकिन सर्वर और प्रॉक्सी अपनी-अपनी अधिकतम सीमाएँ तय करते हैं (जैसे Nginx client_max_body_size)।

RFC 9110 के अनुसार गुण

• Safe: GET सुरक्षित है (केवल-पठन); POST सुरक्षित नहीं है।
• Idempotent: कोई अनुरोध idempotent होता है यदि उसे N बार करने का प्रभाव सर्वर-स्थिति पर एक बार करने जैसा ही हो। GET idempotent है; POST नहीं — इसे बार-बार दोहराने से डुप्लिकेट बन सकते हैं, जैसे दो समान ऑर्डर। Idempotent, safe के समान नहीं है (PUT और DELETE idempotent हैं लेकिन safe नहीं), और यह इस बारे में कुछ नहीं कहता कि प्रतिक्रिया का मुख्य भाग समान होगी या नहीं।
• Cacheable: GET प्रतिक्रियाएँ डिफ़ॉल्ट रूप से cacheable होती हैं; POST प्रतिक्रियाएँ केवल तभी cacheable होती हैं जब उनमें स्पष्ट ताज़गी जानकारी और एक मेल खाता Content-Location हेडर हो, जो व्यवहार में दुर्लभ है।

व्यावहारिक निहितार्थ

• प्राप्ति और नेविगेशन के लिए GET का उपयोग करें; परिणामों को सुरक्षित रूप से दोहराया जा सकता है, बुकमार्क किया जा सकता है, और प्रीफ़ेच किया जा सकता है, तथा GET पृष्ठ को रिफ़्रेश करना हानिरहित है।
• स्थिति बदलने वाली कार्रवाइयों और संवेदनशील या बड़े payload भेजने के लिए POST का उपयोग करें। POST पृष्ठ को रिफ़्रेश करना या उस पर वापस जाना ब्राउज़र की "फ़ॉर्म दोबारा भेजने की पुष्टि करें" चेतावनी को ट्रिगर करता है।
• पासवर्ड कभी GET से न भेजें — वे URL, लॉग और इतिहास में दर्ज हो जाएँगे। यह स्वच्छता है, एन्क्रिप्शन नहीं: HTTPS ट्रांज़िट में URL और बॉडी दोनों को एन्क्रिप्ट करता है, लेकिन URL फिर भी लॉग हो जाता है।

सामान्य अनुवर्ती प्रश्न

• सुरक्षित विधियाँ GET, HEAD, OPTIONS हैं; idempotent विधियाँ GET, HEAD, PUT, DELETE हैं; POST इनमें से कोई नहीं है।
• दोनों विधियाँ HTML फ़ॉर्म (method attribute) द्वारा समर्थित हैं।
• RFC के अर्थ में "safe" का मतलब स्थिति में परिवर्तन न होना है, डेटा-सुरक्षा नहीं।
• अनुप्रयोग-स्तरीय POST idempotency अक्सर idempotency keys के माध्यम से लागू की जाती है.