अतीत में मेरे कई AJAX अनुप्रयोगों ने GET अनुरोध का उपयोग किया है, लेकिन अब मैं इसके बजाय POST अनुरोध का उपयोग शुरू कर रहा हूं। POST अनुरोध थोड़ा अधिक सुरक्षित और निश्चित रूप से अधिक यूआरएल दोस्ताना/सुंदर लगते हैं। इस प्रकार, मैं सोच रहा हूं कि क्या कोई कारण है कि मुझे जीईटी अनुरोध का उपयोग क्यों करना चाहिए।POST अनुरोध पर GET अनुरोध का उपयोग करने के क्या फायदे हैं?
मैं आम तौर पर इस प्रकार सवाल उठाता हूं: अनुरोध के बाद कुछ भी महत्वपूर्ण परिवर्तन करता है? (लॉगिंग और इसके बावजूद)। यदि ऐसा होता है, तो यह एक POST अनुरोध होना चाहिए, यदि ऐसा नहीं होता है, तो यह एक GET अनुरोध होना चाहिए।
मुझे खुशी है कि आप POST अनुरोधों को "थोड़ा" अधिक सुरक्षित कहते हैं, क्योंकि यह काफी है कि वे क्या हैं; किसी उपयोगकर्ता द्वारा किसी पृष्ठ पर नकली अनुरोध के लिए यह मामूली है। इसे एक POST अनुरोध बनाते हुए, वेब त्वरक को रोकता है या कार्रवाई को गलती से फिर से शुरू करने से पुनः लोड करता है।
AJAX के रूप में, एक और विचार है: यदि आप कॉलबैक समर्थन के साथ जेएसओएन वापस कर रहे हैं, तो सावधान रहें कि कोई भी संवेदनशील डेटा न डालें जो आप नहीं चाहते कि अन्य वेबसाइटें वहां देखने में सक्षम हों। विकिपीडिया के पास इन पंक्तियों के साथ भेद्यता थी जहां उपयोगकर्ता विरोधी सीएसआरएफ टोकन उनके JSON एपीआई के माध्यम से प्रकट किया गया था।
यह आपको कहां से मिल का उपयोग करें और जहां के लिए पोस्ट उपयोग करने का निर्णय करने में मदद कर सकता है:
शायद सबसे महत्वपूर्ण बात यह है कि जीईटी यूआरएल इतिहास में पुस्तक-चिह्न योग्य/देखने योग्य है, और Google के साथ खोजने योग्य है।
पोस्ट महत्वपूर्ण है जहां नहीं करना चाहती घटना बुकमार्क योग्य या सक्षम एक यूआरएल के रूप में में लिखा जाता है होना करने के लिए - अन्यथा आप (या Google आपके URL को क्रॉल करने) हो सकते हैं गलती से से उपयोगकर्ताओं को हटाने की तरह काम करने के लिए अपने प्रणाली, उदाहरण के लिए।
आपको जीईटी का उपयोग करना चाहिए जहां आप एक अनुरोध कर रहे हैं जिसका कोई दुष्प्रभाव नहीं है, उदा। बस कुछ जानकारी ला रहा है। यह अनुरोध कर सकते हैं:
ये बातें सब अच्छी हैं। कुछ भी जो डेटा को पुनर्प्राप्त कर रहा है (विशेष रूप से सार्वजनिक डेटा) वास्तव में एक जीईटी होना चाहिए। सर्वर को समझदार अंतिम-संशोधित भेजना चाहिए: और समाप्त हो जाता है: यदि आवश्यक हो तो कैशिंग को अनुमति देने के लिए हेडर।
POST अनुरोध जीईटी के रूप में असुरक्षित हैं। मुख्य अंतर यह है कि POST का उपयोग सर्वर अनुप्रयोग की स्थिति को संशोधित करने के लिए किया जाता है, जबकि केवल डेटा ही अनुरोध करता है।
जब आप स्वच्छ, "आराम से" यूआरएल का उपयोग करते हैं तो अंतर महत्वपूर्ण होता है, जहां यूआरएल स्वयं संसाधन को निर्दिष्ट करता है, और विभिन्न तरीकों से सर्वर की तरफ विभिन्न क्रियाएं ट्रिगर होती हैं।
> POST अनुरोध जीईटी के रूप में असुरक्षित हैं। पूरी तरह से सच नहीं है, लेकिन मैं आपके बिंदु को समझता हूं। अनुरोधों में अक्सर असुरक्षित पहुंच अनुरोध लॉग फ़ाइलों में उनके डेटा दर्ज किए जाते हैं - जबकि POST आमतौर पर नहीं करते हैं। – Jason
POST और GET स्वाभाविक रूप से सुरक्षित या असुरक्षित नहीं हैं। एक या दूसरे का उपयोग सुरक्षा के लिए बिल्कुल कोई कनेक्शन नहीं है। – Kibbee
किसी अन्य व्यक्ति द्वारा उल्लिखित एक और अंतर नहीं है।
अनुरोध प्राप्त करें URL स्ट्रिंग में पास किए गए हैं और इसलिए आमतौर पर ब्राउज़र पर निर्भर लंबाई सीमा के अधीन हैं।
POST अनुरोध बहुत अधिक हो सकते हैं - असल में वास्तव में सीमित नहीं है।इसलिए यदि आपको किसी वेब सर्वर से डेटा का अनुरोध करने की आवश्यकता है और आप बहुत सारी पैरामीटर जानकारी में गुजर रहे हैं तो POST अनुरोध ही एकमात्र विकल्प हो सकता है।
तो, वास्तव में डेटा अनुरोध (कोई साइड इफेक्ट्स) के अनुरोध के लिए एक जीईटी अनुरोध का उल्लेख करने के पहले उल्लेख किया गया है, जबकि POST अनुरोध आमतौर पर डेटा को सर्वर पर संग्रहीत करने के लिए उपयोग किया जाता है (साइड इफेक्ट्स के साथ)। जैसे फ़ाइल अपलोड करने के लिए POST का उपयोग करें। फ़ाइल पुनर्प्राप्त करने के लिए प्राप्त करें।
ऐसा समय था जब आईई का मानना था कि बहुत कम GET URL स्ट्रिंग थी। लोटस नोट्स जैसे कुछ एप्लिकेशन दस्तावेज़ आईडी के प्रतिनिधित्व के लिए बड़ी संख्या में यादृच्छिक वर्णों का उपयोग करते हैं। मुझे किसी अन्य उत्पाद का उपयोग करने से नाराज था जो यादृच्छिक तार उत्पन्न करता था ताकि पेज यूआरएल प्रत्येक बार अद्वितीय हो। यादृच्छिक स्ट्रिंग बहुत बड़ी थी ... और यह हमेशा स्मृति से IE6 के साथ काम नहीं करता था।
सभी अच्छे अंक, फिर भी, सवाल का जवाब में, प्राप्त अनुरोध पोस्ट अनुरोध पर कुछ स्थितियों में अधिक उपयोगी होते हैं:
भावी पीढ़ी के लिए, ब्लॉग नोटों के साथ इस टिप्पणी को अपडेट करने के लिए फिर: # बिंदु 3 यहाँ, उमर अल Zabir (संदर्भित blog post के लेखक) को पूरा श्रेय:
"एटलस द्वारा डिफ़ॉल्ट सभी AJAX कॉल के लिए HTTP पोस्ट बनाता है। एचटीपी पोस्ट एचटीपी जीईटी से अधिक महंगा है। यह तार पर अधिक बाइट्स को प्रसारित करता है, इस प्रकार कीमती नेटवर्क समय लेता है और यह एएसपी.NET को सर्वर के अंत में अतिरिक्त प्रोसेसिंग भी करता है। , आपको एचटीपी का उपयोग जितना संभव हो उतना प्राप्त करना चाहिए। हालांकि, एचटीपी प्राप्त करने से आप वस्तुओं को पारित करने की अनुमति नहीं देते हैं पैरामीटर के रूप में। आप केवल संख्यात्मक, स्ट्रिंग और दिनांक पास कर सकते हैं। जब आप एक एचटीपी कॉल प्राप्त करते हैं, तो एटलस एन्कोडेड यूआरएल बनाता है और यूआरएल पर हिट करता है। इसलिए, आपको बहुत अधिक सामग्री नहीं पारित करनी चाहिए जो यूआरएल को 2012 वर्णों से बड़ा बन जाती है। जहां तक मुझे पता है, यह किसी भी यूआरएल की अधिकतम लंबाई है।
http पोस्ट के बारे में एक और बुरी बात यह है कि यह वास्तव में 2 कॉल है। पहले ब्राउज़र "HTTP 100 जारी रखें" के साथ http पोस्ट हेडर और सर्वर उत्तरों भेजता है। जब ब्राउज़र इस प्राप्त करता है, यह वास्तविक शरीर भेजता है। "
"वे तेज़ हैं एर "केवल इसलिए कि इसे कैश किया जा सकता है? – Harold
नहीं, यह भी कि वे कैसे काम करते हैं; वे डेटा को किस प्रकार और कैसे भेजते हैं, वे पूरी तरह से अलग हैं। Http: // omaralzabir देखें।com/atlas_2__http_post_is_slower_and_it_s_default_in_atlas/ – jvenema
यह एकमात्र उत्तर है जो ओपी के प्रश्न का उत्तर देता है। अन्य अंतर के बारे में बात कर रहे हैं। –
बुकमार्क वास्तव में AJAX के साथ क्या करना है के रूप में प्रश्नकर्ता के लिए कहा नहीं है। – HalfBrian
सही नहीं है, जब तक आप वापस अनदेखी करने के लिए/आगे आपके AJAX क्षुधा में बटन चाहते हैं यदि नहीं, तो आपको अपने यूआरएल में हैश का उपयोग करने की ज़रूरत है, जो सीधे जीईटी यूआरएल और बुकमार्किंग से संबंधित है। – jvenema