मैं सुझाव दूंगा कि आप ऑटो-वृद्धि कुंजी के लिए POST नहीं, PUT का उपयोग करें, या संसाधन आईडी में ऑटो-वृद्धि कुंजी का उपयोग न करें।
यदि आप पोस्ट का उपयोग करते हैं, तो आप /users/1 के बजाय /users पर पोस्ट करेंगे। उत्तर आपको /users/1 या जो कुछ भी आईडी पर रीडायरेक्ट कर सकता है।
यदि आप PUT का उपयोग करते हैं, तो आप /users/10292829 पर डाल सकते हैं जहां संख्या क्लाइंट पर उत्पन्न एक अद्वितीय संसाधन कुंजी है। यह कुंजी समय-उत्पन्न हो सकती है, या यह आपके ग्राहक दर्शकों के मूल्य की विशिष्टता की गारंटी के लिए समय, सत्र आईडी और कुछ अन्य कारकों का हैश हो सकता है। सर्वर तब 10292829 या जो कुछ भी अलग हो, अपनी स्वयं की ऑटो-वृद्धि वाली अनुक्रमणिका उत्पन्न कर सकता है।
कि अधिक जानकारी के लिए, PUT vs POST in REST
अप के बाद देखते हैं। । ।
सभी उपयोगकर्ताओं के लिए PUT/उपयोगकर्ताओं/XXXXXXX की अनुमति देने के मामले में, आप दो अलग-अलग अद्वितीय कुंजी के साथ समाप्त हो जाएंगे जो समान संसाधन को संदर्भित करते हैं। (10292829 और 1 एक ही उपयोगकर्ता को संदर्भित कर सकते हैं)। आपको यह तय करना होगा कि आरईएसटी-स्टाइल यूआरएल में इन अलग-अलग कुंजियों में से प्रत्येक के उपयोग की अनुमति कैसे दी जाए। इन दो अलग-अलग आईडी के उपयोग को सुलझाने की आवश्यकता के कारण, मैं पहले विकल्प का उपयोग करना चाहता हूं, /users पर पोस्ट करना और प्रतिक्रिया में बनाए गए संसाधन का एक अद्वितीय आरईएसटी यूआरएल प्राप्त करना चाहता हूं।
मैं सिर्फ फिर से पढ़ the relevant section of RFC 2616, और विशेष रूप से बाकी अनुप्रयोगों में इस के लिए बनाया गया एक वापसी कोड देखा:
10.2.2 201
बनाया अनुरोध को पूरा किया गया है और एक नया संसाधन में हुई बनाया जा रहा है। नव निर्मित संसाधन को संदर्भ की इकाई में लौटाए गए यूआरआई द्वारा संदर्भित किया जा सकता है, जिसमें स्थान शीर्षलेख फ़ील्ड द्वारा दिए गए संसाधन के लिए सबसे विशिष्ट यूआरआई है। प्रतिक्रिया में संसाधन विशेषताओं और स्थान (ओं) की एक सूची वाली एक इकाई शामिल होनी चाहिए जिससे उपयोगकर्ता या उपयोगकर्ता एजेंट सबसे उपयुक्त विकल्प चुन सकें। इकाई प्रारूप सामग्री प्रकार प्रकार हेडर फ़ील्ड में दिए गए मीडिया प्रकार द्वारा निर्दिष्ट किया गया है।201 सर्वर कोड कोड लौटने से पहले मूल सर्वर को संसाधन बनाना होगा। यदि कार्रवाई तुरंत नहीं की जा सकती है, तो सर्वर को इसके बजाय 202 (स्वीकृत) प्रतिक्रिया के साथ जवाब देना चाहिए।
तो, जाने के लिए RESTful रास्ता /users को पोस्ट और एक 201 Created लौटने के लिए, एक Location: हैडर /users/1 निर्दिष्ट करने के साथ है।
मेरा आरईएसटी एपीआई वर्तमान में POST का समर्थन करता है लेकिन मैं अपडेट को अनुमति देने के लिए PUT का भी समर्थन करना चाहता हूं। तो ग्राहक पक्ष से अद्वितीय आईडी को पारित करने की जटिलता से बचने के लिए अगर इसे बनाने का प्रयास करने के बजाय संसाधन मौजूद नहीं है तो बस 404 वापस कर दें? क्या यह अभी भी भरोसेमंद माना जाएगा? – James
हां, 'पुट' अपडेट के लिए डिज़ाइन किया गया है। यदि यूआरआई जिस पर पुट भेजा जाता है, वह उपलब्ध संसाधन का संदर्भ नहीं देता है, तो 404 वापस लौटने की उचित बात है। यदि यह आरईएसटी/जेएसओएन है, तो आप प्रतिक्रिया के संदेश निकाय में जेसन प्रारूप में एक त्रुटि संदेश शामिल कर सकते हैं। '{" त्रुटि ":" संसाधन मौजूद नहीं है। "}'। लेकिन वास्तव में, संदेश निकाय में जानकारी भेजना केवल तभी उचित होता है जब यह उस स्थिति में जोड़ता है जो स्टेटस कोड बताता है। यदि संदेश मौजूद नहीं है, तो 404 पर्याप्त है, और कोई संदेश निकाय आवश्यक नहीं है। – Cheeso
कूल, वास्तव में 'पुट' के साथ आपके पास यह विकल्प है कि आप बनाना चाहते हैं या नहीं (जो मैं वास्तव में स्पष्टीकरण की तलाश में था)। मेरे परिदृश्य में सोचने के बाद 'PUT' का उपयोग पूरी तरह से अद्यतन करने के लिए किया जाएगा (यदि संसाधन मौजूद है)। धन्यवाद! – James