सवाल REST में बनाम पोस्ट बनाओ


HTTP / 1.1 स्पेक के अनुसार:

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

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

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

अर्थात्, PUT उपयोग किया जाता है बनाएं या अपडेट करें

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


4468
2018-03-10 14:25


मूल


HTTPbis में परिभाषाओं का उपयोग करना सहायक हो सकता है - रॉय ने उन्हें स्पष्ट करने में उचित मात्रा में काम किया। देख: tools.ietf.org/html/... - Mark Nottingham
नवीनतम संशोधन में @ मार्कनोटिंगहम की टिप्पणी लाने के लिए, यहां है पद तथा डाल, जैसा कि HTTPbis पर परिभाषित किया गया है। - Marius Butuc
ऐसा लगता है कि यह बहस सीआरयूडी परिचालन के संदर्भ में HTTP पद्धतियों का वर्णन करके आरईएसटी को ओवरम्प्लीफाइंग करने के सामान्य अभ्यास से उत्पन्न हुई है। - Stuporman
दुर्भाग्य से पहला जवाब POST के बारे में गलत है। मतभेदों के बेहतर स्पष्टीकरण के लिए मेरा उत्तर देखें: stackoverflow.com/a/18243587/2458234 - 7hi4g0
पुट और पोस्ट दोनों असुरक्षित तरीके हैं। हालांकि, पुट बेवकूफ है, जबकि पोस्ट नहीं है। - इस पर अधिक देखें: restcookbook.com/HTTP%20Methods/put-vs-post/... - Dinesh Saini


जवाब:


कुल मिलाकर: 

पुट और पोस्ट दोनों को बनाने के लिए इस्तेमाल किया जा सकता है।

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

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

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

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

कुछ विचार:

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

एक उदाहरण:

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

पद:

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

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

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

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

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

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

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

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

डाल: 

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

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

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

मौजूदा संसाधन को ओवरराइट करने के लिए:

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

3487
2018-03-10 14:29



मुझे लगता है कि कोई इस तथ्य पर पर्याप्त दबाव नहीं डाल सकता है कि PUT बेवकूफ है: यदि नेटवर्क बॉट किया गया है और ग्राहक को यह सुनिश्चित नहीं है कि उसका अनुरोध इसके माध्यम से किया गया है, तो यह केवल इसे एक दूसरा (या 100 वां) समय भेज सकता है, और इसकी गारंटी है HTTP spec कि यह एक बार भेजने के रूप में बिल्कुल वही प्रभाव है। - Jörg W Mittag
@ जोर्ग डब्ल्यू मिट्टाग: आवश्यक नहीं है। दूसरी बार 40 9 संघर्ष या कुछ वापस लौटा सकता है अगर अनुरोध में संशोधित किया गया है (किसी अन्य उपयोगकर्ता द्वारा या पहले अनुरोध स्वयं, जो प्राप्त हुआ)। - Mitar
अगर मुझे गलत नहीं लगता है, तो हमें क्या जोर देना चाहिए कि पुट है परिभाषित बेवकूफ होना आपको अभी भी अपना सर्वर इस तरह लिखना है कि PUT सही ढंग से व्यवहार करता है, हाँ? शायद यह कहना बेहतर है कि "PUT परिवहन को बेदखल करने का कारण बनता है, जो परिवहन के व्यवहार को प्रभावित कर सकता है, उदाहरण के लिए कैशिंग।" - Ian Ni-Lewis
@ JörgWMittag Idempotence catchphrase? कैसे "मेरे दोस्त को भेजें और भेजें और भेजें, इससे अंत में कोई फर्क नहीं पड़ता।" - James Beninger
उनके बारे में सोचता है: PUT = डालें या अपडेट करें; पोस्ट = डालें। तो जब आप दो पुट करते हैं - जब आप दो पोस्ट करते हैं तो आपको एक नया रिकॉर्ड मिलता है - आपको दो नए रिकॉर्ड मिलते हैं। - Eugen Konkov


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

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


PUT और POST के आधार पर चयन करना बेहतर है idempotence कार्रवाई का।

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

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


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

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929

1882
2018-04-22 14:55



मैं मानता हूं, जहां भी बेवकूफता का सवाल है, उसे किसी भी अन्य चिंताओं को तोड़ना चाहिए क्योंकि यह गलत होने से कई अनपेक्षित बग पैदा हो सकती हैं। - Josh
यदि POST संसाधन को अपडेट कर सकता है, तो यह बेवकूफ नहीं है? यदि मैं पीयूटी का उपयोग कर छात्रों की आयु बदलता हूं और 10x बार करता हूं तो छात्रों की उम्र एक जैसी होती है यदि मैंने इसे एक बार किया था। - Schneider
@Schneider, इस मामले में आपका सर्वर बेवकूफ की गारंटी देने के लिए एक अतिरिक्त प्रयास कर रहा है, लेकिन यह विज्ञापन नहीं दे रहा है। यदि वे ऐसे POST अनुरोध को पुनः लोड करने का प्रयास करते हैं तो ब्राउज़र अभी भी उपयोगकर्ता को चेतावनी देंगे। - Tobu
@Schneider POST सहायक संसाधन बना सकता है; इसलिए आप संग्रह के लिए पोस्ट कर सकते हैं, जैसे पोस्ट / व्यय-रिपोर्ट और यह आपके सर्वर पर कई अनुरोधों (व्यय रिपोर्ट) को आपके द्वारा भेजे गए अनुरोधों की मात्रा के रूप में बनाएगा, भले ही वे पूरी तरह से समान हों। ऑटो-वृद्धिशील प्राथमिक कुंजी के साथ डीबी तालिका (/ व्यय-रिपोर्ट) में एक ही पंक्ति डालने के रूप में इसके बारे में सोचें। डेटा वही रहता है, कुंजी (इस मामले में यूआरआई) सर्वर द्वारा उत्पन्न होता है और हर दूसरे सम्मिलन (अनुरोध) के लिए अलग होता है। तो, पोस्ट प्रभाव कर सकते हैं बेवकूफ हो, लेकिन भी हो सकता है नहीं। इसलिए, पोस्ट है नहीं idempotent। - Snifff
मान लें कि हमारे पास ऐसी संस्थाएं हैं जिनमें दो गुण हो सकते हैं - name तथा date। अगर हमारे पास मौजूदा के साथ एक इकाई है name तथा date, लेकिन फिर केवल एक निर्दिष्ट करने के लिए अनुरोध करें name, का उचित व्यवहार डाल विलुप्त होना होगा date इकाई के, जबकि पद केवल निर्दिष्ट गुणों को अपडेट कर सकते हैं, अनिर्दिष्ट गुणों को छोड़कर अनुरोध के पहले थे। क्या यह सही / उचित लगता है, या यह एक अनुचित उपयोग है डाल(मैंने संदर्भ देखा PATCH, जो ऐसा लगता है कि अधिक उपयुक्त होगा, लेकिन अभी तक अस्तित्व में नहीं है)? - Jon z


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

पुट और पोस्ट के लिए प्रासंगिक विनिर्देश है आरएफसी 2616 §9.5 एफएफ।

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

डाल एक संसाधन बनाने या बदलने के लिए है यूआरएल क्लाइंट द्वारा जाना जाता है

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

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

आरएफसी इस तरह पढ़ता है:

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

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


563
2018-04-07 05:52



या बाड़ के दूसरी तरफ से: PUT यदि क्लाइंट परिणामस्वरूप संसाधन का पता निर्धारित करता है, तो सर्वर सर्वर करता है तो पोस्ट करें। - DanMan
मुझे लगता है कि यह उत्तर इसे और स्पष्ट करने के लिए संपादित किया जाना चाहिए कि @DanMan ने एक बहुत ही सरल तरीके से बताया। जो मुझे सबसे मूल्यवान लगता है वह अंत में नोट है, यह बताते हुए कि एक PUT केवल पूरे संसाधन को बदलने के लिए उपयोग किया जाना चाहिए। - Hermes
पैच कम से कम कुछ वर्षों के लिए एक यथार्थवादी विकल्प नहीं है, लेकिन मैं विचारधारा से सहमत हूं। - crush
मैं समझने की कोशिश कर रहा हूं, लेकिन कुछ बनाने के लिए PUT का उपयोग केवल तभी समझ जाएगा यदि क्लाइंट यह सुनिश्चित करने के लिए जानता है कि संसाधन अभी तक मौजूद नहीं है, है ना? ब्लॉग उदाहरण के बाद, कहें कि आपने कुछ वर्षों में सैकड़ों ब्लॉग पोस्ट बनाए हैं, फिर दो साल पहले एक पोस्ट के लिए गलती से उसी शीर्षक को चुनते हैं। अब आप गए हैं और उस पोस्ट को बदल दिया है, जिसका इरादा नहीं था। तो बनाने के लिए PUT का उपयोग करने के लिए क्लाइंट को ट्रैक करने की आवश्यकता होगी और क्या नहीं है, और दुर्घटनाओं और अनपेक्षित दुष्प्रभावों के साथ-साथ ऐसे मार्ग भी हो सकते हैं जो दो पूरी तरह से अलग-अलग चीजें करते हैं? - galaxyAbstractor
तुम सही हो। एक मौजूदा यूआरएल पर एक ब्लॉग यूआरएल को एक मौजूदा पोस्ट के रूप में अपडेट करना होगा (हालांकि आप स्पष्ट रूप से पहले जीईटी के साथ जांच सकते हैं)। यह इंगित करता है कि यूआरएल के रूप में शीर्षक का उपयोग करना क्यों बुरा विचार होगा। हालांकि यह कहीं भी काम करेगा डेटा में एक प्राकृतिक कुंजी थी ... जो मेरे अनुभव में दुर्लभ है। या यदि आपने GUID का उपयोग किया है - Nigel Thorne


सारांश:

सर्जन करना:

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

डाल

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

PUT /resources/<newResourceId> HTTP/1.1 

पद

बनाता है  / संसाधन यूआरआई, या के तहत नया संसाधन संग्रह। आम तौर पर पहचानकर्ता सर्वर द्वारा वापस कर दिया जाता है।

POST /resources HTTP/1.1

अद्यतन करें:

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

डाल

संसाधन के साथ अद्यतन करता है existingResourceId यूआरआई, या संसाधनों के तहत पहचानकर्ता के रूप में संग्रह

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

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

POST /users HTTP/1.1

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

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

POST /users/john HTTP/1.1

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

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

PUT /users/john HTTP/1.1

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

युक्ति:

मुझे spec के कुछ महत्वपूर्ण हिस्सों को हाइलाइट करने दें:

पद

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

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

डाल

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

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

संदर्भ:


164
2017-08-14 22:47



यह पोस्ट मुझे समझने में सहायक थी कि POST दिए गए संग्रह (यूआरआई) में बच्चे के रूप में "कुछ" जोड़ता है, जबकि PUT स्पष्ट रूप से दिए गए यूआरआई स्थान पर "कुछ" को परिभाषित करता है। - kwah
यह सबसे अच्छा जवाब है, यहां, मुझे लगता है: इनमें से कोई भी "पोस्ट संसाधन को अपडेट नहीं कर सकता" बकवास। मुझे आपका कथन पसंद है, "अपडेट केवल PUT के साथ किया जा सकता है"। - Thomas
नहीं, PUT अद्यतन या बनाने के लिए नहीं है। यह बदलने के लिए है। ध्यान दें कि आप बनाने के प्रभाव के लिए कुछ भी नहीं बदल सकते हैं। - thecoshman
@ 7hi4g0 PUT एक पूर्ण प्रतिस्थापन के साथ अद्यतन करने के लिए है, दूसरे शब्दों में, यह प्रतिस्थापित करता है। आप किसी चीज़ के साथ कुछ भी नहीं बदलते हैं, या पूरी तरह से कुछ नया कुछ। PUT मामूली परिवर्तन करने के लिए नहीं है (जब तक कि आपके पास क्लाइंट उस मामूली परिवर्तन नहीं करता है और पूरे नए संस्करण को प्रदान करता है, यहां तक ​​कि शेष क्या है)। आंशिक संशोधन के लिए, पैच पसंद का तरीका है। - thecoshman
@thecoshman आप कर सकते हैं, लेकिन यह स्पष्ट नहीं होगा कि निर्माण भी इसमें शामिल है। इस मामले में, स्पष्ट होना बेहतर है। - 7hi4g0


मैं अपनी "व्यावहारिक" सलाह जोड़ना चाहता हूं। जब आप "आईडी" को जानते हैं तो PUT का उपयोग करें जिसके द्वारा आप जिस वस्तु को सहेज रहे हैं उसे पुनर्प्राप्त किया जा सकता है। 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

155
2018-01-15 19:59



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


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

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

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

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

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

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


144
2017-10-23 14:27



ढीलेपन के कारण यह आमतौर पर सिखाया जा सकता है कि आपको केवल दो क्रियाएं हैं: प्राप्त करें और पोस्ट करें। प्राप्त करने के लिए प्राप्त करें, बदलने के लिए पोस्ट करें। पोस्ट का उपयोग करके पुट और डिलीट भी किया गया था। 25 साल बाद वास्तव में क्या मतलब है कि पूछना संभवतः एक संकेत है जिसे हमने पहले गलत बताया था। आरईएसटी लोकप्रियता ने लोगों को मूलभूत आधार पर वापस ले जाया जहां हमें अब पिछली गलतियों को दूर करना होगा। POST overused था और अब आमतौर पर गलत तरीके से पढ़ाया जाता है। सबसे अच्छा हिस्सा: "एक ही डेटा के साथ दो बार पोस्ट करना मतलब है कि दो समान [संसाधन]" बनाएं। महान बिंदु! - maxpolk
आईडी द्वारा रिकॉर्ड बनाने के लिए आप PUT का उपयोग कैसे कर सकते हैं, जैसे कि आपके उदाहरण में user 5 अगर यह अभी तक अस्तित्व में नहीं है? तुम्हारा मतलब नहीं है update, replace if already exists? या कुछ और - Luke
@ कॉल्टन: मेरा मतलब था मैंने जो लिखा था। यदि आप / उपयोगकर्ता / 5 और # 5 को अभी तक मौजूद नहीं करते हैं तो आप उपयोगकर्ता 5 डालते हैं। - Alexander Torstling
@ कॉल्टन: और PUT इसका भी उपयोग किया जा सकता है बदलने के एक का मूल्य मौजूदा संसाधन पूरी तरह से। - DavidRR
"पोस्ट पर पुट पसंद करें" ... इसे उचित ठहराने की देखभाल? - thecoshman


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

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

104
2018-03-10 14:28



POST /items पहले से परिभाषित संसाधन ('आइटम') में एक नया आइटम जोड़ता है। ऐसा नहीं है, जैसा कि उत्तर कहता है, "एक समूह बनाएं।" मुझे समझ में नहीं आता कि इसमें 12 वोट क्यों हैं। - David J.
बॉक्स के बाहर, रेल आरईएसटी के माध्यम से 'समूह बनाने' का समर्थन नहीं करता है। 'समूह बनाएं' जिसका अर्थ है कि 'संसाधन बनाएं' आपको स्रोत कोड के माध्यम से करना है। - David J.
यह एक उचित दिशानिर्देश है, लेकिन एक oversimplification। जैसा कि अन्य उत्तरों का उल्लेख है, दोनों बनाने और अद्यतन दोनों के लिए विधि का उपयोग किया जा सकता है। - Brad Koch
मैं थोड़ा बदलाव के साथ उत्तर से सहमत हूं। पूरी तरह से संसाधन को अद्यतन करने के लिए बनाने और PUT बनाने के लिए POST का उपयोग करें। आंशिक अद्यतनों के लिए, हम पुट या पैच का उपयोग कर सकते हैं। आइए कहें कि हम एक समूह की स्थिति को अपडेट करना चाहते हैं। हम स्थिति के साथ पुट / समूह / 1 / स्थिति का उपयोग कर सकते हैं पेलोड में कार्रवाई के बारे में विवरण के साथ अनुरोध पेलोड या पैच / समूह / 1 है - java_geek
यह भी स्पष्ट किया जाना चाहिए कि PUT /items/42 के लिए भी मान्य है बनाना संसाधन, लेकिन केवल तभी ग्राहक को संसाधन नाम देने का विशेषाधिकार है। (क्या रेल इस क्लाइंट को इस नामकरण विशेषाधिकार की अनुमति देता है?) - DavidRR


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

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

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

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

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


57
2018-03-10 15:27



संसाधन बनाने के लिए PUT को अनुमति देने में कुछ भी गलत नहीं है। बस जागरूक रहें कि इसका मतलब है कि ग्राहक यूआरएल प्रदान करता है। - Julian Reschke
संसाधन बनाने के लिए PUT को अनुमति देने में कुछ गड़बड़ है: क्लाइंट यूआरएल प्रदान करता है। वह सर्वर का काम है! - Joshcodes
@ जोशकोड यह हमेशा ऐसा नहीं होता है कि यह क्लाइंट आईडी बनाने के लिए सर्वर का काम है। मैंने डिजाइनों को तेजी से देखा है जो ग्राहकों को संसाधन आईडी के रूप में कुछ प्रकार के यूयूआईडी उत्पन्न करने देते हैं। यह डिज़ाइन विशेष रूप से पैमाने को बढ़ाने के लिए खुद को उधार देता है। - Justin Ohms
@JustinOhms मैं क्लाइंट जेनरेट आईडी के बारे में आपके बिंदु से सहमत हूं (साइड नोट: लगभग 2008 के बाद से मेरे द्वारा डिजाइन किए गए सभी सिस्टम क्लाइंट को यूयूआईडी / गइड के रूप में आईडी बनाने की आवश्यकता है)। इसका मतलब यह नहीं है कि क्लाइंट को यूआरएल निर्दिष्ट करना चाहिए। - Joshcodes
@ जोशकोड चिंताओं को अलग करने का मामला है। जहां यूआरएल उत्पन्न होता है वास्तव में थोड़ा परिणाम होता है। हां सर्वर सही यूआरएल से सामग्री वितरित करने के लिए ज़िम्मेदार है लेकिन यह किसी सर्वर को किसी गलत यूआरएल पर अनुरोध का जवाब देने से सीमित नहीं करता है। इस मामले में सर्वर से सही प्रतिक्रिया 308 है। एक उचित ग्राहक फिर सही यूआरएल पर PUT को पुनः प्रयास करेगा। एक और उदाहरण एक वितरित प्रणाली है जहां सभी नोड्स ग्राहकों द्वारा प्रदान किए गए सभी संसाधनों के बारे में नहीं जानते हैं। यहां बनाने के लिए एक पुट पूरी तरह मान्य होगा क्योंकि उस सर्वर नोड के लिए संसाधन मौजूद नहीं है। - Justin Ohms


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

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

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

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

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

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

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

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

10.4.10 40 9 संघर्ष

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

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

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

40 9 संघर्ष के स्टेटस कोड के साथ जवाब देना सही सहारा है क्योंकि:

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

2616 को बदलने के लिए आरएफसी 7231 के रिलीज के आधार पर अपडेट करें

आरएफसी 7231 2616 और अंदर बदलने के लिए डिज़ाइन किया गया है धारा 4.3.3 एक पोस्ट के लिए अनुवर्ती संभावित प्रतिक्रिया का वर्णन करता है

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

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

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


53
2017-10-29 23:00



क्या 40 9 संघर्ष प्रतिक्रिया किसी ऐसे उपयोगकर्ता के साथ एक नया खाता बनाने की कोशिश करने के लिए उपयुक्त कोड होगी जो पहले से मौजूद है? मैं विशेष रूप से वर्जनिंग विवादों के लिए 40 9 का उपयोग कर रहा हूं, लेकिन आपके उत्तर को पढ़ने के बाद, मुझे आश्चर्य है कि इसका उपयोग किसी भी "डुप्लिकेट" अनुरोधों के लिए नहीं किया जाना चाहिए। - Eric B.
@EricB। हां, स्थिति में आप "संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण" वर्णन करते हैं, ऑपरेशन विफल रहता है। इसके अतिरिक्त, यह अपेक्षा करना उचित है कि उपयोगकर्ता संघर्ष को हल कर सकता है और संदेश निकाय को केवल उपयोगकर्ता को सूचित करने की आवश्यकता है कि उपयोगकर्ता नाम पहले से मौजूद है। - Joshcodes
@ जोशकोड आप संघर्ष समाधान प्रक्रिया के बारे में और अधिक कह सकते हैं? इस मामले में, यदि उपयोगकर्ता नाम पहले से मौजूद है, तो ग्राहक को अंतिम उपयोगकर्ता को अलग उपयोगकर्ता नाम के लिए संकेत देने की उम्मीद है? क्या होगा यदि ग्राहक वास्तव में उपयोगकर्ता नाम बदलने के लिए POST का उपयोग करने का प्रयास कर रहा है? क्या अनुरोधों को अभी भी पैरामीटर अपडेट करने के लिए उपयोग किया जाना चाहिए, जबकि POST का उपयोग वस्तुओं को बनाने के लिए किया जाता है चाहे वह एक समय या कई में हो? धन्यवाद। - BFar
@ BFar2 यदि उपयोगकर्ता नाम पहले से मौजूद है तो क्लाइंट को उपयोगकर्ता को संकेत देना चाहिए। उपयोगकर्ता नाम बदलने के लिए, मान लीजिए कि उपयोगकर्ता नाम पहले से बनाए गए संसाधन का हिस्सा है जिसे संशोधित करने की आवश्यकता है, PUT का उपयोग किया जाएगा क्योंकि आप सही हैं, POST का उपयोग हमेशा के लिए, हमेशा और PUT अपडेट के लिए किया जाता है। - Joshcodes
छोटी और प्रभावी भाषा का उपयोग करके चीजों को समझाते हुए भी एक वांछनीय कौशल है - Junchen Liu