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





15 Answers

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

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

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

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

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

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

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929
http rest post put

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

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

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

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

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

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




सारांश:

सर्जन करना:

निम्नलिखित तरीके से 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 विधि का अनुरोध यह अनुरोध करने के लिए किया जाता है कि मूल सर्वर अनुरोध-संलग्न में अनुरोध-यूआरआई द्वारा पहचाने गए संसाधन के नए अधीनस्थ के रूप में अनुरोध में संलग्न इकाई को स्वीकार करता है

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

डाल

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

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

संदर्भ:




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

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

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

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

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

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




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

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

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

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

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




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

सादृश्य:

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




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

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

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

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




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

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 का उपयोग करें।

लंबा जवाब:

पद:

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

डाल:

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

लंबा जवाब:

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

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

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




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

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

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

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

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



आरईएसटी सेवाओं के लिए 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 विधि का उपयोग करें।




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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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




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

चलो यहाँ बहुत स्पष्ट और प्रत्यक्ष हो। यदि आप वेब एपीआई के साथ काम कर रहे .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 अद्यतन के लिए है कोई बहस नहीं है।

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




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




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

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

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

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

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

संपादित करें

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

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

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

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




Related