RESTful API में ट्रेलिंग स्लैश

Question

मुझे Restful API में ट्रेलिंग स्लैश के साथ क्या करना है, इस पर बहस चल रही है।

आइए कहते हैं कि मेरे पास कुत्तों के लिए एक संसाधन है और व्यक्तिगत कुत्तों के लिए अधीनस्थ संसाधन हैं। इसलिए हम निम्न कार्य कर सकते हैं:

GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}

लेकिन हम निम्नलिखित विशेष मामले के साथ क्या करते हैं:

GET/PUT/POST/DELETE http://example.com/dogs/

मेरा व्यक्तिगत विचार है कि यह कह रहा है कि आईडी = के साथ एक व्यक्तिगत कुत्ते के संसाधन के लिए एक अनुरोध भेजें null। मुझे लगता है कि एपीआई को इस मामले में 404 लौटाना चाहिए।

अन्य लोगों का कहना है कि अनुरोध कुत्तों के संसाधन तक पहुंच रहा है अर्थात अनुगामी स्लैश को अनदेखा किया गया है।

क्या कोई निश्चित उत्तर जानता है?

Comments

मुझे लगा कि Restful तरीका कुत्ते / आईडी और कुत्तों (सभी कुत्तों का अर्थ) के बीच अंतर करना था।

— पीडीआर

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

— Gaz_Edge

यह कुत्ते के संसाधन तक पहुंच बना रहा है, अनुगामी स्लैश को अनदेखा किया जाना चाहिए, जिसका अर्थ है कि कुछ को हटाने की कोशिश करने के लिए निषिद्ध प्रतिक्रिया मिलनी चाहिए, जिसे हटाने के लिए लागू नहीं किया जाना चाहिए। मुझे लगता है कि 404 भी स्वीकार्य है। हालांकि यह बात करता है?

— बेंजामिन Gruenbaum

मैं अनुसरण नहीं करता - किसने कहा कि आप कुत्तों को नहीं हटा सकते? यदि आप कुत्तों को हटाते हैं तो यह स्वयं और सभी व्यक्तिगत कुत्तों को हटा देता है। इसलिए मुझे लगता है कि कुत्तों को कॉल करने की अनुमति देना जोखिम भरा है। क्या होगा यदि क्लाइंट का मतलब किसी व्यक्तिगत कुत्ते को हटाना है, लेकिन गलती से {आईडी} छोड़ दिया गया। इसका परिणाम यह होगा कि सभी कुत्तों को हटा दिया जाएगा। यह मानने के लिए अधिक सुरक्षित है कि यह {आईडी} अशक्त है और 404

— लौटाता है

मैं इलाज करता हूँ dogsऔर dogs/बराबर। मेरे लिए यह स्पष्ट है कि dogs/एक निर्देशिका है जिसमें अलग-अलग कुत्ते हैं। इसकी कम स्पष्टता क्या dogsहै, लेकिन मैं इसे समकक्ष मानूंगा, जैसे अधिकांश वेबसर्वर अनुगामी के बिना निर्देशिकाओं तक पहुंच स्वीकार करते हैं /।

— कोडइन्चोज

Answer 1

इसमें से कोई भी आधिकारिक नहीं है (क्योंकि REST का कोई सटीक अर्थ नहीं है)। लेकिन मूल कागज पर REST पर पूर्ण (/ में समाप्त नहीं होने वाला) URL एक संसाधन का नाम देता है, जबकि एक स्लैश '/' में समाप्त होने वाला एक संसाधन समूह है (शायद इस तरह शब्द नहीं है)।

URL का एक GET अंत में स्लैश के साथ उपलब्ध संसाधनों को सूचीबद्ध करने वाला है।

GET http://example.com/dogs/          /* List all the dogs resources */

एक स्लैश वाले URL पर PUT को सभी संसाधनों को बदलने के लिए माना जाता है।

PUT http://example.com/dogs/          /* Replace all the dogs resources */

एक स्लैश वाले URL पर DELETE सभी संसाधनों को हटाने वाला है

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

एक स्लैश वाले URL पर एक POST एक नया संसाधन बनाने वाला है जिसे बाद में एक्सेस किया जा सकता है। नए संसाधन के अनुरूप होने के लिए इस निर्देशिका में होना चाहिए (हालांकि बहुत सारे वास्तुशिल्प यहां धोखा देते हैं)।

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

आदि।

विषय पर विकी पृष्ठ इसे अच्छी तरह समझाता है:

उदाहरण देखें https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services ।

Comments

यह सामान्य पथ / url मॉडल को भी फिट करता है, जहां निर्देशिकाओं को अक्सर अनुगामी के साथ लिखा जाता है/

— CodesInChaos

यदि आप बिना अनुगामी संसाधन समूह का उपयोग करते हैं तो क्या होना चाहिए /?

— oberlies

@ रॉबर्ट्स: यह संदर्भ पर निर्भर करता है। कोई कठिन और तेज़ नियम केवल सर्वोत्तम अभ्यास नहीं हैं। नियम के लिए हमेशा विस्तार होता है और इसका मतलब यह होना चाहिए कि आप इसका मतलब क्या है। ऊपर दिए गए उदाहरण में: GET http://example.com/dogsकुत्तों के बारे में मेटा जानकारी वापस कर सकते हैं (स्वयं सूची नहीं बल्कि कुत्तों की सूची के बारे में मेटा जानकारी)। हो सकता है या शायद इसकी त्रुटि हो।

— मार्टिन

As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. It’s better to drop them completely.यह एकमात्र स्थान नहीं है जो प्रशिक्षण स्लैश का उपयोग न करने का सुझाव देता है

— Laiv

@Laiv मैं भावुकता से असहमत नहीं हूँ। लेकिन कृपया अधिक आधिकारिक संदर्भ लिंक करें (यह एक कमजोर कड़ी है)।

— मार्टिन यॉर्क

Answer 2

Does anyone know the definitive answer?

ऐसा नहीं है क्योंकि रेस्टफुल माना जाने वाली सेवा के लिए जो आवश्यक है, उस पर कोई आधिकारिक दस्तावेज नहीं है।

मैंने कहा कि मैं आसानी से उपयोग के लिए अनुगामी स्लैश की अनुमति दूंगा। जबकि तकनीकी रूप से यह कहा जा सकता है कि एक कुत्ते को एक नल आईडी के साथ प्रवेश करने के प्रयास के रूप में देखा जा सकता है; जब तक वे आपके दस्तावेज़ में इसे नहीं पढ़ लेते, मैं किसी उपयोगकर्ता को यह छलांग लगाते नहीं देखता। मैं एक उपयोगकर्ता को आपके एपीआई के खिलाफ कोड लिखने का प्रयास करता देख सकता हूं और इसमें बस आदत से स्लेश शामिल है और सोच रहा हूं कि जब वे कुत्तों की सूची चाहते हैं तो उन्हें 404 प्रतिक्रिया क्यों मिलती है।

Comments

DELETE example.com/dogs के बारे में क्या ?

— बेंजामिन ग्रुएनबाम

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

— Gaz_Edge

@Gaz_Edge: REST example.com/dogsएक संसाधन है जो किसी भी संसाधन से पूरी तरह स्वतंत्र है example.com/dogs/X। इस प्रकार एक DELETE को example.com/dogsसभी कुत्तों / * को हटाना नहीं है (हालांकि यह हो सकता है कि यह शब्दार्थ है)। लेकिन DELETE example.com/dogs/को सभी कुत्तों / * को हटाना चाहिए।

— मार्टिन यॉर्क

मैं एक बार फिर से कहूंगा कि चूंकि नियम का कोई निश्चित सेट नहीं है, इसलिए जब आप DELETE / कुत्ते या / कुत्ते / कुत्ते को देखते हैं तो क्या होता है, यह इस बात पर आधारित होगा कि आप अपने API के उपभोक्ताओं से क्या अपेक्षा रखते हैं। क्या यह संभावना है कि वे वास्तव में एक अनुरोध के साथ सभी कुत्तों को हटाना चाहेंगे? यदि हां, तो इसे इस तरह से लागू करें, यदि नहीं तो 405 मेथड नॉट अलाउड रिस्पॉन्स दें।

— माइक

मुझे पता है कि यह एक पुराना धागा है, लेकिन मैं हाल ही में इस बारे में सोच रहा हूं। के लिए क्या इसके लायक है, ओएस एक्स बैश खोल व्यवहार करता है foo, foo/और foo////हूबहू। यह मूल रूप से खाली पथ खंडों को अलग करने के लिए लगता है। इसलिए, यदि आप अपनी REST सेवा के साथ एक ही दृष्टिकोण का पालन करते हैं, dogsऔर dogs/एक ही चीज़ का उल्लेख करेंगे।

— ग्रेग ब्राउन

Answer 3

दो तरीके।

विधि 1

हमेशा किसी भी संसाधन के लिए ट्रेलिंग स्लैश का उपयोग करें जिसमें बच्चे शामिल हो सकते हैं।

फ़ाइलों के साथ public_html निर्देशिका पर बस "GET" पर विचार करें।

यह संभव नहीं है जब hello.html एक फाइल हो:

/hello.html
/hello.html/youagain.html

लेकिन संभव है जब hello.html एक निर्देशिका हो:

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

तो अगर "hello.html" के बच्चे कभी भी हो सकते हैं तो यह हमेशा और हमेशा के लिए है "/hello.html/" और "/hello.html/index.html" (या बस /hello.html/) इन बच्चों की एक सूची है ।

विधि 2

होशियार बनो"।

$ find
.
./hello.html
./hello.html/index.html

खोज आदेश hello.html के प्रकार के बारे में परवाह नहीं करता है। निर्देशिका या फ़ाइल, कौन परवाह करता है, यह एक वस्तु का नाम है। जब हम "cp youagain.html hello.html" लिखते हैं, तो cp यह पता लगा सकता है कि hello.html को कैसे संभालना है। cp स्मार्ट है। आपका वेबसर्वर भी स्मार्ट है। इसमें एक पथ हैंडलिंग लाइब्रेरी है। यह मार्ग है। यह स्टेट कर सकता है और आपको बता सकता है कि कोई नाम एक वस्तु या निर्देशिका है। यह blah को blah पर पुनर्निर्देशित कर सकता है / या यहां तक ​​कि दोनों के लिए एक ही प्रतिक्रिया दे सकता है। यह कमाल है !!! मार्ग। इतनी टेक। जब हम सब कुछ कर सकते हैं, तो हम किस तरह से पथ संकरा करना चाहते हैं ???