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




post put (20)

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

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

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

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

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

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


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

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

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


सारांश:

सर्जन करना:

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

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

डाल

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

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

संदर्भ:


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

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

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

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

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

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

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929

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

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

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

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

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


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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

सादृश्य:

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


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

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

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

क्योंकि पुट और प्राप्त करें और एक संसाधन का संदर्भ लें, वे परिभाषा idempotent भी हैं।

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

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

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

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


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

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

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


रेल 4.0 पर रूबी आंशिक अपडेट करने के लिए PUT की बजाय 'पैच' विधि का उपयोग करेगा।

आरएफसी 578 9 पैच के बारे में कहते हैं (1 99 5 से):

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

" एज रेल: अद्यतन के लिए पैच नई प्राथमिक 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 पर एक नज़र डालें जो सर्वोत्तम प्रथाओं का सारांश देता है।


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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





put