POST और PUT HTTP REQUEST में क्या अंतर है?

Question

वे दोनों शरीर के अंदर सर्वर को डेटा भेजते प्रतीत होते हैं, इसलिए उन्हें क्या अलग बनाता है?

Comments

क्या इससे आपके सवाल का जवाब मिलता है? PEST बनाम POST in REST

— शाहीन ज़ाहेडी

Answer 1

HTTP PUT:

PUT एक विशिष्ट URI पर फ़ाइल या संसाधन डालता है, और वास्तव में उस URI पर। यदि उस URI में कोई फ़ाइल या संसाधन पहले से मौजूद है, तो PUT उस फ़ाइल या संसाधन को बदल देता है। अगर वहाँ कोई फ़ाइल या संसाधन नहीं है, तो PUT एक बनाता है। पीयूटी बेमतलब है , लेकिन विरोधाभासी रूप से पीयूटी प्रतिक्रियाएं देखने योग्य नहीं हैं।

PUT के लिए HTTP 1.1 RFC स्थान

HTTP पोस्ट:

POST एक विशिष्ट URI को डेटा भेजता है और अनुरोध को संभालने के लिए उस URI पर संसाधन की अपेक्षा करता है। इस बिंदु पर वेब सर्वर यह निर्धारित कर सकता है कि निर्दिष्ट संसाधन के संदर्भ में डेटा का क्या करना है। POST विधि बेकार नहीं है , हालांकि जब तक सर्वर उपयुक्त Cache-Control सेट करता है और समय सीमा समाप्त हो जाता है, तब तक POST प्रतिक्रियाएं अस्वीकार्य होती हैं ।

आधिकारिक HTTP RFC POST को निर्दिष्ट करता है:

• मौजूदा संसाधनों की व्याख्या;
• बुलेटिन बोर्ड, समाचार समूह, मेलिंग सूची या लेखों के समान समूह को संदेश पोस्ट करना;
• डेटा का एक ब्लॉक प्रदान करना, जैसे कि डेटा सबमिट करने की प्रक्रिया के लिए फ़ॉर्म सबमिट करना;
• एक परिशिष्ट ऑपरेशन के माध्यम से एक डेटाबेस का विस्तार।

POST के लिए HTTP 1.1 RFC का स्थान

POST और PUT में अंतर:

RFC स्वयं ही मुख्य अंतर बताता है:

POST और UUT अनुरोधों के बीच मूलभूत अंतर Request-URI के विभिन्न अर्थों में परिलक्षित होता है। POST अनुरोध में URI उस संसाधन की पहचान करता है जो संलग्न इकाई को संभालेगा। वह संसाधन डेटा-स्वीकार करने की प्रक्रिया, कुछ अन्य प्रोटोकॉल का प्रवेश द्वार, या एनोटेशन स्वीकार करने वाली एक अलग इकाई हो सकती है। इसके विपरीत, एक पीयूटी अनुरोध में यूआरआई अनुरोध के साथ संलग्न इकाई की पहचान करता है - उपयोगकर्ता एजेंट जानता है कि यूआरआई क्या है और सर्वर अनुरोध को किसी अन्य संसाधन पर लागू करने का प्रयास नहीं करता है। यदि सर्वर की इच्छा है कि अनुरोध को एक अलग यूआरआई पर लागू किया जाए, तो उसे 301 (स्थायी रूप से स्थानांतरित) प्रतिक्रिया भेजनी होगी; उपयोगकर्ता एजेंट MAY तब अनुरोध को पुनर्निर्देशित करने या न करने के संबंध में अपना निर्णय लेता है।

इसके अतिरिक्त, और थोड़ा और अधिक संक्षेप में, RFC 7231 धारा 4.3.4 PUT राज्यों (जोर दिया गया),

4.3.4। डाल

PUT विधि अनुरोध करती है कि लक्ष्य संसाधन की स्थिति createdया replacedअनुरोध संदेश पेलोड में संलग्न प्रतिनिधित्व द्वारा परिभाषित राज्य के साथ हो ।

सही विधि का उपयोग करना, एक तरफ असंबंधित:

REST ROA बनाम SOAP का एक लाभ यह है कि HTTP REST ROA का उपयोग करते समय, यह HTTP क्रिया या विधियों के उचित उपयोग को प्रोत्साहित करता है। इसलिए उदाहरण के लिए आप केवल PUT का उपयोग करेंगे जब आप उस सटीक स्थान पर एक संसाधन बनाना चाहते हैं। और आप एक संसाधन बनाने या संशोधित करने के लिए GET का उपयोग कभी नहीं करेंगे।

Comments

मैंने ऐनक में पढ़ा कि If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI। तो PUT का एक कार्यान्वयन जो संसाधन को बनाने से इंकार करता है अगर मौजूद नहीं है तो सही होगा, है ना? यदि हां, तो क्या यह व्यवहार में होता है? या कार्यान्वयन आमतौर पर PUT पर भी बनाते हैं?

— होरक्रोस

कुछ अतिरिक्त अपवाद जो अंतर को बहुत स्पष्ट करते हैं, अगले URL पर है - dzone.com/articles/put-vs-post

— आशीष शेटकर

मुझे समझ में नहीं आ रहा है कि कैसे PUT की शालीनता को लागू किया जाए। सामान्य तौर पर, अधिकांश एपीआई एक नया संसाधन बनाने के मामले में एक आईडी के ऑटो पीढ़ी का उपयोग करेंगे। और PUT में, आपको एक संसाधन बनाना चाहिए, यदि यह मौजूद नहीं है, लेकिन URI में निर्दिष्ट ID का उपयोग करें, लेकिन यदि आप id जनन विधि को स्वचालित होने के लिए सेट करते हैं तो आप यह कैसे कर सकते हैं ???

— बजे रोनी एक्सलराड

तो संक्षेप में: एक पोस्ट अनुरोध में URI उस संसाधन की पहचान करता है जो संलग्न इकाई को संभाल लेगा । एक PUT अनुरोध में URI ही इकाई की पहचान करता है ।

— दाजेन ब्जेलोवुक

पोस्ट विधि के लिए जवाबदेही

— अस्वीकार्य

Answer 2

केवल शब्दार्थ।

एक HTTP PUTको अनुरोध के निकाय को स्वीकार करना है, और फिर उस संसाधन को URI द्वारा पहचाने जाने पर संग्रहीत करना है।

एक HTTP POSTअधिक सामान्य है। यह सर्वर पर एक कार्रवाई शुरू करने वाला है। वह क्रिया URI द्वारा पहचाने गए संसाधन पर अनुरोध निकाय को संग्रहीत करने के लिए हो सकती है, या यह एक भिन्न URI हो सकती है, या यह एक भिन्न क्रिया हो सकती है।

PUT एक फाइल अपलोड की तरह है। एक यूआरआई का पुट यूआरआई को बिल्कुल प्रभावित करता है। एक URI के लिए POST का कोई भी प्रभाव हो सकता है।

Comments

जिसका तात्पर्य है कि एक निश्चित कार्य वास्तव में नहीं हो सकता है

— टेलरमैक

Answer 3

REST- शैली संसाधनों के उदाहरण देने के लिए:

"POST / पुस्तकें" पुस्तक की जानकारी के एक समूह के साथ एक नई पुस्तक बना सकती है, और उस पुस्तक की पहचान करने वाले नए URL के साथ प्रतिक्रिया दे सकती है: "/ books / 5"।

"पीयूटी / किताबें / 5" को या तो 5 की आईडी के साथ एक नई किताब बनानी होगी, या मौजूदा किताब को आईडी 5 से बदलना होगा।

गैर-संसाधन शैली में, POST का उपयोग किसी भी चीज के लिए किया जा सकता है जिसका साइड इफेक्ट होता है। एक अन्य अंतर यह है कि PUT का उपयोग करना चाहिए - एक ही URL पर एक ही डेटा के कई PUT ठीक होने चाहिए, कई POST कई ऑब्जेक्ट बना सकते हैं या जो भी यह आपके POST क्रिया करता है।

Comments

हाय भोली, अगर मैं POST / पुस्तकों / 5 का उपयोग करूँ तो क्या होगा? क्या यह संसाधन नहीं मिला?

— चंगान

मुझे लगता है कि PUT और POST के बीच की सबसे अलग और महत्वपूर्ण अंतर है

— मार्टिन एंडरसन

हाय चंगान, यहाँ एक स्पष्टीकरण है जो विकिपीडिया आपके "POST / पुस्तकों / 5" मामले के बारे में देता है: "आम तौर पर उपयोग नहीं किया जाता है। संबोधित सदस्य को अपने आप में एक संग्रह के रूप में समझें और उसमें एक नई प्रविष्टि बनाएँ।"

— rdiachenko नोव

यह उत्तर यह धारणा देता है कि PUT और POST को एक ही संसाधन पर परिभाषित किया जा सकता है, हालाँकि, idempotency के आगे दूसरा अंतर वह है जो आईडी स्थान को नियंत्रित करता है। PUT में, उपयोगकर्ता एक विशिष्ट ID के साथ संसाधन बनाकर ID स्थान को नियंत्रित कर रहा है। POST में, सर्वर उस ID को लौटा रहा है जिसे उपयोगकर्ता को GET जैसी बाद की कॉल में संदर्भित करना चाहिए। ऊपर अजीब है क्योंकि इसकी दोनों का मिश्रण है।

— टॉमी

Answer 4

1. GET : सर्वर से डेटा प्राप्त करता है। कोई अन्य प्रभाव नहीं होना चाहिए।
2. पोस्ट : एक नई इकाई बनाने के लिए सर्वर को डेटा भेजता है। अक्सर फ़ाइल अपलोड करते समय या वेब फ़ॉर्म सबमिट करते समय उपयोग किया जाता है।
3. PUT : POST के अनुकूल, लेकिन इसका उपयोग मौजूदा इकाई को बदलने के लिए किया जाता है।
4. PATCH : PUT के समान, लेकिन किसी मौजूदा इकाई के भीतर केवल कुछ फ़ील्ड्स को अपडेट करने के लिए उपयोग किया जाता है।
5. DELETE : सर्वर से डेटा हटाता है।
6. TRACE : सर्वर क्या प्राप्त करता है, इसका परीक्षण करने का एक तरीका प्रदान करता है। यह केवल वही भेजता है जो भेजा गया था।
7. विकल्प : किसी ग्राहक को किसी सेवा द्वारा समर्थित अनुरोध विधियों के बारे में जानकारी प्राप्त करने की अनुमति देता है। प्रासंगिक प्रतिक्रिया शीर्षलेख समर्थित विधियों के साथ अनुमति है। सर्वर में वास्तविक अनुरोध विधि के बारे में सूचित करने और कस्टम हेडर के बारे में पूछने के लिए प्रीफ़लाइट अनुरोध के रूप में कॉर्स में भी उपयोग किया जाता है।
8. HEAD : केवल रिस्पॉन्स हेडर लौटाता है।
9. कनेक्ट : ब्राउज़र द्वारा उपयोग किया जाता है जब यह जानता है कि यह प्रॉक्सी से बात करता है और अंतिम यूआरआई https: // से शुरू होता है। कनेक्ट का इरादा एंड-टू-एंड एन्क्रिप्टेड टीएलएस सत्र की अनुमति देना है, इसलिए डेटा प्रॉक्सी के लिए अप्राप्य है।

Comments

सर्वश्रेष्ठ लघु उत्तर

— vibs2006

क्या https का उपयोग करते समय प्रत्येक अनुरोध से पहले कनेक्ट किया गया है?

— चर

Answer 5

PUT का अर्थ किसी विशेष URI के सामान को "अपलोड" करने के लिए एक विधि के रूप में है, या उस URI में पहले से ही ओवरराइटिंग है।

दूसरी ओर, POST किसी दिए गए URI से संबंधित डेटा सबमिट करने का एक तरीका है।

HTTP RFC का संदर्भ लें

Answer 6

जहाँ तक मुझे पता है, PUT का उपयोग ज्यादातर रिकॉर्ड अपडेट करने के लिए किया जाता है।

1. POST - दस्तावेज़ या कोई अन्य संसाधन बनाने के लिए

2. PUT - निर्मित दस्तावेज़ या किसी अन्य संसाधन को अपडेट करने के लिए।

लेकिन यह स्पष्ट होने के लिए कि PUT आमतौर पर मौजूदा रिकॉर्ड को 'रिप्लेस' करता है अगर वह वहां है और बनाता है तो नहीं।

Comments

इस संदर्भ में एक रिकॉर्ड क्या है? सवाल HTTP रिक्वेस्ट को लेकर है।

— किशोर

यदि दस्तावेज़ / संसाधन पहले से मौजूद है तो POST क्या करेगा? यह एक त्रुटि फेंक देंगे, या यह बस ठीक हो जाएगा?

— आदित्य पेडणेकर

मैंने जो पढ़ा है, उसमें से अधिकांश के आधार पर भी बना सकते हैं।

— एड्रॉक्सॉक्स

Answer 7

अन्य लोगों ने पहले ही उत्कृष्ट उत्तर पोस्ट कर दिए हैं, मैं सिर्फ यह जोड़ना चाहता था कि अधिकांश भाषाओं, रूपरेखाओं और उन मामलों का उपयोग करें जिनके साथ आप POST के साथ बहुत अधिक व्यवहार करेंगे, PUT की तुलना में अधिक बार। इस बिंदु पर जहां PUT, DELETE, आदि मूल रूप से सामान्य ज्ञान प्रश्न हैं।

Answer 8

कृपया देखें: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

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

यदि आप RFC 2616 ("हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल - HTTP / 1.1"), धारा 9.6 ("PUT") के पृष्ठ 55 पर एक नज़र डालते हैं , तो आप देखेंगे कि वास्तव में PUT क्या है:

PUT विधि अनुरोध करती है कि संलग्न इकाई आपूर्ति अनुरोध-URI के तहत संग्रहीत की जाए।

POST और PUT के बीच अंतर समझाने के लिए एक आसान पैराग्राफ भी है:

POST और UUT अनुरोधों के बीच मूलभूत अंतर Request-URI के विभिन्न अर्थों में परिलक्षित होता है। POST अनुरोध में URI उस संसाधन की पहचान करता है जो संलग्न इकाई को संभालेगा। वह संसाधन डेटा-स्वीकार करने की प्रक्रिया, कुछ अन्य प्रोटोकॉल का प्रवेश द्वार, या एनोटेशन स्वीकार करने वाली एक अलग इकाई हो सकती है। इसके विपरीत, एक पीयूटी अनुरोध में यूआरआई अनुरोध के साथ संलग्न इकाई की पहचान करता है - उपयोगकर्ता एजेंट जानता है कि यूआरआई क्या है और सर्वर अनुरोध को किसी अन्य संसाधन पर लागू करने का प्रयास नहीं करता है।

यह अद्यतन करने / बनाने के बीच के अंतर के बारे में कुछ भी उल्लेख नहीं करता है, क्योंकि यह ऐसा नहीं है। यह इस बीच के अंतर के बारे में है:

obj.set_attribute(value) # A POST request.

और इस:

obj.attribute = value # A PUT request.

तो कृपया, इस लोकप्रिय गलत धारणा के प्रसार को रोकें। अपने RFC पढ़ें।

Comments

यह कम-से-उपयोगी तरीके से व्यर्थ और कठोर लगता है। PUT के उदाहरण में, आप नई इकाई है, RESTful एपीआई में, 'नया' रिकॉर्ड - और उस स्थान पर सुलभ है। यह संदेहास्पद है कि क्या उप-सदस्यों को अनुमति देने के लिए यह एक अच्छा डिज़ाइन विकल्प है, जैसे कि (मुझे लगता है कि यह आदर्श नहीं है), लेकिन यहां तक ​​कि यह भी था, आप बहुत सारी उपयोगी जानकारी पर हमला करने के लिए उप-प्रजाति का उपयोग कर रहे हैं। अधिकांश समय, जैसा कि आमतौर पर कहा गया है, वर्णन RFC की सामग्री, संक्षेप और सामान्य और प्रथागत अभ्यास दोनों का एक महान कथन है। इसके अलावा, यह आपको विनम्र होने के लिए चोट नहीं पहुँचाएगा।

— टूलूजर

यह पर्याप्त नहीं किया जा सकता है। PUT का REST API में कोई स्थान नहीं है। अधिकांश समय, POST सही शब्दार्थ को इंगित करता है।

— बीफस्टर

अच्छी तरह से नहीं कहा गया है, लेकिन वास्तव में RFC की एक सटीक व्याख्या है। ऐसा लगता है कि वेब डेवलपर दुनिया गलत सूचनाओं का दलदल है।

— विलियम टी फ्रूगार्ड

@Beefster 'POST संकेतक' जैसी कोई चीज नहीं है। नजीबुल ने यहां शानदार प्रदर्शन किया। आप कैसे इंगित करते हैं कि यह क्या इंगित करता है? सिवाय इसके कि आप इसे सिर्फ इसलिए इस्तेमाल करते हैं क्योंकि आपने हमेशा इसे इसी तरह से इस्तेमाल किया है क्योंकि पहले दिन आपने इसे सीखा था, लेकिन वास्तव में यह नहीं जानते कि आपको इसे दूसरों की तुलना में क्यों इस्तेमाल करना चाहिए?

— मोसिया थाबो

Answer 9

एक POST को फैक्ट्री टाइप विधि का कुछ माना जाता है। आप इसके साथ डेटा शामिल करते हैं कि आप क्या चाहते हैं और दूसरे छोर पर जो कुछ भी है वह जानता है कि इसके साथ क्या करना है। किसी दिए गए URL पर मौजूदा डेटा को अपडेट करने के लिए या URI क्या होने जा रहा है, यह जानने के लिए कुछ नया बनाने के लिए PUT का उपयोग किया जाता है और यह पहले से मौजूद नहीं है (एक POST के विपरीत जो कुछ बनाएगा और एक URL लौटाएगा यदि आवश्यक हो)।

Answer 10

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

• सर्वर पर संसाधन बनाने के लिए, POST का उपयोग करें।

• संसाधन प्राप्त करने के लिए, GET का उपयोग करें।

• संसाधन की स्थिति बदलने के लिए या इसे अपडेट करने के लिए, PUT का उपयोग करें।

• किसी संसाधन को हटाने या हटाने के लिए, DELETE का उपयोग करें।

अधिक जानकारी: रेस्टफुल वेब सेवाएं: आईबीएम से मूल बातें

Comments

मुझे लगता है कि आपके पास PUT और POST पीछे है

— Beefster

@Beefster पोस्ट बनाना, अपडेट करना, क्या यह सही है?

— लॉन्ग नगीन

पीयूटी वास्तव में एक यूआरएल पर शाब्दिक सामग्री रखने के लिए है और शायद ही कभी यह एक REST एपीआई में अपनी जगह है। POST अधिक सारगर्भित है और इसमें किसी भी प्रकार की सामग्री जोड़ने को शामिल किया गया है जिसमें "सटीक फ़ाइल को इस सटीक URL पर रखें" का शब्दार्थ नहीं है।

— बीफ़स्टर

Answer 11

एक या दूसरे का उपयोग करते समय यह बहुत सीधा होना चाहिए, लेकिन जटिल शब्दांकन हम में से कई लोगों के लिए भ्रम का स्रोत हैं।

उनका उपयोग कब करें:

• PUTजब आप पहले से ही संसाधन संग्रह का एक हिस्सा है, जो एक विलक्षण संसाधन को संशोधित करना चाहते हैं का उपयोग करें । PUTसंसाधन को संपूर्णता में प्रतिस्थापित करता है। उदाहरण:PUT /resources/:resourceId

  सिडेनोट:PATCH यदि आप संसाधन के एक भाग को अद्यतन करना चाहते हैं तो उपयोग करें ।

---

• POSTजब आप संसाधनों के संग्रह के तहत एक बाल संसाधन जोड़ना चाहते हैं, तो उपयोग करें ।
  उदाहरण:POST => /resources

---

सामान्य रूप में:

• आमतौर पर, व्यवहार में, हमेशा अद्यतन केPUT लिए उपयोग करें ।
• हमेशा क्रिएट संचालन के POSTलिए उपयोग करें ।

---

उदाहरण:

GET / कंपनी / रिपोर्ट => सभी रिपोर्ट
GET / कंपनी / रिपोर्ट / {आईडी} => "आईडी"
POST / कंपनी / रिपोर्ट = द्वारा पहचानी जाने वाली रिपोर्ट जानकारी प्राप्त करें > एक नई रिपोर्ट
PUT / कंपनी / रिपोर्ट / {आईडी} => अपडेट करें "आईडी"
PATCH / कंपनी / रिपोर्ट / {आईडी} = द्वारा पहचानी गई रिपोर्ट जानकारी "आईडी"
DELETE / कंपनी / रिपोर्ट / {आईडी} => "आईडी" से रिपोर्ट हटाएं

Answer 12

POST और PUT के बीच का अंतर यह है कि PUT idempotent है, जिसका अर्थ है, एक ही PUT अनुरोध को कई बार कॉल करना हमेशा एक ही परिणाम उत्पन्न करेगा (यह कोई साइड इफेक्ट नहीं है), जबकि दूसरी ओर, POST अनुरोध को बार-बार कॉल करना पड़ सकता है। कई बार एक ही संसाधन बनाने के अतिरिक्त) दुष्प्रभाव।

GET : GET का उपयोग करने वाले अनुरोध केवल डेटा को पुनः प्राप्त करते हैं, यह निर्दिष्ट संसाधन के प्रतिनिधित्व का अनुरोध करता है

POST: यह संसाधन बनाने के लिए सर्वर को डेटा भेजता है। अनुरोध का मुख्य भाग सामग्री-प्रकार शीर्षलेख द्वारा इंगित किया गया है। यह अक्सर सर्वर पर स्थिति या साइड इफेक्ट में बदलाव का कारण बनता है

PUT : एक नया संसाधन बनाता है या अनुरोध पेलोड के साथ लक्ष्य संसाधन का प्रतिनिधित्व करता है

PATCH : इसका उपयोग किसी संसाधन में आंशिक संशोधन लागू करने के लिए किया जाता है

DELETE : यह निर्दिष्ट संसाधन को हटाता है

TRACE : यह एक उपयोगी डीबगिंग तंत्र प्रदान करते हुए, लक्ष्य संसाधन के मार्ग के साथ एक संदेश लूप-बैक परीक्षण करता है

OPTIONS : इसका उपयोग लक्ष्य संसाधन के लिए संचार विकल्पों का वर्णन करने के लिए किया जाता है, क्लाइंट पूरे सर्वर को संदर्भित करने के लिए विकल्प विधि, या तारांकन (*) के लिए एक URL निर्दिष्ट कर सकता है।

HEAD : यह GET अनुरोध के समान प्रतिक्रिया के लिए कहता है, लेकिन प्रतिक्रिया निकाय के बिना

CONNECT : यह लक्ष्य संसाधन द्वारा पहचाने जाने वाले सर्वर के लिए एक सुरंग स्थापित करता है, इसका उपयोग उन वेबसाइटों तक पहुंचने के लिए किया जा सकता है जो एसएसएल (HTTPS) का उपयोग करते हैं

Answer 13

REST-ful उपयोग

POST एक नया संसाधन बनाने के लिए उपयोग किया जाता है और फिर संसाधन लौटाता है URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

यह कॉल एक नई पुस्तक बना सकती है और उस पुस्तक को लौटा सकती है URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT किसी संसाधन को बदलने के लिए उपयोग किया जाता है, यदि वह संसाधन मौजूद है तो बस उसे अपडेट करें, लेकिन यदि वह संसाधन मौजूद नहीं है, तो उसे बनाएं;

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

साथ PUTहम जानते हैं कि संसाधन पहचानकर्ता है, लेकिन POSTनए संसाधन पहचानकर्ता वापस आ जाएगी

नॉन रेस्ट-फुल उपयोग

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

PUT एक विशिष्ट URL पर शाब्दिक सामग्री को रखने या बदलने के लिए उपयोग किया जाता है

रेस्ट-फुल और नॉन रेस्ट-फुल स्टाइल दोनों में एक और अंतर

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

PUT इम्पोटोटेंट ऑपरेशन है: एक ही अनुरोध के साथ कई बार निष्पादित किए जाने पर इसका कोई दुष्प्रभाव नहीं होगा।

Answer 14

यह उल्लेखनीय होगा कि POSTकुछ सामान्य क्रॉस-साइट रिक्वेस्ट फॉरगेरी (CSRF) हमलों के अधीन है, जबकि PUTऐसा नहीं है।

पीड़ित के आने पर सीएसआरएफ संभव नहीं हैPUTattackersite.com ।

हमले का असर यह है कि शिकार अनजाने किसी उपयोगकर्ता को हटाता सिर्फ इसलिए कि यह (शिकार) लॉग-इन किया गया था के रूप में adminपर target.site.com, जाने से पहले attackersite.com:

सामान्य अनुरोध (कुकीज़ भेजी जाती हैं): ( PUTसमर्थित विशेषता नहीं है)

पर कोड attackersite.com:

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

XHR अनुरोध (कुकीज़ भेजी जाती हैं): ( PUTप्रीफ़लाइट अनुरोध को ट्रिगर करेगा, जिसकी प्रतिक्रिया ब्राउज़र को deleteUserपेज अनुरोध करने से रोक देगी )

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

Answer 15

सरल शब्दों में आप कह सकते हैं:

1.HTTP गेट: इसका उपयोग एक या अधिक आइटम प्राप्त करने के लिए किया जाता है

2.HTTP पोस्ट: इसका उपयोग आइटम बनाने के लिए किया जाता है

3.HTTP पुट: इसका इस्तेमाल किसी आइटम को अपडेट करने के लिए किया जाता है

4.HTTP पैच: इसका उपयोग किसी आइटम को आंशिक रूप से अपडेट करने के लिए किया जाता है

5.HTTP डिलीट: इसका उपयोग किसी आइटम को हटाने के लिए किया जाता है

Answer 16

वास्तव में उनके शीर्षक के अलावा कोई अंतर नहीं है। वास्तव में GET और अन्य के बीच एक बुनियादी अंतर है। "GET" -Request पद्धति के साथ, आप डेटा को url-address-line में भेजते हैं, जिसे पहले प्रश्न-चिह्न से अलग किया जाता है, और फिर & साइन के साथ।

लेकिन "POST" -प्रत्येक विधि से, आप url के माध्यम से डेटा पास नहीं कर सकते हैं, लेकिन आपको अनुरोध के तथाकथित "निकाय" में ऑब्जेक्ट के रूप में डेटा पास करना होगा। सर्वर साइड पर, आपको भेजे गए डेटा को प्राप्त करने के लिए प्राप्त सामग्री के शरीर को पढ़ना होगा। लेकिन शरीर में सामग्री भेजने की कोई दूसरी संभावना नहीं है, जब आप "GET" भेजते हैं।

यह दावा, कि "GET" केवल डेटा प्राप्त करने के लिए है और "POST" डेटा पोस्ट करने के लिए है, बिल्कुल गलत है। कोई भी आपको नई सामग्री बनाने, मौजूदा सामग्री को हटाने, मौजूदा सामग्री को संपादित करने या डेटा के आधार पर बैकएंड में जो कुछ भी कर सकता है, उसे "GET" अनुरोध या "POST" अनुरोध द्वारा भेजा जाता है। और कोई भी आपको बैकएंड को एक तरह से कोड करने से नहीं रोक सकता है, कि "POST" के साथ-साथ, क्लाइंट कुछ डेटा मांगता है।

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

केवल ये दो बुनियादी तरीके हैं। प्राप्त करें और पोस्ट करें। लेकिन यह उनकी संरचना है, जो उन्हें अलग बनाती है और न कि आप बैकएंड में क्या कोड बनाते हैं। बैकएंड में आप जो चाहें प्राप्त कर सकते हैं, प्राप्त आंकड़ों के साथ। लेकिन "POST" के साथ-साथ आपको शरीर में डेटा भेजना / पुनर्प्राप्त करना है और url-addressline में नहीं, और "GET" अनुरोध के साथ, आपको url-addressline में डेटा भेजना / पुनः प्राप्त करना है, न कि शरीर। बस इतना ही।

अन्य सभी विधियाँ, जैसे "PUT", "DELETE" और इसी तरह, उनकी संरचना "POST" जैसी ही है।

POST मेथड का मुख्य रूप से उपयोग किया जाता है, यदि आप कंटेंट को कुछ छिपाना चाहते हैं, क्योंकि आप जो भी url-addressline में लिखते हैं, यह कैश में सेव हो जाएगा और GET-Method डेटा के साथ url-addressline लिखने जैसा ही है। इसलिए यदि आप संवेदनशील डेटा भेजना चाहते हैं, जो हमेशा आवश्यक रूप से उपयोगकर्ता नाम और पासवर्ड नहीं है, लेकिन उदाहरण के लिए कुछ आईडी या हैश, जिसे आप url-address-line में नहीं दिखाना चाहते हैं, तो आपको POST विधि का उपयोग करना चाहिए ।

साथ ही URL-Addressline की लंबाई 1024 प्रतीकों तक सीमित है, जबकि "POST" -Method प्रतिबंधित नहीं है। इसलिए यदि आपके पास बड़ी मात्रा में डेटा है, तो आप इसे GET-Request के साथ भेजने में सक्षम नहीं हो सकते हैं, लेकिन आपको POST-Request का उपयोग करना होगा। इसलिए यह POST-request का एक और प्लस पॉइंट भी है।

लेकिन जब आप भेजने के लिए जटिल पाठ नहीं है, तो GET- अनुरोध के साथ काम करना आसान है। अन्यथा, और यह POST विधि के लिए एक और प्लस पॉइंट है, यह है कि GET-पद्धति के साथ आपको पाठ को url-encode करने की आवश्यकता है, ताकि पाठ या रिक्त स्थान के भीतर कुछ प्रतीकों को भेजने में सक्षम हो सके। लेकिन एक POST पद्धति के साथ आपके पास कोई प्रतिबंध नहीं है और आपकी सामग्री को किसी भी तरह से बदलने या हेरफेर करने की आवश्यकता नहीं है।

Answer 17

PUT और POST दोनों रेस्ट मेथड हैं।

PUT - यदि हम दोनों समयों में समान मापदंडों का उपयोग करके PUT का उपयोग करते हुए दो बार एक ही अनुरोध करते हैं, तो दूसरे अनुरोध का कोई प्रभाव नहीं पड़ेगा। यही कारण है कि PUT का उपयोग आम तौर पर अपडेट परिदृश्य के लिए किया जाता है, एक ही पैरामीटर के साथ एक से अधिक बार अपडेट कॉल करना प्रारंभिक कॉल से अधिक कुछ नहीं करता है इसलिए PUT idempotent है।

उदाहरण के लिए, POST एक आदर्श नहीं है, इसलिए Create दो अलग-अलग प्रविष्टियों को लक्ष्य में बनाएगा, इसलिए यह idempotent नहीं है, इसलिए POST में व्यापक रूप से उपयोग किया जाता है।

हर बार एक ही पैरामीटर के साथ POST का उपयोग करके कॉल करने से दो अलग-अलग चीजें होंगी, इसलिए आमतौर पर POST का उपयोग परिदृश्य बनाने के लिए क्यों किया जाता है