मुझे GET या POST विधि का उपयोग कब करना चाहिए? उनमें क्या अंतर है?

Question

उपयोग GETया POSTविधि करते समय क्या अंतर है ? कौन सा अधिक सुरक्षित है? उनमें से प्रत्येक के (डिस) लाभ क्या हैं?

( इसी तरह का सवाल )

Comments

गेट में एक शरीर नहीं है, इसलिए अभ्यास का मतलब है कि आप नाम तक सीमित हैं -> अधिक जटिल संरचना के लिए किसी भी क्वेरी स्ट्रिंग एन्कोडिंग प्रारूप की कमी के कारण डेटा संरचना के रूप में मूल्य जोड़े। यदि आपको अपने अनुरोधों (यानी एक सरणी, ऑब्जेक्ट आदि) में अधिक जटिल डेटा संरचनाओं को संभालने की आवश्यकता है, तो आपको POST और शायद अधिक उन्नत प्रारूपों (json / xml) का उपयोग करने की आवश्यकता है। संक्षिप्त में कहा गया: जब तक आपको वास्तव में (URL / संसाधन खोज योग्य नहीं होना चाहिए) GET का उपयोग न करें।

— थीमीहाई

के संभावित डुप्लिकेट जब आप पोस्ट का उपयोग करें और जब आप प्राप्त प्रयोग करते हैं?

— इमरान अली खान

Answer 1

यह सुरक्षा की बात नहीं है। HTTP प्रोटोकॉल परिभाषित करता है प्राप्त प्रकार होने के रूप में अनुरोध idempotent , पदों दुष्प्रभाव हो सकते हैं, जबकि। सादे अंग्रेजी में, इसका मतलब है कि GET का उपयोग किसी चीज़ को देखने के लिए किया जाता है, उसे बदले बिना, जबकि POST का उपयोग किसी चीज़ को बदलने के लिए किया जाता है। उदाहरण के लिए, एक खोज पृष्ठ को GET का उपयोग करना चाहिए, जबकि एक ऐसा रूप जो आपके पासवर्ड को बदलता है, को POST का उपयोग करना चाहिए।

इसके अलावा, ध्यान दें कि PHP अवधारणाओं को थोड़ा भ्रमित करता है। POST अनुरोध को क्वेरी स्ट्रिंग से और अनुरोध निकाय के माध्यम से इनपुट मिलता है। GET अनुरोध केवल क्वेरी स्ट्रिंग से इनपुट प्राप्त करता है। तो एक POST अनुरोध एक GET अनुरोध का सुपरसेट है; आप उपयोग कर सकते हैं $_GETएक पोस्ट अनुरोध में है, और यह भी अर्थपूर्ण हो सकता है में एक ही नाम के साथ मानकों के लिए $_POSTऔर $_GETहै कि मतलब अलग बातें।

उदाहरण के लिए, मान लें कि आपके पास लेख संपादित करने के लिए एक फ़ॉर्म है। लेख-आईडी क्वेरी स्ट्रिंग में हो सकता है (और, इसलिए, इसके माध्यम से उपलब्ध है $_GET['id']), लेकिन मान लें कि आप लेख-आईडी को बदलना चाहते हैं। नई आईडी तब अनुरोध निकाय ( $_POST['id']) में मौजूद हो सकती है । ठीक है, शायद यह सबसे अच्छा उदाहरण नहीं है, लेकिन मुझे आशा है कि यह दोनों के बीच के अंतर को दिखाता है।

Comments

निश्चित रूप से GET और POST के अंतर का एक सुरक्षा पहलू है। एक दुर्भावनापूर्ण साइट उदाहरण के लिए छवि टैग में एक मनमाने ढंग से GET अनुरोध चिपका सकती है, जिससे उपयोगकर्ता किसी अन्य सर्वर के विरुद्ध GET कर सकते हैं। यदि यह GET दूसरों की तरह है / deleteemyaccount तो खराब चीजें होती हैं।

— फ्रैंक श्वाइटमैन

मेरा मतलब था कि $ _POST की सामग्री जादुई रूप से दुर्भावनापूर्ण उपयोगकर्ताओं से छिपी नहीं है। सभी चीज़ प्रोग्रामिंग के लिए स्पष्ट रूप से सुरक्षा पहलू हैं।

— troelskn

यह पोस्ट पूरी तरह से प्रश्न का उत्तर नहीं देती है क्योंकि वह सुरक्षा निहितार्थ का उल्लेख नहीं करता है। शीर्ष भाग तब तक अच्छा होता है जब तक वर्तनी की "दर्द वाली अंग्रेजी" को "सादे अंग्रेजी" में बदल दिया जाता है। नीचे का हिस्सा भी मुश्किल है। कुल मिलाकर, मेरे पोस्ट थो से बहुत बेहतर है। :-)

— अक्रिकोस

"एक POST अनुरोध को क्वेरी स्ट्रिंग और अनुरोध निकाय के माध्यम से इनपुट मिलता है।" IMHO यह गलत है। या तो इनपुट का उपयोग करने के लिए आपको $ _REQUEST का उपयोग करना होगा। $ _POST को url प्रविष्टियाँ नहीं मिलती हैं।

— गुन्नार बर्नस्टीन

@Frank Schwieterman मुझे पता है कि यह पोस्ट पुरानी है, लेकिन मेरे खाते को हटा देना बेकार नहीं है और इसे प्राप्त करने का उपयोग नहीं करना चाहिए।

— १२:५५ पर ठंढाकार

Answer 2

जब उपयोगकर्ता किसी फ़ॉर्म में जानकारी दर्ज करता है और सबमिट पर क्लिक करता है, तो ब्राउज़र से सर्वर पर जानकारी: URL में, या HTTP अनुरोध के मुख्य भाग में दो तरीके भेजे जा सकते हैं।

GET विधि, जिसका उपयोग पहले उदाहरण में किया गया था, URL में नाम / मान जोड़े को जोड़ती है। दुर्भाग्य से, एक URL की लंबाई सीमित है, इसलिए यह विधि केवल तभी काम करती है जब कुछ ही पैरामीटर हों। यदि प्रपत्र बड़ी संख्या में पैरामीटर का उपयोग करता है, या यदि पैरामीटर में बड़ी मात्रा में डेटा है, तो URL को छोटा किया जा सकता है। इसके अलावा, URL पर दिए गए पैरामीटर ब्राउज़र के पता क्षेत्र में दिखाई देते हैं, जो पासवर्ड के लिए सबसे अच्छी जगह नहीं है।

GET विधि का विकल्प POST विधि है। यह विधि HTTP अनुरोध के शरीर के अंदर नाम / मूल्य जोड़े को पैकेज करती है, जो एक क्लीनर URL के लिए बनाता है और प्रपत्र आउटपुट पर कोई आकार सीमाएं नहीं लगाता है। यह अधिक सुरक्षित भी है।

Comments

यह अधिक "सुरक्षित" कैसे है?

— जूलियन रेशे

क्योंकि इसके बदलने के लिए कठिन है? आप पता बार में GET को बदल सकते हैं, लेकिन यह POST के साथ उतना आसान नहीं है।

— एडॉप्टर

सर्वर क्लाइंट पर भरोसा नहीं कर सकता। झूठी मान्यताओं के आसपास अपने आवेदन को डिजाइन करना, सुरक्षित से बहुत दूर है।

— troelskn

ओपनिड भी नहीं बचा है, क्योंकि इसे तोड़ा जा सकता है?

— 8

मेरा मानना ​​है कि यह सबसे स्पष्ट स्पष्टीकरण है - भेजे गए डेटा के प्लेसमेंट के बारे में अंतर। धन्यवाद।

— ग्रीनल्डमैन

Answer 3

सबसे अच्छा जवाब पहले वाला था।

आप उपयोग कर रहे हैं:

• प्राप्त जब आप डेटा (डेटा प्राप्त) प्राप्त करना चाहते हैं।
• POST जब आप डेटा (POST DATA) भेजना चाहते हैं।

Comments

अनुरोध / प्रतिक्रिया सेवा पैटर्न का उपयोग क्या है और आप दोनों करना चाहते हैं? ;) मैं ज्यादातर मामलों में POST का उपयोग करना पसंद करूँगा जब मुझे प्रतिक्रिया वापस करने की आवश्यकता होगी।

— दिमित्री पावलोव

आम तौर पर यह सच है। GETडेटा भेजने में भी पूरी तरह से सक्षम है, इसलिए बहुत सटीक उत्तर नहीं।

— पैट्रिक हॉफमैन

Answer 4

उपयोग करने के लिए दो सामान्य "सुरक्षा" निहितार्थ हैं GET। चूंकि डेटा URL स्ट्रिंग में दिखाई देता है, इसलिए संभव है कि कोई व्यक्ति आपके पते पर बार / URL को देख रहा हो, वह ऐसा कुछ देखने में सक्षम हो सकता है जो उन्हें सत्र कुकी के रूप में निजी नहीं होना चाहिए, जो संभवतः आपके सत्र को हाईजैक करने के लिए उपयोग किया जा सकता है। ध्यान रहे सभी के पास कैमरा फोन हो।

अनुरोधों के URL के भाग के रूप में अधिकांश वेब सर्वर एक्सेस लॉग में वेरिएबल्स के GETसाथ अन्य सुरक्षा निहितार्थों को GETलॉग करना पड़ता है । स्थिति के आधार पर, विनियामक जलवायु और डेटा की सामान्य संवेदनशीलता यह संभावित रूप से चिंताओं को बढ़ा सकती है।

कुछ क्लाइंट / फायरवॉल / आईडीएस सिस्टम GETअत्यधिक मात्रा में डेटा वाले अनुरोधों पर भड़क सकते हैं और इसलिए अविश्वसनीय परिणाम प्रदान कर सकते हैं।

POST वेब सर्वर पर फ़ाइल अपलोड के लिए उपयोग किए जाने वाले बहु-भाग बाइनरी इनपुट के लिए उन्नत कार्यक्षमता का समर्थन करता है।

POSTकंटेंट-लेंथ हेडर की आवश्यकता होती है, जो एप्लिकेशन विशिष्ट क्लाइंट कार्यान्वयन की जटिलता को बढ़ा सकता है क्योंकि प्रस्तुत डेटा का आकार अग्रिम में एक विशेष रूप से एकल-पास वृद्धिशील मोड में बनने से क्लाइंट अनुरोध को रोकने के लिए जाना जाना चाहिए। शायद HTTPआरपीसी (रिमोट प्रोसीजर कॉल) परिवहन के रूप में इसका उपयोग करके दुरुपयोग करने वालों के लिए एक मामूली मुद्दा ।

दूसरों ने पहले ही अर्थपूर्ण मतभेदों को कवर करने और इस प्रश्न के "जब" भाग में एक अच्छा काम किया है।

Answer 5

मैं जब मैं जानकारी पुन: प्राप्त कर रहा हूँ का उपयोग से एक URL और पोस्ट जब मैं जानकारी भेज रहा हूं करने के लिए एक यूआरएल।

Comments

लेकिन आप GET का उपयोग करने के लिए भी भेज सकते हैं। अंतर प्रारूप (url (GET) या अनुरोध (POST)) में है।

— एरिक

यदि समापन बिंदु एक फ़ाइल को स्वीकार करता है और फ़ाइल से एक पंक्ति लौटाता है (कोई डेटा निर्माण या परिवर्तन या डेटाबेस शामिल नहीं है), तो क्या समापन बिंदु GET या POST होना चाहिए?

— चर

Answer 6

यदि बहुत अधिक डेटा, या सॉर्ट-ऑफ संवेदनशील जानकारी (वास्तव में संवेदनशील सामान के साथ-साथ एक सुरक्षित कनेक्शन की आवश्यकता है) तो आपको POST का उपयोग करना चाहिए।

यदि आप चाहते हैं कि लोग आपके पृष्ठ को बुकमार्क करने में सक्षम हों, तो GET का उपयोग करें, क्योंकि सभी डेटा को बुकमार्क के साथ शामिल किया गया है।

बस GET विधि के साथ REFRESH मारने वाले लोगों से सावधान रहें, क्योंकि उपयोगकर्ता को चेतावनी दिए बिना डेटा हर बार फिर से भेजा जाएगा (POST कभी-कभी उपयोगकर्ता को डेटा को फिर से भेजने के बारे में चेतावनी देता है)।

Comments

यदि समापन बिंदु एक फ़ाइल को स्वीकार करता है और फ़ाइल से एक पंक्ति लौटाता है (कोई डेटा निर्माण या परिवर्तन या डेटाबेस शामिल नहीं है), तो क्या समापन बिंदु GET या POST होना चाहिए?

— चर

@ पोस्ट करने योग्य। इस स्थिति में, क्योंकि फ़ाइल अपलोड को संभालने के लिए POST बनाया गया है और मानक GET नहीं है। आपको पृष्ठ लोड होने पर हर बार फ़ाइल भेजनी होगी, इसलिए यह समझ में आता है कि केवल GET + फ़ाइल के बजाय मानक POST का उपयोग करें जो GET की उम्मीद को तोड़ देगा कि एक URL को हर बार एक ही परिणाम अधिक-कम देना चाहिए।

— अनुदान

Answer 7

यह W3C दस्तावेज़ HTTP GET और POST के उपयोग की व्याख्या करता है।

मुझे लगता है कि यह एक आधिकारिक स्रोत है।

सारांश है (दस्तावेज़ की धारा 1.3):

• GET का उपयोग करें यदि इंटरैक्शन एक प्रश्न की तरह अधिक है (यानी, यह एक सुरक्षित ऑपरेशन है जैसे कि एक क्वेरी, रीड ऑपरेशन, या लुकअप)।
• पोस्ट का उपयोग करें यदि:
  • इंटरैक्शन ऑर्डर की तरह अधिक है, या
  • इंटरैक्शन संसाधन की स्थिति को इस तरह से बदलता है, जिसे उपयोगकर्ता अनुभव करेगा (उदाहरण के लिए, एक सेवा के लिए सदस्यता), या
  • बातचीत के परिणामों के लिए उपयोगकर्ता को जवाबदेह ठहराया जाना चाहिए।

Comments

मुझे लगता है कि इसे इस रूप में और भी संक्षेपित किया जा सकता है: जब सर्वर की स्थिति में परिवर्तन नहीं होता है, तब यह प्राप्त होता है।

— यमचाह

Answer 8

Get और Post के तरीकों का आपके द्वारा उपयोग की जा रही सर्वर तकनीक से कोई लेना-देना नहीं है, यह php, asp.net या रूबी में समान काम करता है। GET और POST HTTP प्रोटोकॉल का हिस्सा हैं। जैसा कि उल्लेख किया गया है, POST अधिक सुरक्षित है। POST फॉर्म भी ब्राउज़र द्वारा कैश नहीं किए जाते हैं। POST का उपयोग बड़ी मात्रा में डेटा ट्रांसफर करने के लिए भी किया जाता है।

Answer 9

डेटा में परिवर्तन करते समय POST का उपयोग करने का कारण:

• Google वेब त्वरक जैसे एक वेब त्वरक पृष्ठ पर सभी (GET) लिंक पर क्लिक करेगा और उन्हें कैश करेगा। यह बहुत बुरा है अगर लिंक चीजों में बदलाव करते हैं।
• एक ब्राउज़र GET अनुरोधों को कैश करता है, भले ही उपयोगकर्ता उस लिंक पर क्लिक करता है जो परिवर्तन को निष्पादित करने के लिए सर्वर को अनुरोध नहीं भेज सकता है।
• CSRF के खिलाफ अपनी साइट / एप्लिकेशन की सुरक्षा के लिए आपको POST का उपयोग करना चाहिए। अपने ऐप को पूरी तरह से सुरक्षित करने के लिए आपको सर्वर पर एक विशिष्ट पहचानकर्ता उत्पन्न करना होगा और उसे अनुरोध में भेजना होगा।

इसके अलावा, क्वेरी स्ट्रिंग (GET के साथ एकमात्र विकल्प) में संवेदनशील जानकारी न डालें क्योंकि यह पता बार, बुकमार्क और सर्वर लॉग में दिखाई देता है।

उम्मीद है कि यह बताता है कि लोग क्यों कहते हैं कि POST 'सुरक्षित' है। यदि आप संवेदनशील डेटा संचारित कर रहे हैं तो आपको SSL का उपयोग करना चाहिए।

Answer 10

GETऔर POSTHTTP तरीके हैं जो समान लक्ष्य प्राप्त कर सकते हैं

GETमूल रूप से डेटा प्राप्त करने (प्राप्त करने) के लिए, ए के GETपास एक शरीर नहीं होना चाहिए, इसलिए कुकीज़ से अलग, जानकारी पास करने का एकमात्र स्थान URL में है और URL लंबाई में सीमित हैं, GETइसकी तुलना में कम सुरक्षित है POSTक्योंकि भेजे गए डेटा का हिस्सा है URL

GETपासवर्ड, क्रेडिट कार्ड या अन्य संवेदनशील जानकारी भेजते समय कभी भी उपयोग न करें !, URL में डेटा सभी को दिखाई देता है, कैश्ड डेटा हो सकता है। GETहानिरहित है जब हम वापस बटन लोड कर रहे हैं या कॉल कर रहे हैं, तो यह पुस्तक चिह्नित होगी, पैरामीटर ब्राउज़र इतिहास में बने रहेंगे, केवल ASCII वर्णों की अनुमति है।

POSTइसमें कुछ भी शामिल हो सकता है, जैसे डेटा संग्रहीत करना या अपडेट करना, या उत्पाद ऑर्डर करना या ई-मेल भेजना। POSTविधि में एक शरीर है।

POSTसर्वर के लिए संवेदनशील और गोपनीय जानकारी पास करने के लिए विधि सुरक्षित है यह URL में क्वेरी पैरामीटर में दिखाई नहीं देगा और पैरामीटर ब्राउज़र इतिहास में सहेजे नहीं जाते हैं। डेटा लंबाई पर कोई प्रतिबंध नहीं हैं। जब हम ब्राउज़र को पुनः लोड कर रहे हैं, तो उपयोगकर्ता को सचेत करना चाहिए कि डेटा फिर से प्रस्तुत किया जाएगा। POSTविधि को बुकमार्क नहीं किया जा सकता है

Answer 11

1. GET विधि का उपयोग कम संवेदनशील डेटा भेजने के लिए किया जाता है जबकि POST विधि का उपयोग संवेदनशील डेटा भेजने के लिए किया जाता है।
2. POST विधि का उपयोग करके आप GET विधि की तुलना में बड़ी मात्रा में डेटा भेज सकते हैं।
3. GET विधि द्वारा भेजा गया डेटा ब्राउज़र हेडर बार में दिखाई देता है जबकि POST विधि द्वारा भेजा गया डेटा अदृश्य है।

Answer 12

यदि आप संसाधन URL से प्राप्त करना चाहते हैं तो GET विधि का उपयोग करें। यदि आप अपने ब्राउज़र का पिछला बटन दबाते हैं, तो आप हमेशा अंतिम पृष्ठ देख सकते हैं, और इसे बुकमार्क किया जा सकता है, इसलिए यह POST विधि के रूप में सुरक्षित नहीं है।

यदि आप URL को कुछ सबमिट करना चाहते हैं तो POST विधि का उपयोग करें। उदाहरण के लिए, आप एक Google खाता बनाना चाहते हैं और आपको सभी विस्तृत जानकारी भरने की आवश्यकता हो सकती है, फिर आप 'सबमिट' बटन दबाते हैं (POST विधि को यहां कहा जाता है), एक बार जब आप सफलतापूर्वक सबमिट कर देते हैं, और अपने ब्राउज़र के बैक बटन को हिट करने का प्रयास करते हैं , आपको भरे हुए फॉर्म के साथ अंतिम पृष्ठ के बजाय त्रुटि या एक नया रिक्त फ़ॉर्म मिलेगा।

Answer 13

GETविधि:

• इसका उपयोग केवल 256 वर्ण तिथि भेजने के लिए किया जाता है

• इस पद्धति का उपयोग करते समय, जानकारी ब्राउज़र पर देखी जा सकती है

• यह प्रपत्रों द्वारा उपयोग की जाने वाली डिफ़ॉल्ट विधि है

• यह इतना सुरक्षित नहीं है।

---

POSTविधि:

• इसका उपयोग असीमित डेटा भेजने के लिए किया जाता है।

• इस पद्धति के साथ, जानकारी को ब्राउज़र पर नहीं देखा जा सकता है

• आप स्पष्ट रूप से POSTविधि का उल्लेख कर सकते हैं

• यह GETविधि की तुलना में अधिक सुरक्षित है

• यह अधिक उन्नत सुविधाएँ प्रदान करता है

Comments

"इसका उपयोग केवल 256 वर्ण तिथि भेजने के लिए किया जाता है" - यह सच नहीं है। "इस पद्धति का उपयोग करते समय, जानकारी ब्राउज़र पर देखी जा सकती है" - पोस्ट डेटा ब्राउज़र में भी दिखाई देता है, यह सिर्फ इतना स्पष्ट नहीं है। "यह अधिक उन्नत सुविधाएँ प्रदान करता है" - जैसे?

— क्वेंटिन

यह बहुत उपयोगी उत्तर नहीं है। गलत जानकारी जैसे कि 'यह इतना सुरक्षित नहीं है' और 'अधिक उन्नत सुविधाएँ प्रदान करता है', और क्वेंटिन द्वारा बताई गई अन्य बातें।

— एंड्रयू बार्बर