REST में PUT बनाम POST

Question

HTTP / 1.1 के अनुसार युक्ति:

इस POSTविधि का उपयोग यह अनुरोध करने के लिए किया जाता है कि मूल सर्वर अनुरोध में संलग्न इकाई को स्वीकार करता है, जिसके द्वारा पहचाने गए संसाधन के नए अधीनस्थ के रूप में अनुरोध Request-URIकिया गया हैRequest-Line

दूसरे शब्दों में, बनाने केPOST लिए उपयोग किया जाता है ।

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

यही है, बनाने या बदलने के लिएPUT उपयोग किया जाता है ।

तो, संसाधन बनाने के लिए किसका उपयोग किया जाना चाहिए? या किसी को दोनों का समर्थन करने की आवश्यकता है?

Comments

यह HTTPbis में परिभाषाओं का उपयोग करने के लिए सहायक हो सकता है - रॉय ने उन्हें स्पष्ट करने में उचित मात्रा में काम किया। देखें: tools.ietf.org/html/…

— मार्क नॉटिंघम

बस नवीनतम संशोधन के लिए @ मार्कनोटिंघम की टिप्पणी, यहाँ पर POST और PUT लाने के लिए , जैसा कि HTTPbis पर परिभाषित किया गया है।

— मारियस ब्यूटुक

मुझे ऐसा लगता है कि यह बहस CRUD संचालन के संदर्भ में HTTP विधियों का वर्णन करके REST की निगरानी के सामान्य अभ्यास से उत्पन्न हुई है।

— स्टुपॉर्मन

दुर्भाग्य से POST के बारे में पहले उत्तर गलत हैं। अंतरों की बेहतर व्याख्या के लिए मेरे उत्तर की जाँच करें: stackoverflow.com/a/18243587/2458234

— 7hi4g0

PUT और POST दोनों असुरक्षित तरीके हैं। हालांकि, पीयूटी बेमतलब है, जबकि पीओएसटी नहीं है। - और देखें: restcookbook.com/HTTP%20Methods/put-vs-post/…

— दिनेश सैनी

Answer 1

कुल मिलाकर:

PUT और POST दोनों का उपयोग बनाने के लिए किया जा सकता है।

आपको यह पूछना होगा कि "आप किस कार्य को कर रहे हैं?" भेद करने के लिए कि आपको क्या उपयोग करना चाहिए। मान लेते हैं कि आप सवाल पूछने के लिए एपीआई डिजाइन कर रहे हैं। यदि आप POST का उपयोग करना चाहते हैं तो आप उसे प्रश्नों की सूची में करेंगे। यदि आप PUT का उपयोग करना चाहते हैं तो आप एक विशेष प्रश्न के लिए ऐसा करेंगे।

महान दोनों का उपयोग किया जा सकता है, इसलिए मुझे अपने RESTful डिजाइन में किसका उपयोग करना चाहिए:

आपको PUT और POST दोनों का समर्थन करने की आवश्यकता नहीं है।

जो उपयोग किया जाता है वह आपके ऊपर छोड़ दिया जाता है। लेकिन आप अनुरोध में संदर्भित किस वस्तु पर निर्भर करते हुए सही का उपयोग करना याद रखें।

कुछ विचार:

• क्या आप अपने URL ऑब्जेक्ट को स्पष्ट रूप से बनाते हैं, या सर्वर को तय करने देते हैं? अगर आप उनका नाम लेते हैं तो PUT का उपयोग करें। यदि आप सर्वर को तय करने देते हैं तो POST का उपयोग करें।
• पीयूटी एक आदर्श है, इसलिए यदि आप किसी वस्तु को दो बार पीटते हैं, तो इसका कोई प्रभाव नहीं पड़ता है। यह एक अच्छी संपत्ति है, इसलिए मैं जब संभव हो PUT का उपयोग करेगा।
• आप एक ही ऑब्जेक्ट URL के साथ PUT के साथ एक संसाधन को अपडेट या बना सकते हैं
• POST के साथ आपके पास URL में संशोधन करने के लिए एक ही समय में 2 अनुरोध आ सकते हैं, और वे ऑब्जेक्ट के विभिन्न भागों को अपडेट कर सकते हैं।

एक उदाहरण:

मैंने इसके बारे में SO पर एक अन्य उत्तर के भाग के रूप में निम्नलिखित लिखा है :

पद:

एक संसाधन को संशोधित करने और अद्यतन करने के लिए उपयोग किया जाता है

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

ध्यान दें कि निम्नलिखित त्रुटि है:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

यदि URL अभी तक नहीं बना है, तो आपको नाम निर्दिष्ट करते समय इसे बनाने के लिए POST का उपयोग नहीं करना चाहिए। यह 'संसाधन नहीं मिला' त्रुटि के कारण होना चाहिए क्योंकि <new_question>अभी तक मौजूद नहीं है। आपको <new_question> पहले सर्वर पर संसाधन को डालना चाहिए ।

हालाँकि आप POST का उपयोग करके संसाधन बनाने के लिए ऐसा कुछ कर सकते हैं:

POST /questions HTTP/1.1
Host: www.example.com/

ध्यान दें कि इस स्थिति में संसाधन का नाम निर्दिष्ट नहीं है, नई ऑब्जेक्ट URL पथ आपके पास वापस आ जाएगी।

डाल:

एक संसाधन बनाने के लिए उपयोग किया जाता है, या इसे अधिलेखित कर दिया जाता है। जब आप संसाधन नया URL निर्दिष्ट करते हैं।

एक नए संसाधन के लिए:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

मौजूदा संसाधन को अधिलेखित करने के लिए:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

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

4.3.4। डाल

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

Comments

मुझे लगता है कि कोई भी इस तथ्य पर जोर नहीं दे सकता है कि पीयूटी बेकार है: यदि नेटवर्क बॉट किया गया है और ग्राहक को यकीन नहीं है कि क्या उसके अनुरोध के माध्यम से इसे बनाया गया है, तो यह इसे एक दूसरा (या 100 वां) समय भेज सकता है, और इसकी गारंटी है HTTP का अनुमान है कि यह एक बार भेजने के समान ही प्रभाव है।

— जोर्ग डब्ल्यू मित्तग

@ Jörg W Mittag: आवश्यक नहीं। दूसरी बार 409 संघर्ष या कुछ और लौट सकता है यदि इस बीच अनुरोध को संशोधित किया गया हो (किसी अन्य उपयोगकर्ता या पहले अनुरोध के माध्यम से, जो इसके माध्यम से मिला)।

— मित्रा

अगर मैं गलत नहीं हूं, तो हमें जो तनाव होना चाहिए वह यह है कि PUT को बेरोजगार माना जाता है । आपको अभी भी अपने सर्वर को इस तरह से लिखना है कि PUT सही तरीके से व्यवहार करे, हाँ? शायद यह कहना बेहतर है कि "PUT के कारण ट्रांसपोर्टेशन में बेअदबी होती है, जो ट्रांसपोर्ट के व्यवहार को प्रभावित कर सकता है, जैसे कैशिंग।"

— इयान नी-लुईस

@ JörgWMittag Idempotence catchphrase? कैसे के बारे में "भेजें और भेजें और मेरे दोस्त को भेजें, इससे अंत में कोई फर्क नहीं पड़ता।"

— जेम्स बेनिंजर

उनमें से सोचता है: PUT = डालें या अपडेट करें; POST = सम्मिलित करें। इसलिए जब आप दो PUT बनाते हैं - आपको एक नया रिकॉर्ड मिलता है, जब आप दो POST करते हैं - आपको दो नए रिकॉर्ड मिलते हैं।

— यूजेन कोनकोव

Answer 2

आप कहते हैं कि वेब पर दावे पा सकते हैं

• एक संसाधन बनाने के लिए POST का उपयोग किया जाना चाहिए, और एक को संशोधित करने के लिए PUT का उपयोग किया जाना चाहिए
• PUT का उपयोग संसाधन बनाने के लिए किया जाना चाहिए, और POST का उपयोग एक को संशोधित करने के लिए किया जाना चाहिए

न ही काफी सही है।

---

बेहतर के आधार पर रख दिया और पोस्ट के बीच चयन करने के लिए है idempotence कार्रवाई की।

PUT का तात्पर्य एक संसाधन डालकर है - दिए गए URL पर जो भी उपलब्ध है उसे पूरी तरह से अलग चीज़ से बदलना। परिभाषा के अनुसार, एक PUT आलंबनशील है। आप जितनी बार चाहें उतनी बार करें और नतीजा भी वही है। x=5उदासीन है। आप पहले से मौजूद है या नहीं (जैसे, बनाने के लिए, या अद्यतन करने के लिए) एक संसाधन PUT कर सकते हैं!

POST एक संसाधन को अपडेट करता है, एक सहायक संसाधन जोड़ता है, या परिवर्तन का कारण बनता है। एक POST उस तरह x++से नहीं है , जिस तरह से वह बेकार नहीं है।

---

इस तर्क से, PUT बनाने के लिए है जब आप उस चीज़ का URL जानते हैं जिसे आप बनाएंगे। पोस्ट बनाने के लिए POST का उपयोग तब किया जा सकता है जब आप उन चीजों की श्रेणी के लिए "फ़ैक्टरी" या प्रबंधक का URL जानते हैं जिन्हें आप बनाना चाहते हैं।

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929

Comments

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

— जोश

अगर POST किसी संसाधन को अपडेट कर सकता है, तो यह कैसे बेमतलब है? अगर मैं PUT का उपयोग करके छात्रों की आयु को बदल देता हूं और ऐसा करता हूं कि यदि मैंने एक बार किया तो छात्रों की आयु 10 गुना है।

— जैक उलेजा

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

— तोबू

@ श्नाइडर POST एक सहायक संसाधन बना सकता है; इसलिए, आप POST / व्यय-रिपोर्ट की तरह संग्रह कर सकते हैं और यह आपके सर्वर पर आपके द्वारा भेजे गए अनुरोधों की मात्रा के रूप में कई इकाइयां (व्यय रिपोर्ट) बनाएंगे, भले ही वे पूरी तरह समान हों। इसे ऑटो-इंक्रीम्ड प्राइमरी की के साथ DB टेबल (/ व्यय-रिपोर्ट) में एक ही पंक्ति डालने के बारे में सोचें। डेटा एक ही रहता है, कुंजी (इस मामले में यूआरआई) सर्वर द्वारा उत्पन्न होती है और हर दूसरे इंसर्ट (अनुरोध) के लिए अलग होती है। तो, POST का प्रभाव निष्प्रभावी हो सकता है, लेकिन यह भी नहीं हो सकता है। इसलिए, POST बेकार नहीं है ।

— Snifff

मान लीजिए कि हमारे पास ऐसी इकाइयाँ हैं जिनके दो गुण हो सकते हैं - nameऔर date। यदि हमारे पास एक मौजूदा nameऔर के साथ एक इकाई है date, लेकिन फिर इसे केवल एक निर्दिष्ट करने के लिए अनुरोध करें name, PUT का उचित व्यवहार dateइकाई के विरूपित करना होगा , जबकि POST केवल निर्दिष्ट गुणों को अपडेट कर सकता है, अनिर्दिष्ट गुणों को छोड़कर। अनुरोध करने से पहले। क्या यह ध्वनि सही / उचित है, या क्या यह PUT का अनुचित उपयोग है (मैंने PATCH के संदर्भ देखें , जो ऐसा लगता है कि यह अधिक उपयुक्त होगा, लेकिन अभी तक मौजूद नहीं है)?

— जॉन जेड

Answer 3

• URL पर POST एक सर्वर परिभाषित URL पर एक बाल संसाधन बनाता है ।
• एक URL पर PUT ग्राहक परिभाषित URL पर अपनी संपूर्णता में संसाधन बनाता है / बदलता है ।
• PATCH एक यूआरएल को अपडेट हिस्सा संसाधन की है कि ग्राहक द्वारा निर्धारित URL पर।

PUT और POST के लिए प्रासंगिक विनिर्देश RFC 2616 ff9.5ff है।

POST एक बाल संसाधन बनाता है , इसलिए POST /itemsएक संसाधन बनाता है जो संसाधन के अंतर्गत रहता है /items। उदाहरण के लिए। /items/1। एक ही पोस्ट पैकेट को दो बार भेजने से दो संसाधन बनेंगे।

PUT क्लाइंट द्वारा ज्ञात URL पर एक संसाधन बनाने या बदलने के लिए है ।

इसलिए: PUT केवल CREATE के लिए एक उम्मीदवार है जहाँ ग्राहक को संसाधन बनने से पहले ही url का पता चल जाता है। उदाहरण के लिए। /blogs/nigel/entry/when_to_use_post_vs_putजैसा कि शीर्षक का उपयोग संसाधन कुंजी के रूप में किया जाता है

PUT ज्ञात url पर संसाधन को बदलता है यदि यह पहले से मौजूद है, तो एक ही अनुरोध को दो बार भेजने से कोई प्रभाव नहीं पड़ता है। दूसरे शब्दों में, PUT के लिए कॉल बेकार हैं ।

RFC इस तरह पढ़ता है:

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

नोट: PUT का उपयोग ज्यादातर संसाधनों को अपडेट करने के लिए किया गया है (उन्हें संपूर्णता में प्रतिस्थापित करके), लेकिन हाल ही में मौजूदा संसाधनों को अपडेट करने के लिए PATCH का उपयोग करने की दिशा में आंदोलन है, क्योंकि PUT यह निर्दिष्ट करता है कि यह पूरे संसाधन को बदल देता है। आरएफसी 5789।

अपडेट 2018 : एक ऐसा मामला है जो PUT से बचने के लिए बनाया जा सकता है। देखिये "REST बिना PUT"

"आरईएसटी विदाउट पीयूटी" तकनीक के साथ, विचार यह है कि उपभोक्ताओं को नए 'संज्ञा वाले' अनुरोध संसाधनों को पोस्ट करने के लिए मजबूर किया जाता है। जैसा कि पहले चर्चा की गई है, ग्राहक के मेलिंग पते को बदलना एक नए "ChangeOfAddress" संसाधन के लिए एक POST है, न कि एक अलग मेलिंग एड्रेस फ़ील्ड मान के साथ "ग्राहक" संसाधन का एक PUT।

REST एपीआई डिज़ाइन से लिया गया - थॉटवर्क्स के प्रकाश सुब्रमण्यम द्वारा संसाधन मॉडलिंग

यह एपीआई को एक एकल संसाधन को अद्यतन करने वाले कई ग्राहकों के साथ राज्य संक्रमण की समस्याओं से बचने के लिए मजबूर करता है, और इवेंट सोर्सिंग और सीक्यूआरएस के साथ अधिक मेल खाता है। जब काम अतुल्यकालिक रूप से किया जाता है, तो परिवर्तन को पोस्ट करना और इसके लागू होने की प्रतीक्षा करना उचित लगता है।

Comments

या बाड़ के दूसरी तरफ से: यदि ग्राहक सर्वर करता है, तो परिणामस्वरूप संसाधन का पता, पोस्ट को निर्धारित करता है।

— दानमेन

मुझे लगता है कि इस उत्तर को और अधिक स्पष्ट करने के लिए संपादित किया जाना चाहिए @DanMan ने बहुत ही सरल तरीके से बताया। मुझे यहां जो सबसे मूल्यवान लगता है वह है अंत में नोट, जिसमें कहा गया है कि एक PUT का उपयोग केवल पूरे संसाधन को बदलने के लिए किया जाना चाहिए।

— हर्म्स

PATCH कम से कम कुछ वर्षों के लिए एक यथार्थवादी विकल्प नहीं है, लेकिन मैं विचारधारा से सहमत हूं।

— क्रश करें

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

— गैलेक्सीएब्रेटोर

तुम सही हो। एक मौजूदा के रूप में एक ही url पर एक ब्लॉग पोस्ट डालने से उस मौजूदा पोस्ट के लिए एक अद्यतन हो जाएगा (हालांकि आप स्पष्ट रूप से एक GET के साथ पहले जांच कर सकते हैं)। यह इंगित करता है कि URL के रूप में केवल शीर्षक का उपयोग करना एक बुरा विचार क्यों होगा। हालांकि यह कहीं भी काम करेगा डेटा में एक प्राकृतिक कुंजी थी ... जो मेरे अनुभव में दुर्लभ है। या यदि आपने GUIDs

— Nigel Thorne

Answer 4

सारांश:

सृजन करना:

निम्नलिखित तरीके से PUT या POST दोनों के साथ किया जा सकता है:

डाल

बनाता है के साथ नए संसाधन newResourceId / संसाधनों यूआरआई, या के तहत पहचानकर्ता के रूप में, संग्रह ।

PUT /resources/<newResourceId> HTTP/1.1 

पद

/ संसाधन URI, या संग्रह के तहत एक नया संसाधन बनाता है । आमतौर पर पहचानकर्ता सर्वर द्वारा लौटाया जाता है।

POST /resources HTTP/1.1

अपडेट करें:

कर सकते हैं केवल निम्नलिखित तरीके में डाल के साथ किया जाना:

डाल

मौजूदा संसाधन के साथ संसाधन को अद्यतन करता है पहचानकर्ता के रूप में / संसाधन URI, या संग्रह के तहत ।

PUT /resources/<existingResourceId> HTTP/1.1

स्पष्टीकरण:

जब बाकी और यूआरआई जनरल के रूप में साथ काम कर, आप सामान्य पर छोड़ दिया और विशिष्ट पर सही । जेनरिक आमतौर पर कहा जाता है संग्रह और अधिक विशिष्ट आइटम कहा जा सकता है संसाधन । ध्यान दें कि एक संसाधन में एक संग्रह हो सकता है ।

उदाहरण:

<- सामान्य - विशिष्ट ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

जब आप POST का उपयोग करते हैं तो आप हमेशा एक संग्रह का उल्लेख करते हैं , इसलिए जब भी आप कहते हैं:

POST /users HTTP/1.1

आप उपयोगकर्ता संग्रह में एक नया उपयोगकर्ता पोस्ट कर रहे हैं ।

यदि आप आगे बढ़ते हैं और कुछ इस तरह की कोशिश करते हैं:

POST /users/john HTTP/1.1

यह काम करेगा, लेकिन शब्दार्थ आप कह रहे हैं कि आप उपयोगकर्ताओं के संग्रह के तहत जॉन संग्रह में एक संसाधन जोड़ना चाहते हैं ।

एक बार जब आप PUT का उपयोग कर रहे हैं तो आप एक संसाधन या एकल आइटम का उल्लेख कर रहे हैं , संभवतः एक संग्रह के अंदर । तो जब आप कहते हैं:

PUT /users/john HTTP/1.1

आप सर्वर अद्यतन के लिए कह रहे हैं, या बना सकते हैं यदि यह मौजूद नहीं है, तो उपयोगकर्ता संग्रह के तहत जॉन संसाधन ।

युक्ति:

मुझे कल्पना के कुछ महत्वपूर्ण हिस्सों को उजागर करने दें:

पद

पोस्ट विधि अनुरोध करने के लिए प्रयोग किया जाता है कि मूल सर्वर स्वीकार इकाई एक के रूप में अनुरोध में संलग्न नई अधीनस्थ संसाधन अनुरोध लाइन में अनुरोध- URI द्वारा की पहचान की

इसलिए, एक संग्रह पर एक नया संसाधन बनाता है ।

डाल

PUT विधि अनुरोध करता है कि संलग्न इकाई जा संग्रहीत आपूर्ति अनुरोध- URI के तहत। यदि अनुरोध-URI पहले से मौजूद संसाधन को संदर्भित करता है , तो संलग्न इकाई SHOULD को मूल सर्वर पर रहने वाले एक के संशोधित संस्करण के रूप में माना जाना चाहिए । अनुरोध- URI है, तो एक मौजूदा को इंगित नहीं संसाधन, और यूआरआई है कि सक्षम एक के रूप में परिभाषित किया जा रहा है नए संसाधन का अनुरोध उपयोगकर्ता एजेंट द्वारा, मूल सर्वर कर सकते हैं बनाने कि यूआरआई के साथ संसाधन। "

इसलिए, संसाधन के अस्तित्व के आधार पर बनाएं या अपडेट करें ।

संदर्भ:

• HTTP / 1.1 विशेष
• विकिपीडिया - REST
• यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI): जेनेरिक सिंटैक्स और शब्दार्थ

Comments

यह पोस्ट यह समझने में मेरे लिए मददगार थी कि POST दिए गए संग्रह (URI) में एक बच्चे के रूप में "कुछ" जोड़ता है, जबकि PUT दिए गए URI स्थान पर "कुछ" को स्पष्ट रूप से परिभाषित करता है।

— kwah

यह सबसे अच्छा जवाब है, यहां, मुझे लगता है: इसमें से कोई भी "POST एक संसाधन को अपडेट कर सकता है" बकवास। मुझे आपका कथन पसंद है, "अपडेट केवल PUT के साथ किया जा सकता है"।

— थॉमस

नहीं, PUT अद्यतन या बनाने के लिए नहीं है। यह बदलने के लिए है। ध्यान दें कि आप बनाने के प्रभाव के लिए कुछ के साथ कुछ नहीं बदल सकते हैं।

— Thecoshman

@ 7hi4g0 PUT पूर्ण प्रतिस्थापन के साथ अद्यतन करने के लिए है, दूसरे शब्दों में, यह प्रतिस्थापित करता है। आप कुछ के साथ कुछ नहीं की जगह, या कुछ के साथ पूरी तरह से नया कुछ। PUT एक मामूली परिवर्तन करने के लिए नहीं है (जब तक कि आपके पास ग्राहक नहीं है, तब तक वह मामूली परिवर्तन करें और पूरे नए संस्करण को प्रदान करें, यहां तक ​​कि जो शेष है वही)। आंशिक संशोधन के लिए, PATCH पसंद का तरीका है।

— Thecoshman 12

@thecoshman आप कर सकते हैं, लेकिन यह भी स्पष्ट नहीं होगा कि बनाने में भी शामिल है। इस मामले में, स्पष्ट होना बेहतर है।

— 7hi4g0

Answer 5

POST इसका अर्थ है "नया बनाएं" जैसा कि "यहां उपयोगकर्ता बनाने के लिए इनपुट है, इसे मेरे लिए बनाएं"।

PUT का अर्थ है "सम्मिलित करें, प्रतिस्थापित करें यदि पहले से मौजूद है" जैसा कि "यहां उपयोगकर्ता 5 के लिए डेटा है"।

आप POSTexample.com/users के बाद से आप URLउपयोगकर्ता के बारे में अभी तक नहीं जानते हैं , आप चाहते हैं कि सर्वर इसे बनाए।

आप PUTexample.com/users/id है क्योंकि आप की जगह / एक बनाना चाहते हैं विशिष्ट उपयोगकर्ता।

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

एक सामान्य सलाह यह है कि POSTजब आपको सर्वर को URLअपने संसाधनों की पीढ़ी के नियंत्रण में रखने की आवश्यकता हो, तो इसका उपयोग करें। PUTअन्यथा उपयोग करें । पसंद करते हैं PUT अधिक POST।

Comments

धीमेपन के कारण यह आमतौर पर सिखाया जा सकता है कि केवल दो क्रियाएं हैं जिनकी आपको आवश्यकता है: GET और POST। प्राप्त करने के लिए, परिवर्तन के लिए POST प्राप्त करें। यहां तक ​​कि PUT और DELETE को POST का उपयोग करके प्रदर्शन किया गया था। यह पूछने पर कि वास्तव में 25 साल बाद PUT का क्या मतलब है, एक संकेत है कि हमने पहले इसे गलत सीखा था। REST की लोकप्रियता ने लोगों को उन मूल बातों पर वापस भेज दिया जहां हमें अब पिछली गलत गलतियों को अनजान करना होगा। POST का अत्यधिक उपयोग किया गया और अब आमतौर पर गलत तरीके से पढ़ाया जाता है। सबसे अच्छा हिस्सा: "एक ही डेटा के साथ दो बार पोस्ट करने का मतलब है दो समान [संसाधन] बनाना"। महान बिंदु!

— मैक्सपूल

user 5यदि आप अभी तक मौजूद नहीं हैं , तो आप आईडी द्वारा रिकॉर्ड बनाने के लिए PUT का उपयोग कैसे कर सकते हैं ? क्या आपका मतलब नहीं है update, replace if already exists? या कुछ और

— ल्यूक

@ कोल्टन: मेरा मतलब है कि मैंने क्या लिखा है। यदि आप PUT / users / 5 और # 5 मौजूद नहीं हैं, तो आप उपयोगकर्ता 5 डालें।

— अलेक्जेंडर टॉर्टलिंग

@ कोल्टन: और PUTइसका उपयोग मौजूदा संसाधन के मूल्य को उसकी संपूर्णता में बदलने के लिए भी किया जा सकता है ।

— डेविड आरआर

"POST पर अधिक ध्यान दें" ... इसका औचित्य साबित करने के लिए परवाह है?

— Thecoshman

Answer 6

मैं अपनी "व्यावहारिक" सलाह जोड़ना चाहूंगा। PUT का उपयोग करें जब आप "id" जानते हैं जिसके द्वारा आप जिस ऑब्जेक्ट को सेव कर रहे हैं उसे पुनः प्राप्त किया जा सकता है। यदि आपको ज़रूरत है तो PUT का उपयोग करना बहुत अच्छा नहीं होगा, कहते हैं, एक डेटाबेस जनरेट आईडी आपको भविष्य के लुकअप या अपडेट करने के लिए लौटाया जाएगा।

तो: किसी मौजूदा उपयोगकर्ता को बचाने के लिए, या जहां ग्राहक आईडी बनाता है और यह सत्यापित किया गया है कि आईडी अद्वितीय है:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

अन्यथा, शुरू में ऑब्जेक्ट बनाने के लिए POST का उपयोग करें, और ऑब्जेक्ट को अपडेट करने के लिए PUT:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

Comments

वास्तव में, यह होना चाहिए POST /users। (ध्यान दें कि /usersयह बहुवचन है।) इसमें एक नया उपयोगकर्ता बनाने और इसे /usersसंग्रह का बाल संसाधन बनाने का प्रभाव है ।

— डेविड आरआर

@DavidRR निष्पक्ष होना, समूहों को कैसे संभालना है यह पूरी तरह से एक और बहस है। GET /usersसमझ में आता है, जैसा आप चाहते हैं, यह पढ़ता है, लेकिन मैं (नए उपयोगकर्ता के लिए पेलोड के साथ) ठीक हूं GET /user/<id>या नहीं, POST /userक्योंकि यह सही ढंग से पढ़ता है 'मुझे उपयोगकर्ता 5 प्राप्त करें' अजीब है, लेकिन 'मुझे उपयोगकर्ता 5 प्राप्त करें' अधिक स्वाभाविक है। मैं शायद अभी भी बहुवचन के पक्ष में नीचे गिर

— जाऊँगा

Answer 7

बनाने के लिए POST का उपयोग करें, और अपडेट करने के लिए PUT करें। वैसे भी रूबी रेल्स पर यह कर रही है।

PUT    /items/1      #=> update
POST   /items        #=> create

Comments

POST /itemsपहले से परिभाषित संसाधन ('आइटम') में एक नया आइटम जोड़ता है। ऐसा नहीं है, जैसा कि उत्तर कहता है, "एक समूह बनाएं।" मुझे समझ में नहीं आता कि इसके 12 वोट क्यों हैं।

— डेविड जे।

बॉक्स से बाहर, रेल REST के माध्यम से 'एक समूह बनाने' का समर्थन नहीं करता है। 'एक समूह' बनाने के लिए जिसके द्वारा मेरा मतलब है 'एक संसाधन बनाएँ' आपको इसे स्रोत कोड के माध्यम से करना होगा।

— डेविड जे।

यह एक उचित दिशानिर्देश है, लेकिन एक निरीक्षण है। जैसा कि अन्य उत्तर में उल्लेख किया गया है, या तो विधि का उपयोग निर्माण और अद्यतन दोनों के लिए किया जा सकता है।

— ब्राड कोच

मैं एक मामूली संशोधन के साथ जवाब से सहमत हूं। बनाने के लिए POST का उपयोग करें और संसाधन को पूरी तरह से अपडेट करने के लिए PUT करें। आंशिक अपडेट के लिए, हम PUT या PATCH का उपयोग कर सकते हैं। आइए हम एक समूह की स्थिति को अपडेट करना चाहते हैं। हम PUT / समूहों / 1 / स्थिति का उपयोग कर सकते हैं स्थिति पेलोड या PATCH / समूहों / 1 के साथ स्थिति है पेलोड में कार्रवाई के बारे में विवरण के साथ

— java_geek

यह भी स्पष्ट किया जाना चाहिए कि संसाधन बनाने केPUT /items/42 लिए भी मान्य है , लेकिन केवल अगर ग्राहक को संसाधन के नामकरण का विशेषाधिकार है । (क्या रेल ग्राहक को इस नामकरण के विशेषाधिकार की अनुमति देता है?)

— डेविड आरआर

Answer 8

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

सादृश्य:

• PUT यानी लेना और डाल जहां यह था।
• डाकघर में डाक के रूप में पोस्ट ।

सोशल मीडिया / नेटवर्क सादृश्य:

• पदसोशल मीडिया पर : जब हम संदेश पोस्ट करते हैं, तो यह नई पोस्ट बनाता है।
• हमारे द्वारा पहले से पोस्ट किए गए संदेश के लिए (यानी संपादित करें) रखो ।

Comments

@MobileMon नहीं, अन्य तरीके CRUD नहीं हैं।

— 19

मैं कहूंगा कि पर्ट्स फॉर यूपीएसईआरटीएस

— होला

@MobileMon no: POST जब आप एक नया संसाधन बनाते हैं और आप इसे प्राप्त करने के लिए अंतिम समापन बिंदु नहीं जानते हैं। अन्य मामलों के लिए पीयूटी।

— पोर्टेकोई

Answer 9

REST एक बहुत ही उच्च-स्तरीय अवधारणा है। वास्तव में, यह भी HTTP का उल्लेख नहीं करता है!

यदि आपको HTTP में REST को लागू करने के बारे में कोई संदेह है, तो आप हमेशा एटम प्रकाशन प्रोटोकॉल (AtpPD) पर एक नज़र डाल सकते हैं विनिर्देश । AtomPub HTTP के साथ Restful webservices लिखने के लिए एक मानक है जो कई HTTP और REST ल्यूमिनरीज़ द्वारा विकसित किया गया था, रॉय फील्डिंग के कुछ इनपुट के साथ, REST के आविष्कारक और स्वयं HTTP के सह-आविष्कारक हैं।

वास्तव में, आप भी सीधे AtomPub का उपयोग करने में सक्षम हो सकते हैं। हालांकि यह ब्लॉगिंग समुदाय से बाहर आया, यह ब्लॉगिंग के लिए किसी भी तरह से प्रतिबंधित नहीं है: यह HTTP के माध्यम से मनमाने संसाधनों के मनमाने (नेस्टेड) ​​संग्रह के साथ बातचीत करने के लिए एक सामान्य प्रोटोकॉल है। यदि आप संसाधनों के एक नेस्टेड संग्रह के रूप में अपने आवेदन का प्रतिनिधित्व कर सकते हैं, तो आप बस एटमपब का उपयोग कर सकते हैं और इस बारे में चिंता न करें कि क्या पीयूटी या पीओटीएस का उपयोग करना है, क्या लौटने के लिए HTTP स्थिति कोड और उन सभी विवरण।

संसाधन निर्माण (खंड 9.2) के बारे में एटमपुब का यही कहना है:

सदस्यों को एक संग्रह में जोड़ने के लिए, ग्राहक संग्रह के URI को POST अनुरोध भेजते हैं।

Comments

PUT को संसाधन बनाने की अनुमति देने में कुछ भी गलत नहीं है। बस इस बात से अवगत रहें कि इसका अर्थ है कि ग्राहक URL प्रदान करता है।

— जूलियन रेसचेक

PUT को संसाधन बनाने की अनुमति देने में कुछ गड़बड़ है: क्लाइंट URL प्रदान करता है। यही सर्वर का काम है!

— जोशोड्स

@ जोशकोड्स हमेशा ऐसा नहीं होता है कि क्लाइंट आईडी बनाना सर्वर का काम है। मैंने तेजी से देखे जाने वाले डिजाइनों को देखा है जो ग्राहकों को संसाधन आईडी के रूप में यूयूआईडी के कुछ प्रकार उत्पन्न करते हैं। यह डिजाइन पैमाने को बढ़ाने के लिए विशेष रूप से उधार देता है।

— जस्टिन

@JustinOhms मैं क्लाइंट जनरेटेड आईडी के बारे में आपकी बात से सहमत हूं (साइड नोट: लगभग 2008 के बाद से मेरे द्वारा डिज़ाइन की गई सभी प्रणालियों को क्लाइंट को यूयूआईडी / गाइड के रूप में आईडी बनाने की आवश्यकता है)। इसका मतलब यह नहीं है कि क्लाइंट को URL निर्दिष्ट करना चाहिए।

— जोशकोड्स

हां, यदि संसाधन पहले से मौजूद है, तो PUT का उपयोग करें। हालाँकि, लगभग सभी मामलों में, संसाधन POST के साथ बनाए जाने चाहिए और क्लाइंट को URL प्रदान नहीं करना चाहिए। रॉय फील्डिंग इस कथन से सहमत हैं: FWIW: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

— Joshcodes

Answer 10

HTTP + REST API वाले सर्वर पर संसाधन बनाने के लिए PUT या POST का उपयोग करने का निर्णय URL संरचना के मालिक के आधार पर है। ग्राहक को पता है, या परिभाषित करने में भाग लेने के बाद, URL संरचना एसओए से उत्पन्न अवांछनीय कपलिंग के लिए एक अनावश्यक युग्मन है। इस प्रकार के कपलिंगों को बचाना रीस्ट इतना लोकप्रिय है। इसलिए, उपयोग करने का उचित तरीका POST है। इस नियम के अपवाद हैं और वे तब होते हैं जब ग्राहक संसाधनों के स्थान संरचना पर नियंत्रण बनाए रखना चाहता है। यह दुर्लभ है और संभावना है कि कुछ और गलत है।

इस बिंदु पर कुछ लोग तर्क देंगे कि यदि Restful-URL का उपयोग किया जाता है, तो ग्राहक संसाधन के URL को जानता है और इसलिए एक PUT स्वीकार्य है। आखिरकार, यही कारण है कि कैनोनिकल, सामान्यीकृत, रूबी ऑन रेल्स, Django यूआरएल महत्वपूर्ण हैं, ट्विटर एपीआई को देखें ... ब्ला ब्ला ब्ला। उन लोगों को यह समझने की जरूरत है कि रेस्टफुल-यूआरएल जैसी कोई चीज नहीं है और रॉय फील्डिंग खुद कहते हैं कि :

REST API को निश्चित संसाधन नाम या पदानुक्रम (क्लाइंट और सर्वर का स्पष्ट युग्मन) को परिभाषित नहीं करना चाहिए। नौकरों को अपने स्वयं के नामस्थान को नियंत्रित करने की स्वतंत्रता होनी चाहिए। इसके बजाय, सर्वरों को क्लाइंट को यह निर्देश देने की अनुमति दें कि मीडिया के प्रकारों और लिंक संबंधों के भीतर उन निर्देशों को परिभाषित करके, उपयुक्त यूआरआई का निर्माण कैसे करें, जैसे कि HTML फॉर्म और यूआरआई टेम्प्लेट में किया जाता है। [यहाँ असफलता का तात्पर्य है कि क्लाइंट्स एक डोमेन-विशिष्ट मानक, जो कि RPC के कार्यात्मक युग्मन के बराबर डेटा-उन्मुख है) के रूप में बैंड की जानकारी के कारण एक संसाधन संरचना मान रहे हैं।

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

RESTful-URL का विचार वास्तव में REST का उल्लंघन है क्योंकि सर्वर URL संरचना का प्रभारी है और इसे युग्मन से बचने के लिए इसका उपयोग करने का निर्णय लेने के लिए स्वतंत्र होना चाहिए। यदि यह भ्रमित करता है तो आप एपीआई डिजाइन पर स्वयं की खोज के महत्व के बारे में पढ़ते हैं।

संसाधनों का निर्माण करने के लिए POST का उपयोग करना एक डिजाइन विचार के साथ आता है क्योंकि POST एक आदर्श नहीं है। इसका मतलब यह है कि कई बार POST दोहराने से हर बार समान व्यवहार की गारंटी नहीं होती है। यह लोगों को PUT का उपयोग करने के लिए संसाधनों को बनाने में डराता है जब उन्हें नहीं करना चाहिए वे जानते हैं कि यह गलत है (POST CREATE के लिए है) लेकिन वे इसे वैसे भी करते हैं क्योंकि वे नहीं जानते कि इस समस्या को कैसे हल किया जाए। इस चिंता को निम्न स्थिति में प्रदर्शित किया जाता है:

1. क्लाइंट सर्वर के लिए एक नया संसाधन पोस्ट करता है।
2. सर्वर अनुरोध को संसाधित करता है और प्रतिक्रिया भेजता है।
3. क्लाइंट को कभी भी प्रतिक्रिया नहीं मिलती है।
4. सर्वर इस बात से अनजान है कि ग्राहक को प्रतिक्रिया नहीं मिली है।
5. ग्राहक के पास संसाधन के लिए URL नहीं है (इसलिए PUT एक विकल्प नहीं है) और POST को दोहराता है।
6. POST एक आदर्श और सर्वर नहीं है ...

चरण 6 वह जगह है जहां लोग आमतौर पर भ्रमित होते हैं कि क्या करना है। हालाँकि, इस समस्या को हल करने के लिए एक कीचड़ बनाने का कोई कारण नहीं है। इसके बजाय, HTTP का उपयोग RFC 2616 में निर्दिष्ट किया जा सकता है और सर्वर जवाब देता है:

10.4.10 409 संघर्ष

संसाधन की वर्तमान स्थिति के साथ विरोध के कारण अनुरोध पूरा नहीं किया जा सका। इस कोड को केवल उन स्थितियों में अनुमति दी जाती है जहां यह उम्मीद की जाती है कि उपयोगकर्ता संघर्ष को हल करने में सक्षम हो सकता है और अनुरोध को फिर से शुरू कर सकता है। प्रतिक्रिया निकाय SHOULD में पर्याप्त शामिल हैं

उपयोगकर्ता के लिए संघर्ष के स्रोत को पहचानने के लिए जानकारी। आदर्श रूप से, प्रतिक्रिया इकाई में समस्या को ठीक करने के लिए उपयोगकर्ता या उपयोगकर्ता एजेंट के लिए पर्याप्त जानकारी शामिल होगी; हालाँकि, यह संभव नहीं हो सकता है और इसकी आवश्यकता नहीं है।

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

409 के स्टेटस कोड के साथ उत्तर देना सही विरोध है क्योंकि :

• एक POST डेटा का प्रदर्शन करना जिसके पास एक ID है जो सिस्टम में पहले से मौजूद एक संसाधन से मेल खाता है, "संसाधन की वर्तमान स्थिति के साथ संघर्ष है।"
• चूंकि क्लाइंट के पास सर्वर को समझने के लिए और उचित कार्रवाई करने के लिए महत्वपूर्ण हिस्सा है। यह एक "स्थिति (स्थिति) है जहां यह उम्मीद की जाती है कि उपयोगकर्ता संघर्ष को हल करने और अनुरोध को फिर से शुरू करने में सक्षम हो सकता है।"
• एक प्रतिक्रिया जिसमें परस्पर विरोधी आईडी के साथ संसाधन का URL होता है और संसाधन के लिए उपयुक्त पूर्व शर्त "समस्या को ठीक करने के लिए उपयोगकर्ता या उपयोगकर्ता एजेंट के लिए पर्याप्त जानकारी" प्रदान करेगा जो कि RFC 2616 के अनुसार आदर्श मामला है।

2616 को बदलने के लिए RFC 7231 के रिलीज़ पर आधारित अपडेट

RFC 7231 को 2616 को बदलने के लिए डिज़ाइन किया गया है और धारा 4.3.3 में POST के लिए संभावित प्रतिक्रिया का वर्णन किया गया है

यदि किसी POST को संसाधित करने का परिणाम मौजूदा संसाधन के प्रतिनिधित्व के बराबर होगा, तो एक मूल सर्वर स्थान फ़ील्ड में मौजूदा संसाधन के पहचानकर्ता के साथ 303 (अन्य देखें) प्रतिक्रिया भेजकर उपयोगकर्ता एजेंट को उस संसाधन पर पुनर्निर्देशित करता है। यह उपयोगकर्ता एजेंट को एक संसाधन पहचानकर्ता प्रदान करने और साझा कैशिंग के लिए अधिक उत्तरदायी के माध्यम से प्रतिनिधित्व को स्थानांतरित करने का लाभ है, हालांकि उपयोगकर्ता एजेंट के पास पहले से ही प्रतिनिधित्व नहीं होने पर अतिरिक्त अनुरोध की कीमत पर।

अब यह केवल एक घटना है कि एक POST दोहराया जाता है में एक 303 वापस करने के लिए आकर्षक हो सकता है। हालांकि, विपरीत सच है। यदि कोई एकाधिक अनुरोध करता है (विभिन्न संसाधन बना रहा है) एक ही सामग्री लौटाता है, तो 303 लौटना केवल तभी समझ में आएगा। एक उदाहरण "आपके अनुरोध संदेश को सबमिट करने के लिए धन्यवाद" होगा जो क्लाइंट को प्रत्येक बार फिर से डाउनलोड करने की आवश्यकता नहीं है। RFC 7231 अभी भी 4.2.2 की धारा में बना हुआ है कि POST को बेरोजगार नहीं करना है और इस बात को बनाए रखना है कि POST का उपयोग करना चाहिए।

इसके बारे में अधिक जानकारी के लिए, इस लेख को पढ़ें ।

Comments

क्या 409 संघर्ष प्रतिक्रिया कुछ के लिए उपयुक्त कोड होगा जैसे कि पहले से मौजूद उपयोगकर्ता नाम के साथ एक नया खाता बनाने की कोशिश करना? मैं विशेष रूप से विरोधाभासों के संस्करण के लिए 409 का उपयोग कर रहा हूं, लेकिन आपके उत्तर को पढ़ने के बाद, मुझे आश्चर्य है कि क्या इसे किसी "डुप्लिकेट" अनुरोधों के लिए उपयोग नहीं किया जाना चाहिए।

— एरिक बी।

@EricB। हां, जिस स्थिति में आप "संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण" का वर्णन करते हैं, ऑपरेशन विफल हो जाता है। इसके अतिरिक्त, यह अपेक्षा करना उचित है कि उपयोगकर्ता संघर्ष को हल कर सकता है और संदेश निकाय को केवल उस उपयोगकर्ता को सूचित करना होगा जो उपयोगकर्ता नाम पहले से मौजूद है।

— जोशोड्स

@ जोशकोड आप संघर्ष समाधान प्रक्रिया के बारे में अधिक कह सकते हैं? इस स्थिति में, यदि उपयोगकर्ता नाम पहले से मौजूद है, तो क्या ग्राहक को एक अलग उपयोगकर्ता नाम के लिए उपयोगकर्ता को संकेत देने की उम्मीद है? क्या होगा यदि क्लाइंट वास्तव में उपयोगकर्ता नाम बदलने के लिए POST का उपयोग करने की कोशिश कर रहा है? क्या PUT अनुरोधों को अभी भी मापदंडों को अपडेट करने के लिए उपयोग किया जाना चाहिए, जबकि POST का उपयोग वस्तुओं को बनाने के लिए किया जाता है चाहे वह एक समय में हो या कई हो? धन्यवाद।

— BFar

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

— जोशकोड्स

छोटी और प्रभावी भाषा का उपयोग करते हुए चीजों की व्याख्या करना भी एक वांछनीय कौशल है

— Junchen लियू

Answer 11

मुझे यह सलाह पसंद है, RFC 2616 की PUT की परिभाषा से :

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

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

मैं इसका मतलब है, और PUT पर आलस्य आवश्यकताओं, मतलब है कि:

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

Comments

"POST का उपयोग मौजूदा वस्तुओं के लिए नॉन-इम्पोटेंट अपडेट के लिए भी किया जा सकता है (विशेष रूप से, पूरी चीज़ को निर्दिष्ट किए बिना किसी ऑब्जेक्ट का हिस्सा बदलना" यही तो PATCH के लिए है

— Snuggs

Answer 12

संक्षेप में:

PUT वैसा ही है, जहां एक ही ऑपरेशन को एक बार या कई बार अंजाम देने पर रिसोर्स स्टेट एक जैसा होगा।

POST नॉन-इम्पोटेंट है, जहाँ एक ही बार निष्पादित करने की तुलना में यदि ऑपरेशन को कई बार निष्पादित किया जाता है, तो संसाधन स्थिति भिन्न हो सकती है।

डेटाबेस क्वेरी के साथ सादृश्य

PUT आप "UPDATE STUDENT SET एड्रेस =" abc "जहां id =" 123 "के समान सोच सकते हैं;

पद आप "INSERT INTO STUDENT (नाम, पता) VALUES (" abc "," xyzzz ") जैसा कुछ सोच सकते हैं;

स्टूडेंट आईडी ऑटो जनरेट होती है।

PUT के साथ, यदि एक ही क्वेरी को कई बार या एक बार निष्पादित किया जाता है, तो छात्र तालिका स्थिति समान रहती है।

POST के मामले में, यदि एक ही क्वेरी को कई बार निष्पादित किया जाता है, तो डेटाबेस में कई छात्र रिकॉर्ड बनते हैं और "INSERT" क्वेरी के प्रत्येक निष्पादन पर डेटाबेस स्थिति बदल जाती है।

नोट: PUT को एक संसाधन स्थान (पहले से-संसाधन) की आवश्यकता होती है, जिस पर अद्यतन होने की आवश्यकता होती है, जबकि POST की आवश्यकता नहीं होती है। इसलिए सहज रूप से POST एक नए संसाधन के निर्माण के लिए है, जबकि पहले से मौजूद संसाधन को अपडेट करने के लिए PUT की आवश्यकता है।

कुछ ऐसे अपडेट आ सकते हैं जिन्हें POST के साथ अपडेट किया जा सकता है। कोई भी कठोर नियम नहीं है, जिसे अपडेट के लिए उपयोग करना है या जिसे बनाने के लिए उपयोग करना है। फिर से ये कन्वेंशन हैं, और सहज रूप से मैं ऊपर बताए गए तर्क के साथ झुका हूं और इसका पालन कर रहा हूं।

Comments

के लिए PUT के समान है सम्मिलित या अपडेट करें क्वेरी

— यूजेन Konkov

वास्तव में PUT आप "UPDATE STUDENT SET एड्रेस =" abc "जहां id =" 123 "के समान हो सकता है, PATCH के लिए एक स्टेटमेंट होगा।" UPDATE STUDENT SET एड्रेस = "abc", name = "newname" जहाँ id = " 123 "PUT के लिए एक सही सादृश्य होगा

— mko

पुट का इस्तेमाल INSERT के लिए भी किया जा सकता है। उदाहरण के लिए यदि आपको पता चला है कि आप एक ही फाइल को कई बार अपलोड करने की कोशिश कर रहे हैं, तो यह आपके अनुरोध को बेकार कर देगा। (कोई नई फ़ाइल अपलोड नहीं हुई है)।

— kiwicomb123

Answer 13

POST एक मेलबॉक्स में एक पत्र पोस्ट करने या एक ईमेल कतार में एक ईमेल पोस्ट करने जैसा है। जब आप किसी घन छेद में एक वस्तु या एक शेल्फ पर एक जगह डालते हैं तो पीयूटी ऐसा होता है (इसका एक ज्ञात पता है)।

POST के साथ, आप QUEUE या COLLECTION के पते पर पोस्ट कर रहे हैं। PUT के साथ, आप ITEM के पते पर रख रहे हैं।

PUT सुस्पष्ट है। आप 100 बार अनुरोध भेज सकते हैं और इससे कोई फर्क नहीं पड़ेगा। POST एक आदर्श नहीं है। यदि आप अनुरोध 100 बार भेजते हैं, तो आपको अपने डाक बॉक्स में 100 ईमेल या 100 पत्र मिलेंगे।

एक सामान्य नियम: यदि आप आइटम का आईडी या नाम जानते हैं, तो PUT का उपयोग करें। यदि आप चाहते हैं कि प्राप्त करने वाले पक्ष द्वारा आईडी या आइटम का नाम सौंपा जाए, तो POST का उपयोग करें।

Comments

नहीं, PUT का अर्थ है कि आप URL जानते हैं। यदि आप केवल आईडी जानते हैं तो URL प्राप्त करने के लिए उस आईडी के साथ पोस्ट करें।

— जोशकोड्स

आईडी URL का हिस्सा है, इसलिए हां, यदि आप URL जानते हैं (जिसमें आईडी शामिल है) तो PUT का उपयोग करें।

— होमर 6

नहीं, URL सर्वर द्वारा निर्धारित किया गया है और आईडी जरूरी नहीं कि URL का हिस्सा है। रॉय फील्डिंग आपको वही बताएंगे या आप बस उनकी थीसिस पढ़ सकते हैं ।

— जोशकोड्स

@ जोशकोड्स, क्या ऐसा मानना ​​है? एक प्रतिष्ठित आर्किटेक्चर में, आइटम आईडी निश्चित रूप से URL का हिस्सा है, जैसे: / लोग / 123 में। मुझे REST के लिए यह साइट पसंद है: microformats.org/wiki/rest/urls

— Beez

@Beez mircoformats लिंक सर्वरों को उनके URL की संरचना के लिए एक अच्छा तरीका बताता है लेकिन सर्वर URL को निर्धारित करता है। क्लाइंट अगले-से-कभी नहीं करता है। यदि आपको यह समझ में नहीं आता है तो मेरा उत्तर या संबद्ध लेख देखें ।

— जोशकोड्स

Answer 14

नया उत्तर (अब जब मैं बेहतर समझा हूं):

PUT केवल इस बात का विवरण है कि सेवा को किस सामग्री पर काम करना चाहिए, क्लाइंट द्वारा पहचाने गए संसाधन के निरूपण को प्रस्तुत करने के लिए उपयोग करें; POST इस बात का एक बयान है कि सेवा को अब से क्या सामग्री चाहिए, इसमें (संभवतः डुप्लिकेट) शामिल हैं, लेकिन यह सर्वर पर निर्भर है कि इस सामग्री को कैसे पहचाना जाए।

PUT x(यदि xएक संसाधन की पहचान करता है ): " xमेरी सामग्री के साथ पहचाने गए संसाधन की सामग्री को बदलें ।"

PUT x(यदि xसंसाधन की पहचान नहीं करता है): "मेरी सामग्री से युक्त एक नया संसाधन बनाएँ और xइसे पहचानने के लिए उपयोग करें।"

POST x: "मेरी सामग्री को संग्रहीत करें और मुझे एक पहचानकर्ता दें जो मैं किसी सामग्री (पुराने या नए) की पहचान करने के लिए उपयोग कर सकता हूं जिसमें उक्त सामग्री हो सकती है (संभवतः अन्य सामग्री के साथ मिश्रित)। कहा गया कि संसाधन समान या अधीनस्थ होना चाहिए जो xपहचान करता है।" " y का संसाधन x के संसाधन के अधीन है " आमतौर पर है, लेकिन जरूरी नहीं कि y को x (जैसे x = /fooऔर y = /foo/bar) का उपपथ बनाकर कार्यान्वित किया जाए और अस्तित्व को दर्शाने के लिए x के संसाधन के प्रतिनिधित्व को संशोधित किया जाए। एक नए संसाधन की, जैसे कि हाइपरलिंक के साथ y तकसंसाधन और कुछ मेटाडेटा। केवल उत्तरार्द्ध वास्तव में अच्छे डिजाइन के लिए आवश्यक है, क्योंकि यूआरएल आरईएसटी में अपारदर्शी हैं - आपको किसी हाइपरमीडिया का उपयोग करना चाहिए सेवा-मार्ग के लिए क्लाइंट-साइड URL निर्माण के बजाय, वैसे भी।

REST में, "सामग्री" वाले संसाधन जैसी कोई चीज़ नहीं है। मैं डेटा के लिए "सामग्री" के रूप में संदर्भित करता हूं जो सेवा निरूपण को प्रस्तुत करने के लिए उपयोग करती है। यह आमतौर पर डेटाबेस या फ़ाइल (जैसे एक छवि फ़ाइल) में कुछ संबंधित पंक्तियों से युक्त होता है। यह उपयोगकर्ता के कंटेंट को उस सेवा में परिवर्तित करने के लिए है, जिसे सेवा उपयोग कर सकती है, जैसे JSON पेलोड को SQL स्टेटमेंट में परिवर्तित करना।

मूल उत्तर (पढ़ने में आसान हो सकता है) :

PUT /something(यदि /somethingपहले से मौजूद है): "आपके पास जो कुछ भी है उसे ले लो /somethingऔर जो मैं तुम्हें देता हूं उसे बदल दो।"

PUT /something(अगर /somethingपहले से मौजूद नहीं है): "जो मैं तुम्हें देता हूं वह ले लो और इसे रखो /something।"

POST /something: "ले लो जो मैं तुम्हें देता हूं और इसे कहीं भी रख सकता हूं /somethingजब तक आप चाहते हैं कि जब तक आप मुझे अपना URL दे दें।"

Comments

लेकिन अगर यह मौजूद नहीं है, तो आप एक नया संसाधन बनाने के लिए PUT का उपयोग कैसे कर सकते हैं, जबकि आपकी आईडी जनरेशन विधि ऑटो वृद्धि पर है? आमतौर पर ORM का ऑटो आपके लिए आईडी जनरेट करता है, जैसे आप चाहते हैं कि यह उदाहरण के लिए POST में हो। क्या इसका मतलब है कि यदि आप सही तरीके से PUT को लागू करना चाहते हैं तो आपको अपनी आईडी ऑटो पीढ़ी को बदलना होगा? यह अजीब है अगर जवाब हां में है।

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

@RoniAxelrad: PUT एक डेटाबेस "INSERT OR UPDATE" स्टेटमेंट की तरह है, जहाँ आप स्टेटमेंट में कुंजी को शामिल करते हैं, इसलिए केवल वही लागू होता है जहाँ आप कोई टक्कर नहीं कर सकते हैं। जैसे। आपके डोमेन में एक 'प्राकृतिक कुंजी' है या आप एक गाइड का उपयोग करते हैं। POST एक तालिका में ऑटो इंक्रीमेंट कुंजी के साथ सम्मिलित करने जैसा है। आपको डेटाबेस द्वारा यह बताया जाना चाहिए कि डालने के बाद उसे क्या आईडी मिली। अपने "INSERT OR UPDATE" को नोट करें यदि यह मौजूद है तो किसी भी पिछले डेटा को बदल देगा।

— निगेल थोर्न

@NigelThorne आपके उत्तर के लिए धन्यवाद। इसलिए अगर उदाहरण के लिए, मैं एक यूआरआई के साथ एक बुक आईडी 10 पीयूटी करने की कोशिश कर रहा हूं: पीयूटी किताबें / 10। यदि पुस्तक आईडी 10 मौजूद नहीं है, तो मुझे आईडी 10 सही के साथ एक पुस्तक बनानी चाहिए? लेकिन मैं निर्माण आईडी अंश को नियंत्रित नहीं कर सकता, क्योंकि यह ऑटो वेतन वृद्धि है। उस स्थिति में मुझे क्या करना चाहिए?

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

@RoniAxelrad REST एक ID पर मौजूद है जो मौजूद नहीं है सर्वर से एक संसाधन बनाने का अनुरोध करता है। यह अभी भी तय करना है कि यह अनुमति देना चाहता है या नहीं। सर्वर प्रभारी है। यह "नहीं। मैं ऐसा नहीं करने जा रहा हूं" के साथ जवाब दे सकता है। आप पहले से ही ऐसा करते हैं कि यदि उपयोगकर्ता के पास पर्याप्त अनुमति नहीं है ... आदि। सर्वर के लिए "नहीं" कहना ठीक है। REST एक कन्वेंशन है जो हमें विभिन्न प्रकार के अनुरोधों के अर्थ को परिभाषित करने देता है ... आपका सर्वर तय करता है कि आपके व्यावसायिक तर्क के आधार पर उन अनुरोधों का क्या करना है :) भले ही यह "नहीं" कहे यह अभी भी REST का अनुसरण कर रहा है :)

— निगेल थॉर्न

Answer 15

संक्षिप्त जवाब:

अंगूठे का सरल नियम: बनाने के लिए POST का उपयोग करें, अपडेट करने के लिए PUT का उपयोग करें।

लंबा जवाब:

पद:

• POST का उपयोग सर्वर पर डेटा भेजने के लिए किया जाता है।
• उपयोगी है जब संसाधन का URL अज्ञात है

डाल:

• PUT का उपयोग सर्वर में स्टेट ट्रांसफर करने के लिए किया जाता है
• किसी संसाधन का URL ज्ञात होने पर उपयोगी

दीर्घ उत्तर:

यह समझने के लिए कि हमें यह सवाल करने की आवश्यकता है कि PUT की आवश्यकता क्यों थी, PUT क्या समस्याएं थीं जिन्हें POST हल नहीं कर सकता था।

REST आर्किटेक्चर के दृष्टिकोण से ऐसा कोई भी नहीं है जो मायने रखता है। हम PUT के बिना भी रह सकते थे। लेकिन एक ग्राहक के विकास के दृष्टिकोण से इसने उसके जीवन को बहुत सरल बना दिया।

PUT से पहले, क्लाइंट सीधे उस URL को नहीं जान सकते थे कि सर्वर ने जनरेट किया है या यदि सभी ने कोई जेनरेट किया है या सर्वर को भेजा जाने वाला डेटा पहले से अपडेट है या नहीं। PUT ने इन सभी सिरदर्द के डेवलपर को राहत दी। PUT सुस्पष्ट है, PUT दौड़ की स्थिति को संभालता है, और PUT क्लाइंट को URL चुनने देता है।

Comments

आपका संक्षिप्त उत्तर बहुत गलत हो सकता है। HTTP PUT, HTTP प्रॉक्सी द्वारा दोहराया जा सकता है। और इसलिए, अगर PUT वास्तव में SQL INSERT कर रहा है, तो यह दूसरी बार विफल हो सकता है, जिसका अर्थ है कि यह अलग परिणाम देगा और इसलिए यह IDEMPOTENT नहीं होगा (जो PUT और POST के बीच का अंतर है)

— कामिल टॉमबिक

Answer 16

रूल्स 4.0 पर रूबी आंशिक अपडेट करने के लिए PUT के बजाय 'PATCH' पद्धति का उपयोग करेगा।

RAT 5789 PATCH के बारे में कहता है (1995 से):

अंतर को बेहतर बनाने और त्रुटियों को रोकने के लिए एक नई विधि आवश्यक है। PUT विधि पहले से ही एक संसाधन के साथ एक संपूर्ण नए निकाय को अधिलेखित करने के लिए परिभाषित है, और आंशिक परिवर्तन करने के लिए पुन: उपयोग नहीं किया जा सकता है। अन्यथा, प्रॉक्सी और कैश, और यहां तक ​​कि क्लाइंट और सर्वर भी ऑपरेशन के परिणाम के रूप में भ्रमित हो सकते हैं। POST का उपयोग पहले से ही किया जा रहा है लेकिन व्यापक अंतर के बिना (एक के लिए, पैच प्रारूप समर्थन की खोज करने के लिए कोई मानक तरीका नहीं है)। PATCH का उल्लेख पहले HTTP विनिर्देशों में किया गया था, लेकिन पूरी तरह से परिभाषित नहीं किया गया था।

" एज रेल्स: अपडेट के लिए PATCH नया प्राथमिक HTTP तरीका है " यह बताता है।

Answer 17

जो पहले ही कहा जा चुका है, उसे बहाल करने के जोखिम में, यह याद रखना महत्वपूर्ण है कि PUT का तात्पर्य है कि ग्राहक यह नियंत्रित करता है कि संसाधन बनाते समय URL क्या समाप्त होने वाला है। तो PUT और POST के बीच चुनाव का एक हिस्सा यह होने वाला है कि आप क्लाइंट को सही, सामान्य URL प्रदान करने के लिए कितना भरोसा कर सकते हैं, जो कि आपकी URL स्कीम के साथ सुसंगत हैं।

जब आप ग्राहक को सही काम करने के लिए पूरी तरह से भरोसा नहीं कर सकते हैं, तो एक नई वस्तु बनाने के लिए POST का उपयोग करना अधिक उपयुक्त होगा और फिर प्रतिक्रिया में क्लाइंट को URL भेजना होगा।

Comments

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

— Ixmatus

यह बिल्कुल सही नहीं है - PUT अभी भी गैर-विहित नाम के साथ संदर्भित करके एक संसाधन बना सकता है, जब तक कि प्रतिक्रिया में, सर्वर एक Locationशीर्ष लेख लौटाता है जिसमें विहित संसाधन नाम होता है।

— ईथर

@ जोशकोड्स यह मत भूलो कि आपके पास एक ही अंतर्निहित संसाधन का संदर्भ देने वाले कई यूआरआई हो सकते हैं। तो ईथर ने जो कहा वह ध्वनि की सलाह है, ग्राहक एक URL (जो अधिक अर्थ हो सकता है, जैसे PUT /X-files/series/4/episodes/max) और उस URI के साथ सर्वर का जवाब दे सकता है, जो उस नए संसाधन (यानी /X-Ffiles/episodes/91) के लिए एक संक्षिप्त कैनोनिकल यूनिक लिंक प्रदान करता है

— कॉसमैन

@TheCoshman समस्या यह है कि URL संरचना के लिए चिंता क्लाइंट की नहीं है। स्व-खोज (आरईएसटी का एक हिस्सा) के बारे में पढ़ने से यह स्पष्ट हो सकता है।

— जोशकोड्स

@ जोशकोड उस तर्क से, एक ग्राहक को कभी भी PUT का उपयोग नहीं करना चाहिए क्योंकि उन्हें URL प्रदान करने से संबंधित नहीं होना चाहिए। अच्छी तरह से ... जब तक कि सर्वर ग्राहक को एक URL प्रदान नहीं करता है यदि ग्राहक इसे लगाना चाहता है ... "PUT / comments / new" जैसा कुछ हो सकता है और सर्वर "204 / टिप्पणियों / 234532" का जवाब दे सकता है, लेकिन यह थोड़ा सा लगता है मेरे लिए RPC, ग्राहक को केवल POST / टिप्पणी करनी चाहिए ...

— thecoshman

Answer 18

बहुत ही सरल तरीके से मैं फेसबुक टाइमलाइन का उदाहरण ले रहा हूं।

केस 1: जब आप अपनी टाइमलाइन पर कुछ पोस्ट करते हैं, तो यह एक नई प्रविष्टि होती है। तो इस मामले में वे POST विधि का उपयोग करते हैं क्योंकि POST विधि गैर-बेरोजगार है।

केस 2: यदि आपका मित्र आपकी पोस्ट पर पहली बार टिप्पणी करता है, तो यह डेटाबेस में एक नई प्रविष्टि भी बनाएगा, इसलिए POST विधि का उपयोग किया जाएगा।

केस 3: यदि आपका मित्र अपनी टिप्पणी संपादित करता है, तो इस मामले में, उनके पास एक टिप्पणी आईडी है, इसलिए वे डेटाबेस में एक नई प्रविष्टि बनाने के बजाय एक मौजूदा टिप्पणी को अपडेट करेंगे। इसलिए इस प्रकार के ऑपरेशन के लिए PUT विधि का उपयोग करें क्योंकि यह एक प्रकार का वृक्ष है। *

एकल पंक्ति में, डेटाबेस में एक नई प्रविष्टि जोड़ने के लिए POST का उपयोग करें और डेटाबेस में कुछ अपडेट करने के लिए PUT करें।

Comments

यदि टिप्पणी उपयोगकर्ता आईडी, बनाई गई तिथि, टिप्पणी-संदेश आदि जैसी संपत्ति के साथ एक वस्तु है और संपादन के समय केवल टिप्पणी-संदेश अपडेट हो रहा है, तो यहां पाच किया जाना चाहिए?

— हबीब परवाद

PUT का उपयोग FB द्वारा टिप्पणी को अपडेट करने के लिए किया जाता है क्योंकि एक मौजूदा संसाधन को अपडेट किया जा रहा है, और यही PUT करता है (एक संसाधन को अपडेट करता है)। PUT, POST के विपरीत, बेरोजगार होता है। एक HTTP क्रिया idempotent त्रुटि हैंडलिंग को प्रभावित करती है लेकिन उपयोग को निर्देशित नहीं करती है। अधिक विस्तार से स्पष्टीकरण के लिए मेरा जवाब देखें: stackoverflow.com/questions/630453/put-vs-post-in-rest/…

— जोशकोड्स

Answer 19

सबसे महत्वपूर्ण विचार विश्वसनीयता है । यदि कोई POST संदेश खो जाता है तो सिस्टम की स्थिति अपरिभाषित है। स्वचालित पुनर्प्राप्ति असंभव है। PUT संदेशों के लिए, राज्य केवल पहले सफल पुनर्प्रयास तक अपरिभाषित है।

उदाहरण के लिए, POST के साथ क्रेडिट कार्ड लेनदेन बनाना एक अच्छा विचार नहीं हो सकता है।

यदि आप अपने संसाधन पर ऑटो जनरेट यूआरआई करते हैं, तो आप क्लाइंट को एक उत्पन्न यूआरआई (खाली संसाधन की ओर इशारा करते हुए) पास करके भी पीयूटी का उपयोग कर सकते हैं।

कुछ अन्य विचार:

• POST संपूर्ण संसाधन युक्त कैश की प्रतिलिपि को अमान्य कर देता है (बेहतर संगति)
• PUT प्रतिक्रियाएं देखने योग्य नहीं हैं, जबकि POST वाले हैं (सामग्री-स्थान और समाप्ति की आवश्यकता है)
• PUT को जावा जावा, पुराने ब्राउज़र, फायरवॉल जैसे उदाहरणों से कम सहायता मिलती है

Comments

यह गलत है। पोस्ट के लिए, राज्य भी अपरिभाषित है केवल पहली सफल पुन: प्रयास करें जब तक। फिर, या तो सर्वर POST को स्वीकार करता है (संदेश कभी नहीं आया), डुप्लिकेट आईडी के लिए 409 संघर्ष (संदेश आया, प्रतिक्रिया खो गया था), या किसी अन्य मान्य प्रतिक्रिया को फेंकता है।

— जोशकोड्स 24'14

आम तौर पर कोई उपयोगकर्ता POST ऑपरेशन को सुरक्षित रूप से पुनर्प्राप्त करने में सक्षम नहीं होगा क्योंकि POST ऑपरेशन कोई गारंटी नहीं देता है कि दो ऑपरेशन एक के समान प्रभाव डालेंगे। शब्द "ID" का HTTP से कोई लेना-देना नहीं है। URI संसाधन की पहचान करता है।

— हंस मल्हेरे जुले

एक उपयोगकर्ता किसी भी तरह से जितनी बार चाहे उतनी बार POST ऑपरेशन को "सुरक्षित" कर सकता है। यह सिर्फ एक डुप्लिकेट आईडी त्रुटि प्राप्त करेगा (यह मानते हुए कि संसाधन के पास एक आईडी है) या एक डुप्लिकेट डेटा त्रुटि (यह मानते हुए कि यह एक समस्या है और संसाधन के पास आईडी नहीं है)।

— जोशोड्स 2:27 पर

दीवार के खिलाफ सिर बैंग्स। HTTP के पास विश्वसनीयता की समस्या का कोई हल नहीं है, और यह बहुत अच्छी तरह से समझा नहीं गया है, बहुत अधिक चर्चा नहीं की गई है, और बस वेब अनुप्रयोगों के विशाल बहुमत के लिए इसे पूरा नहीं किया गया है। @ जोशकोड्स में इस प्रश्न का उत्तर है। मैं अनिवार्य रूप से हंस से सहमत हूं। एक समस्या है।

— bbsimonbb

@bbsimonbb, HTTP में त्रुटि प्रतिक्रियाओं का एक मजबूत और अच्छी तरह से प्रलेखित सेट है। इस सवाल का मेरा जवाब ( stackoverflow.com/questions/630453/put-vs-post-in-rest/… ) कवर करता है कि कैसे स्थिरता प्राप्त करने के लिए विनिर्देश के अनुसार http का उपयोग करें।

— जोशकोड्स

Answer 20

इस विषय पर नए पाठकों को अंतहीन चर्चा से रूबरू होना चाहिए कि आपको क्या करना चाहिए , और अनुभव से सबक की अनुपस्थिति। तथ्य यह है कि RAP SOAP पर "पसंदीदा" है, मुझे लगता है, अनुभव से एक उच्च-स्तरीय शिक्षा है, लेकिन अच्छाई हमें वहां से आगे बढ़नी चाहिए? यह 2016 है। रॉय का शोध प्रबंध 2000 में था। हमने क्या विकास किया है? मज़ा अाया? क्या इसके साथ एकीकृत करना आसान था? समर्थन के लिए? क्या यह स्मार्टफोन के उठने और मोबाइल कनेक्शन को भड़काने से निपटेगा?

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

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

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

सर्वर व्यवसाय करता है, प्रतिक्रिया देता है और सहमत कार्रवाई URI के खिलाफ संग्रहीत करता है । यदि कुछ भी गलत होता है, तो क्लाइंट अनुरोध (प्राकृतिक व्यवहार) दोहराता है, और यदि सर्वर ने पहले ही देख लिया है, तो यह संग्रहीत प्रतिक्रिया को दोहराता है और कुछ नहीं करता है ।

आप जल्दी से वादों के साथ समानता लाएंगे: हम कुछ भी करने से पहले परिणाम के लिए प्लेसहोल्डर बनाते हैं और वापस करते हैं। एक वादे की तरह, एक क्रिया एक बार सफल या विफल हो सकती है, लेकिन इसका परिणाम बार-बार प्राप्त हो सकता है।

सबसे अच्छी बात यह है कि हम आवेदन भेजने और प्राप्त करने के लिए अपने संबंधित वातावरण में विशिष्ट पहचान की कार्रवाई को विशिष्टता से जोड़ने का मौका देते हैं। और हम मांग करना शुरू कर सकते हैं, और लागू कर सकते हैं !, ग्राहकों से जिम्मेदार व्यवहार: अपने अनुरोधों को जितना चाहें उतना दोहराएं, लेकिन जब तक आप मौजूदा से एक निश्चित परिणाम के कब्जे में न हों, तब तक एक नई कार्रवाई उत्पन्न न करें।

जैसे, कई कांटेदार समस्याएं दूर हो जाती हैं। बार-बार डालने के अनुरोध डुप्लिकेट नहीं बनाएंगे, और जब तक हम डेटा के कब्जे में नहीं होते तब तक हम वास्तविक संसाधन नहीं बनाते हैं। (डेटाबेस कॉलम शून्य नहीं रह सकते हैं)। बार-बार अद्यतन अनुरोध असंगत राज्यों को नहीं मारेंगे और बाद के परिवर्तनों को अधिलेखित नहीं करेंगे। ग्राहक जो भी कारण (ग्राहक दुर्घटनाग्रस्त हो गया, प्रतिक्रिया गायब हो गई, आदि) के लिए मूल पुष्टिकरण और पुन: प्राप्त कर सकते हैं।

404 त्रुटि से टकराने के बिना, मूल हटाए गए अनुरोधों को मूल पुष्टि देख और संसाधित कर सकते हैं। यदि चीजें अपेक्षा से अधिक समय लेती हैं, तो हम अनंतिम रूप से प्रतिक्रिया दे सकते हैं, और हमारे पास एक जगह है जहां ग्राहक निश्चित परिणाम के लिए वापस जांच कर सकता है। इस पैटर्न का सबसे अच्छा हिस्सा इसकी कुंग-फू (पांडा) संपत्ति है। हम एक कमजोरी लेते हैं, ग्राहकों के लिए किसी भी अनुरोध को दोहराने के लिए किसी भी समय वे प्रतिक्रिया को नहीं समझते हैं, और इसे एक ताकत में बदल देते हैं :-)

यह बताने से पहले कि यह RESTful नहीं है, कृपया REST सिद्धांतों का सम्मान करने के कई तरीकों पर विचार करें। ग्राहक URL का निर्माण नहीं करते हैं। एपीआई खोज योग्य रहता है, यद्यपि शब्दार्थ में थोड़ा परिवर्तन होता है। HTTP क्रियाओं का उचित उपयोग किया जाता है। अगर आपको लगता है कि यह लागू करने के लिए एक बड़ा बदलाव है, तो मैं आपको अनुभव से बता सकता हूं कि यह नहीं है।

यदि आपको लगता है कि आपके पास स्टोर करने के लिए भारी मात्रा में डेटा होगा, तो आइए वॉल्यूम पर बात करते हैं: एक विशिष्ट अपडेट की पुष्टि एक किलोबाइट का एक अंश है। HTTP वर्तमान में निश्चित रूप से प्रतिक्रिया देने के लिए आपको एक या दो मिनट देता है। यहां तक ​​कि अगर आप केवल एक सप्ताह के लिए कार्रवाई करते हैं, तो ग्राहकों को पकड़ने का पर्याप्त मौका है। यदि आपके पास बहुत अधिक मात्रा है, तो आप एक समर्पित एसिड-कंप्लेंट कुंजी मान स्टोर, या इन-मेमोरी समाधान चाह सकते हैं।

Comments

एक सत्र बनाए रखने की तरह भंडारण प्रतिक्रिया नहीं होगी? जो (क्षैतिज) स्केलिंग मुद्दों का कारण होगा।

— सौरभ हरवांडे

Answer 21

दूसरों द्वारा सुझाए गए मतभेदों के अलावा, मैं एक और जोड़ना चाहता हूं।

में पोस्ट विधि आप में शरीर पैरामीटर भेज सकते हैंform-data

में PUT विधि आप में शरीर पैरामीटर भेजने के लिएx-www-form-urlencoded

हैडर Content-Type:application/x-www-form-urlencoded

इसके अनुसार, आप PUT विधि में फाइल या मल्टीपार्ट डेटा नहीं भेज सकते

संपादित करें

सामग्री प्रकार "एप्लिकेशन / x-www-form-urlencoded" बाइनरी डेटा या गैर-ASCII वर्णों वाले पाठ को बड़ी मात्रा में भेजने के लिए अक्षम है। सामग्री प्रकार "मल्टीपार्ट / फॉर्म-डेटा" का उपयोग उन प्रपत्रों को प्रस्तुत करने के लिए किया जाना चाहिए जिनमें फाइलें, गैर-एएससीआईआई डेटा और बाइनरी डेटा शामिल हैं।

जिसका मतलब है अगर आपको सबमिट करना है

फ़ाइलें, गैर- ASCII डेटा और बाइनरी डेटा

आपको POST विधि का उपयोग करना चाहिए

Comments

इसे क्यों नहीं उखाड़ा गया? अगर सच है, तो यह एक महत्वपूर्ण अंतर है?

— इफैक्ट्योर सिप

प्रोफ़ाइल अपडेट के लिए एपीआई को लागू करते समय मुझे इसका सामना करना पड़ा, जिसमें उपयोगकर्ता प्रोफ़ाइल पिक अपलोड शामिल है। फिर मैंने इसे पोस्टमैन, अजाक्स, पीएचपी कर्ल और लारवेल 5.6 के बैकएंड के साथ परीक्षण किया।

— रोहित धीमान

Answer 22

ऐसा प्रतीत होता है कि RST सेवाओं के लिए HTTP POST बनाम HTTP PUT विधि का उपयोग करने के लिए हमेशा कुछ भ्रम होता है। अधिकांश डेवलपर्स सीधे HTTP तरीकों से CRUD संचालन को जोड़ने का प्रयास करेंगे। मैं तर्क दूंगा कि यह सही नहीं है और कोई बस HTTP विधियों को HTTP विधियों से नहीं जोड़ सकता है। अर्थात्:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

यह सही है कि CRUD ऑपरेशन्स के R (etrieve) और D (elete) को क्रमशः HTTP तरीकों GET और DELETE में मैप किया जा सकता है। हालाँकि, भ्रम सी (reate) और U (अद्यतन) कार्रवाई में निहित है। कुछ मामलों में, कोई PUT का उपयोग कर सकता है जबकि अन्य मामलों में POST की आवश्यकता होगी। अस्पष्टता HTTP PUT विधि बनाम HTTP POST विधि की परिभाषा में निहित है।

HTTP 1.1 विनिर्देशों के अनुसार GET, HEAD, DELETE, और PUT विधियाँ निष्प्राण होनी चाहिए, और POST विधि निष्प्राण नहीं है। कहने का तात्पर्य यह है कि यदि कोई संसाधन एक संसाधन पर एक या कई बार किया जा सकता है और हमेशा उस संसाधन की उसी स्थिति को लौटाता है, तो यह एक आदर्श है। जबकि एक गैर-निष्क्रिय ऑपरेशन, संसाधन के एक संशोधित राज्य को एक अनुरोध से दूसरे में वापस कर सकता है। इसलिए, एक गैर-बेरोजगार ऑपरेशन में, इस बात की कोई गारंटी नहीं है कि किसी व्यक्ति को संसाधन का एक ही राज्य प्राप्त होगा।

उपर्युक्त सुस्पष्ट परिभाषा के आधार पर, मेरा HTTP HTTP तरीका बनाम बनाम RST सेवाओं के लिए HTTP POST विधि का उपयोग करने पर है: जब HTTP PUT विधि का उपयोग करें:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

दोनों ही मामलों में, इन ऑपरेशनों को एक ही परिणाम के साथ कई बार किया जा सकता है। यही कारण है कि संसाधन को एक से अधिक बार अनुरोध करने से नहीं बदला जाएगा। इसलिए, एक सच्चा आदर्श ऑपरेशन। जब HTTP POST विधि का उपयोग करें:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

निष्कर्ष

REST सेवाओं के लिए HTTP विधियों में सीधे CRUD संचालन को सहसंबंधित और मैप न करें। एक HTTP पीओटी विधि बनाम एक HTTP पीओटी विधि का उपयोग उस ऑपरेशन के बेकार पहलू पर आधारित होना चाहिए। यही है, यदि ऑपरेशन idempotent है, तो HTTP PUT विधि का उपयोग करें। यदि ऑपरेशन न के बराबर है, तो HTTP POST विधि का उपयोग करें।

Comments

अपडेट => HTTP POST: POST अपडेट करने के लिए नहीं है

— प्रेमराज ३०'१६ ०६:०५

@premraj आपने यह धारणा बना ली कि बुरहान आपको नहीं बनाने के लिए कह रहा है; अर्थात्, आप CRUD, REST और HTTP को स्वीकार कर रहे हैं। यदि आप RFC 7231 पढ़ते हैं, जहां ये चीजें परिभाषित हैं, तो आप पाएंगे कि HTTP प्रोटोकॉल में, POST की परिभाषा निश्चित रूप से अपडेट करने की अनुमति देती है। यह केवल REST की अड़चन है जो अन्यथा कहती है।

— IAM_AL_X

Answer 23

मूल सर्वर उस URI के साथ संसाधन बना सकता है

इसलिए आप POST का उपयोग करते हैं और शायद, लेकिन संसाधन निर्माण के लिए आवश्यक नहीं। आपको दोनों का समर्थन करने की आवश्यकता नहीं है। मेरे लिए POST पूरी तरह से पर्याप्त है। तो यह एक डिजाइन निर्णय है।

जैसा कि आपके उद्धरण में उल्लेख किया गया है, आप PUT का उपयोग वहाँ के निर्माण के लिए करते हैं, जो IRI को सौंपा गया कोई संसाधन नहीं है, और आप वैसे भी एक संसाधन बनाना चाहते हैं। उदाहरण के लिए, PUT /users/123/passwordआमतौर पर पुराने पासवर्ड को नए के साथ बदल देता है, लेकिन आप इसका उपयोग पासवर्ड बनाने के लिए कर सकते हैं यदि यह पहले से मौजूद नहीं है (उदाहरण के लिए, नए पंजीकृत उपयोगकर्ताओं द्वारा या प्रतिबंधित उपयोगकर्ताओं को पुनर्स्थापित करके)।

Comments

मुझे लगता है कि आप PUT का उपयोग करने के कुछ अच्छे उदाहरणों में से एक प्रदान करने में सफल रहे हैं, अच्छी तरह से किया गया।

— Thecoshman

Answer 24

मैं निम्नलिखित के साथ उतरने जा रहा हूं:

PUT एक संसाधन को संदर्भित करता है, जिसे URI द्वारा पहचाना जाता है। इस मामले में, आप इसे अपडेट कर रहे हैं। यह संसाधनों का जिक्र करने वाली तीन क्रियाओं का हिस्सा है - हटाएं और अन्य दो बनें।

POST मूल रूप से एक स्वतंत्र रूप का संदेश है, जिसका अर्थ है 'बैंड से बाहर'। यदि संदेश को एक निर्देशिका में संसाधन जोड़ने के रूप में व्याख्या की जा सकती है, तो यह ठीक होगा, लेकिन मूल रूप से आपको यह जानने के लिए संदेश को समझना होगा कि आप क्या भेज रहे हैं (पोस्टिंग) यह जानने के लिए कि संसाधन के साथ क्या होगा।

---

क्योंकि PUT और GET और DELETE एक संसाधन का उल्लेख करते हैं, वे भी परिभाषा के अनुसार हैं।

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

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

---

संपादित करें: एक और बात - एक पीयूटी बना सकते हैं, लेकिन अगर ऐसा होता है तो आईडी को एक प्राकृतिक आईडी - एकेए एक ईमेल पता होना चाहिए। इस तरह जब आप दो बार PUT करते हैं, तो दूसरा पुट पहले का अपडेट होता है। यह इसे उदासीन बनाता है ।

यदि आईडी उत्पन्न होती है (उदाहरण के लिए एक नया कर्मचारी आईडी), तो उसी URL के साथ दूसरा PUT एक नया रिकॉर्ड बनाएगा, जो कि निष्पादक नियम का उल्लंघन करता है। इस स्थिति में क्रिया POST होगी, और संदेश (संसाधन नहीं) इस संदेश में परिभाषित मूल्यों का उपयोग करके एक संसाधन बनाना होगा।

Answer 25

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

मैं उन सम्मेलनों का वर्णन करूंगा जो मुझे लगता है कि सबसे व्यापक रूप से उपयोग किए जाते हैं और सबसे उपयोगी होते हैं:

जब आप किसी विशेष URL पर एक संसाधन रखते हैं, तो क्या होता है कि उसे उस URL पर सहेजा जाना चाहिए, या उन पंक्तियों के साथ कुछ करना चाहिए।

जब आप किसी विशेष URL पर किसी संसाधन पर POST करते हैं, तो अक्सर आप उस URL पर संबंधित जानकारी पोस्ट कर रहे होते हैं। इसका तात्पर्य है कि URL पर संसाधन पहले से मौजूद है।

उदाहरण के लिए, जब आप एक नई स्ट्रीम बनाना चाहते हैं, तो आप इसे कुछ URL पर PUT कर सकते हैं। लेकिन जब आप किसी संदेश को मौजूदा स्ट्रीम में पोस्ट करना चाहते हैं, तो आप उसके URL पर POST करें।

स्ट्रीम के गुणों को संशोधित करने के लिए, आप PUT या POST के साथ ऐसा कर सकते हैं। मूल रूप से, केवल "PUT" का उपयोग करें, जब ऑपरेशन बेमतलब है - अन्यथा POST का उपयोग करें।

हालाँकि, ध्यान दें कि सभी आधुनिक ब्राउज़र GET या POST के अलावा HTTP क्रियाओं का समर्थन नहीं करते हैं।

Comments

जैसा कि आप POST का वर्णन करते हैं कि वास्तव में PATCH का व्यवहार कैसा होना चाहिए। "पोस्टिंग सूची में पोस्ट" के रूप में POST का अर्थ "एपेंड" के समान कुछ और है।

— अलेक्जेंडर टॉर्स्ट्लिंग 15

Answer 26

अधिकांश समय, आप उन्हें इस तरह उपयोग करेंगे:

• एक संग्रह में एक संसाधन पोस्ट करें
• संग्रह /: आईडी द्वारा पहचाने गए संसाधन को PUT करें

उदाहरण के लिए:

• पोस्ट / आइटम
• PUT / आइटम / 1234

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

ध्यान दें कि POST "संग्रह में एक नया तत्व बनाता है, और किसी दिए गए URL पर एक तत्व" PUT "प्रतिस्थापित करता है, लेकिन आंशिक संशोधनों के लिए PUT का उपयोग करना बहुत आम बात है, अर्थात इसका उपयोग केवल मौजूदा संसाधनों को अपडेट करने के लिए और केवल शरीर में शामिल क्षेत्रों (अन्य क्षेत्रों की अनदेखी) को संशोधित करें। यह तकनीकी रूप से गलत है, यदि आप REST-purist बनना चाहते हैं, तो PUT को पूरे संसाधन को बदलना चाहिए और आपको आंशिक अपडेट के लिए PATCH का उपयोग करना चाहिए। मैं व्यक्तिगत रूप से बहुत परवाह नहीं करता हूं जहां तक ​​व्यवहार स्पष्ट है और आपके सभी एपीआई एंडपॉइंट्स के अनुरूप है।

याद रखें, REST आपके API को सरल रखने के लिए सम्मेलनों और दिशानिर्देशों का एक सेट है। यदि आप "RESTfull" बॉक्स की जांच करने के लिए एक जटिल कार्य के आसपास समाप्त होते हैं, तो आप उद्देश्य को हरा रहे हैं);

Answer 27

हालांकि इनका वर्णन करने का एक अज्ञेय तरीका है, लेकिन यह उत्तर से लेकर वेबसाइटों तक विभिन्न कथनों के साथ विरोधाभासी प्रतीत होता है।

यहां बहुत स्पष्ट और प्रत्यक्ष हैं। यदि आप वेब एपीआई के साथ काम कर रहे एक .NET डेवलपर हैं, तो तथ्य (Microsoft API प्रलेखन से) हैं, http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -पीआई-कि-सपोर्ट-क्रूड-ऑपरेशंस :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

सुनिश्चित करें कि आप अपडेट करने के लिए "POST" का उपयोग कर सकते हैं, लेकिन बस अपने दिए गए ढांचे के साथ आपके लिए निर्धारित सम्मेलनों का पालन करें। मेरे मामले में यह .NET / Web API है, इसलिए PUT UPDATE के लिए है, कोई बहस नहीं है।

मुझे आशा है कि यह किसी भी Microsoft डेवलपर्स को मदद करता है जो अमेज़ॅन और सन / जावा वेबसाइट लिंक के साथ सभी टिप्पणियों को पढ़ते हैं।

Answer 28

यहाँ एक सरल नियम है:

किसी URL पर PUT का उपयोग उस URL पर स्थित संसाधन को अद्यतन करने या बनाने के लिए किया जाना चाहिए।

URL में POST का उपयोग किसी ऐसे संसाधन को अद्यतन करने या बनाने के लिए किया जाना चाहिए जो किसी अन्य ("अधीनस्थ") URL पर स्थित है, या HTTP के माध्यम से स्थानीय नहीं है।

Comments

पीयूटी अपडेट के लिए नहीं है, यह बदलने के लिए है, ध्यान दें कि बनाने के लिए आप कुछ के साथ कुछ नहीं बदल रहे हैं। POST फॉर्म के किसी भी आकार में अद्यतन के लिए बिल्कुल नहीं है।

— Thecoshman

क्या http कल्पना ऐसा कहती है? या आप कुछ और पर अपनी टिप्पणी को आधार बना रहे हैं?

— एडम ग्रिफिथ्स

यह सिर्फ सामान्य ज्ञान है, जब आप कुछ नहीं जानते हैं तो आप कैसे अपडेट करते हैं? POST एक नया संसाधन बनाने के लिए है।

— Thecoshman

Thecoshman - आप यहाँ शब्दार्थ को गाली दे रहे हैं - एक प्रतिस्थापन एक अद्यतन हो सकता है यदि यह कुछ अंतरों के साथ एक ही संसाधन है। यदि एक ही संसाधन को बदलने के लिए उपयोग किया जाता है, तो प्रतिस्थापित केवल पुट के लिए मान्य है। एक नए और अलग संसाधन के साथ प्रतिस्थापित करना अमान्य है (पुराने को हटाएं और नया जोड़ें?), खासकर अगर 'नए' संसाधन में प्राकृतिक आईडी नहीं है। पोस्ट, OTOH, एक ऐसी चीज़ है जो पोस्ट का उपयोग, अपडेट, रिप्लेस और डिलीट कर सकती है - पोस्ट का उपयोग इस बात पर निर्भर करता है कि कोई संदेश व्याख्या करने के लिए है या नहीं, जैसे कि 'डिस्काउंट लागू करें', जो कि संसाधन के आधार पर बदल भी सकता है और नहीं भी। तर्क।

— जेरार्ड ओनेइल

अपनी दूसरी टिप्पणी के रूप में - आप के बारे में कैसे 'संसाधन प्राप्त करें', उन क्षेत्रों को संशोधित करें जिनकी आपको आवश्यकता है, और फिर इसे वापस डालें? या कैसे के बारे में अगर संसाधन एक अलग स्रोत से आता है, लेकिन एक प्राकृतिक आईडी (बाहरी आईडी) का उपयोग करता है - मूल डेटा को बदलने पर स्वाभाविक रूप से URL पर संसाधन को अपडेट करेगा।

— जेरार्ड ओनिल

Answer 29

यदि आप डेटाबेस संचालन से परिचित हैं, तो हैं

1. चुनते हैं
2. सम्मिलित करें
3. अपडेट करें
4. हटाएं
5. मर्ज (अपडेट पहले से मौजूद है, तो डालें)

मैं PUTमर्ज के लिए उपयोग करता हूं और संचालन की तरह अद्यतन करता हूं और POSTसम्मिलन के लिए उपयोग करता हूं ।

Answer 30

व्यवहार में, संसाधन बनाने के लिए POST अच्छा काम करता है। स्थान बनाए गए शीर्ष लेख में नए बनाए गए संसाधन का URL लौटाया जाना चाहिए। PUT का उपयोग किसी संसाधन को पूरी तरह से अपडेट करने के लिए किया जाना चाहिए। कृपया समझें कि RESTful API डिज़ाइन करते समय ये सबसे अच्छे अभ्यास हैं। HTTP विनिर्देशन जैसे कि संसाधनों को बनाने / अद्यतन करने के लिए कुछ प्रतिबंधों के साथ PUT / POST के उपयोग को प्रतिबंधित नहीं करता है। Http://techoctave.com/c7/posts/71-twitter-rest-api-dissected पर एक नज़र डालें जो सर्वोत्तम प्रथाओं का सारांश प्रस्तुत करता है।

Comments

अधिकांश भाग के लिए, इस सभी शोर के माध्यम से पढ़ने से, आप गेंद पर लगते हैं। मैं कहूंगा, हालांकि, हमें PUT को रीप्ले / अपडेट के बजाय रिप्लेस विधि के रूप में देखना चाहिए। मुझे लगता है कि यह जो करता है उसमें बेहतर वर्णन करता है।

— Thecoshman