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




post put (25)

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

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

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

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

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

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


Answers

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

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

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

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

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

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

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

संपादित करें

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

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

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

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


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

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

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

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

  • 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।


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

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

लंबा जवाब:

पद:

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

डाल:

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

लंबा जवाब:

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

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

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


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

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


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


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

सादृश्य:

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


कुल मिलाकर:

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

आपको पूछना है कि "आप क्या कर रहे हैं?" यह समझने के लिए कि आपको क्या उपयोग करना चाहिए। आइए मान लें कि आप प्रश्न पूछने के लिए एक एपीआई डिजाइन कर रहे हैं। यदि आप 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/

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

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

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

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

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


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

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

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

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

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

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

इसलिए:

POST /expense-report

या:

PUT  /expense-report/10929

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

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

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

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

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

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

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


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

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

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


संक्षेप में:

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

चलो यहाँ बहुत स्पष्ट और प्रत्यक्ष हो। यदि आप वेब एपीआई के साथ काम कर रहे .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 का उपयोग करते हैं, आईआरआई को कोई संसाधन नहीं दिया गया है, और आप वैसे भी संसाधन बनाना चाहते हैं। उदाहरण के लिए, PUT /users/123/passwordआमतौर पर पुराने पासवर्ड को एक नए से बदल देता है, लेकिन यदि आप पहले से मौजूद नहीं हैं तो पासवर्ड बनाने के लिए इसका उपयोग कर सकते हैं (उदाहरण के लिए, ताज़ा पंजीकृत उपयोगकर्ताओं द्वारा या प्रतिबंधित उपयोगकर्ताओं को बहाल करके)।


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

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

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


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

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

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

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

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

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

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

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

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

" एज रेल: अद्यतन के लिए पैच नई प्राथमिक HTTP विधि है " इसे समझाता है।


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

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

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

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


किसी 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 पढ़ें ।


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


नामकरण सम्मेलनों के साथ, यह आमतौर पर कहने के लिए सुरक्षित है "बस एक चुनें और इसे चिपकाएं", जो समझ में आता है।

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

और उस संदर्भ में, भाषाई नियम केवल आपको निम्न तक ही प्राप्त कर सकते हैं:

एक निर्देशिका में कई फाइलें और / या उप-निर्देशिकाएं हो सकती हैं, और इसलिए इसका नाम बहुवचन रूप में होना चाहिए।

और मुझे वह पसंद है।
हालांकि, दूसरी ओर - यह आपकी निर्देशिका है, यदि आप यही चाहते हैं तो आप इसे "ए-रिसोर्स-या-बहु-संसाधन" नाम दे सकते हैं। यह वास्तव में महत्वपूर्ण बात नहीं है।

महत्वपूर्ण बात यह है कि यदि आप "संसाधन" नामक निर्देशिका के तहत "123" नामक एक फ़ाइल डालते हैं (जिसके परिणामस्वरूप /resourceS/123 ), तो आप उम्मीद नहीं कर सकते कि यह /resource/123 माध्यम से सुलभ हो।

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

नोट: तकनीकी रूप से, आप "प्रतीकात्मक लिंक" बना सकते हैं, ताकि /resources/123 माध्यम से भी पहुंचा जा सके, लेकिन पूर्व में अभी भी मौजूद होना चाहिए!





http rest post put