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




post put (24)

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

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

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

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

यही है, PUT का निर्माण या अद्यतन करने के लिए प्रयोग किया जाता है।

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


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

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

लंबा जवाब:

पद:

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

डाल:

  • पुट का उपयोग सर्वर को सर्वर में स्थानांतरित करने के लिए किया जाता है
  • जब संसाधन का यूआरएल ज्ञात होता है तो उपयोगी

लंबा जवाब:

इसे समझने के लिए हमें सवाल पूछने की जरूरत है कि पुट की आवश्यकता क्यों थी, पीयूटी समस्या को हल करने की कोशिश कर रहा था, जो समस्याएं हल नहीं कर पा रही थीं।

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

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


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

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

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

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

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

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

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929

संक्षेप में:

पुट बेवकूफ है, जहां एक ही ऑपरेशन एक बार या कई बार निष्पादित किया जाता है, तो संसाधन स्थिति वही होगी।

पोस्ट गैर-बेवकूफ है, जहां एक बार निष्पादित करने की तुलना में ऑपरेशन को कई बार निष्पादित किया जाता है, तो संसाधन स्थिति अलग हो सकती है।

डेटाबेस क्वेरी के साथ एनालॉजी

PUT आप "अद्यतन छात्र सेट पता =" abc "के समान सोच सकते हैं जहां id =" 123 ";

पोस्ट आप "स्टूडेंट (नाम, पता) VALUES (" एबीसी "," xyzzz ") में" INSERT "जैसे कुछ के बारे में सोच सकते हैं;

छात्र आईडी ऑटो उत्पन्न है।

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

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

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

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


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

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

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

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

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

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

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

उपरोक्त idempotent परिभाषा के आधार पर, आरईएसटी सेवाओं के लिए HTTP POST विधि का उपयोग कर HTTP PUT विधि बनाम मेरा उपयोग करने पर मेरा है: 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 पोस्ट विधि का उपयोग करें जब:

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.

निष्कर्ष

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


  • एक यूआरएल के लिए पोस्ट एक सर्वर परिभाषित यूआरएल पर एक बाल संसाधन बनाता है
  • किसी URL पर PUT क्लाइंट परिभाषित यूआरएल पर पूरी तरह से संसाधन को बनाता / बदलता है
  • एक यूआरएल के लिए पैच उस क्लाइंट परिभाषित यूआरएल पर संसाधन का हिस्सा अद्यतन करता है

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

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

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

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

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

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

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

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


नया जवाब (अब मैं आरईएसटी बेहतर समझता हूं):

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

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

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

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

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

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

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

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

POST /something: "जो कुछ मैं आपको देता हूं उसे ले लो और /somethingजब तक आप पूरा कर लेंगे तब तक आप मुझे अपना यूआरएल दें।"


कुल मिलाकर:

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

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

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

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

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

कुछ विचार:

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

एक उदाहरण:

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

पद:

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

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/

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

डाल:

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

संपादित करें

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

जिसका अर्थ है कि आपको जमा करना है

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

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


सारांश:

सर्जन करना:

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

डाल

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

PUT /resources/<newResourceId> HTTP/1.1 

पद

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

POST /resources HTTP/1.1

अद्यतन करें:

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

डाल

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

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

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

युक्ति:

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

पद

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

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

डाल

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

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

संदर्भ:


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

चलो यहाँ बहुत स्पष्ट और प्रत्यक्ष हो। यदि आप वेब एपीआई के साथ काम कर रहे .NET डेवलपर हैं, तो तथ्य हैं (माइक्रोसॉफ्ट एपीआई दस्तावेज से), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations :

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 अद्यतन के लिए है कोई बहस नहीं है।

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


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

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

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

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

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

संसाधन बनाने के लिए 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 में पोस्ट के लिए संभावित प्रतिक्रिया का पालन करता है

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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


मुझे यह सलाह पसंद है, आरएफसी 2616 की पीयूटी की परिभाषा से :

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

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

मैं इसकी व्याख्या करता हूं, और पुट पर बेवकूफता आवश्यकताओं का अर्थ यह है कि:

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

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

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

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


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

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

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

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

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


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

सादृश्य:

  • यानी ले लो और कहां रखा गया था।
  • पोस्ट ऑफिस में मेल भेजने के रूप में पोस्ट करें


पोस्ट मेलबॉक्स में एक पत्र पोस्ट करना या ईमेल कतार में ईमेल पोस्ट करना है। PUT ऐसा लगता है जब आप किसी ऑब्जेक्ट को एक क्यूबबी होल या शेल्फ पर एक स्थान डालते हैं (यह एक ज्ञात पता है)।

पोस्ट के साथ, आप QUEUE या संग्रह के पते पर पोस्ट कर रहे हैं। पुट के साथ, आप आइटम के पते पर डाल रहे हैं।

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

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





put