संसाधन के प्रतिनिधित्व को वापस करने के लिए सर्वोत्तम प्रथाएं जो संग्रह भी है

Question

मान लें कि मैं एक विश्वसनीय इंटरफ़ेस बनाना चाहता हूं, और मैं foo एस के साथ अपनी आईडी के आधार पर काम करना चाहता हूं। यहां कोई नई बात नहीं:

• GET /api/foo1 प्रतिनिधित्व foo1 की (जैसे JSON का उपयोग कर) देता है।
• DELETE /api/foo1foo1 हटा देता है।

आदि

अब मैं आपको बता दूँ कि एक "foo" एक संग्रह प्रकार बात कर रही है। तो मैं एक "foo" करने के लिए एक "बार" जोड़ने के लिए सक्षम होना चाहते हैं:

• PUT /api/foo1/bar3foo1 को bar3 कहते हैं।
• GET /api/foo1/bar3foo1 का प्रतिनिधित्व देता है।
• DELETE /api/foo1/bar3bar3foo1 से हटा देता है।
• DELETE /api/foo1foo1 पूरी तरह हटा देता है।

अब प्रश्न बना रहता है: GET /api/foo1 क्या करता है? क्या यह मूल रूप से इस प्रश्न में माना गया है कि यह foo1 का प्रतिनिधित्व देता है? या यह सलाखों की एक सूची वापस करता है? या क्या यह foo1 का प्रतिनिधित्व करता है जो foo1 के साथ-साथ दोनों में सभी निहित बारों की एक सूची शामिल है?

या GET /api/foo1 केवल foo1 का प्रतिनिधित्व लौटना चाहिए जैसा कि मैंने शुरू में ग्रहण किया, और foo1 (दृष्टिकोण WebDAV द्वारा लिया) के अंदर सलाखों सूची एक PROPFIND अनुरोध की आवश्यकता होती है? लेकिन फिर सुसंगत होने के लिए, क्या मुझे अपनी सभी अन्य सूची-प्रकार की कार्यक्षमता को PROPFIND में बदलना नहीं होगा, सामग्री की सूची के लिए GET /api/foo1 का उपयोग करने वाले सभी हजारों रीस्टफुल ट्यूटोरियल का सीधे विरोध करना होगा?

Answer 1

वेबडाव के अर्थशास्त्र को वास्तव में रीस्टफुल इंटरफेस के मुहावरों से कभी मेल नहीं मिला है।

सिद्धांत रूप में, GET को संसाधन की स्थिति का प्रतिनिधित्व प्राप्त करना चाहिए और संग्रह के सदस्यों को पुनर्प्राप्त करने के लिए PROPFIND का उपयोग किया जाना चाहिए।

तो आप इस करना चाहिए:

• प्राप्त/API/foo1/- रिटर्न foo1 के राज्य केवल
• PROPFIND/API/foo1/- foo1

के सदस्यों रिटर्न अधिकांश यदि आप उन्हें PROPFIND का उपयोग करने के लिए कहते हैं, तो फ्रंट एंड देव्स फिक्र आउट हो जाएंगे, हालांकि यह ब्राउज़र जेएस कार्यान्वयन में पूरी तरह से समर्थित है।

निजी तौर पर मैं एक WebDAV/json प्रवेश द्वार है, जहां अनुरोध RESTful मुहावरे का उपयोग किया जाता है, लेकिन मेरी WebDAV कार्यान्वयन के लिए रूट का उपयोग

उदाहरण के लिए मैं यह नहीं होगा:

GET /api/foo1/_PROPFIND?fields=name,fooProp1,fooProp2 

और वह

वापसी होगी

[ 
{ name : "bar1", fooProp1: "..", fooProp2 : ".."}, 
{ name : "bar2", fooProp1: "..", fooProp2 : ".."} 
] 

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

Answer 2

रीस्टफुल एपीआई में मार्ग और उनके संचालन पूरी तरह डेवलपर्स द्वारा डिजाइन किए गए हैं। यह डेवलपर है जो एक विशिष्ट मार्ग का अनुरोध करते समय वापस लौटने का फैसला करता है, GET /api/foo1।

और डेवलपर को /api/foo1/bar सहित प्रत्येक मार्ग को डिज़ाइन करना चाहिए। किसी विशेष मार्ग को क्या करना चाहिए इस पर कोई विशिष्ट नियम नहीं है। यदि आपका एपीआई एक ओपन-सोर्स प्रोजेक्ट है तो हर रूट का एक साफ और स्पष्ट दस्तावेज बनाएं।

पुरानी स्कूल की रणनीतियों के बारे में सोचने में अपना समय बर्बाद न करें।

Answer 3

कुछ सोचने के बाद, मुझे लगता है कि एक विश्वसनीय परिप्रेक्ष्य से सबसे अच्छा वैचारिक स्पष्टीकरण यह है कि आम तौर पर "चीज़" इसके "संग्रह" जैसी ही नहीं है। इसलिए WebDAV दुनिया में एक directory/ वही चीज हो सकती है जो अपनी फाइलें रखती है, यथार्थवादी दुनिया में मेरे पास निहित फ़ाइलों के लिए अलग directory/files/ उपपथ हो सकता है। इस तरह से मैं फ़ाइलों को अलग से निर्देशिका से अलग कर सकता हूं।

बार्न युक्त एक खेत के लिए एक विश्वसनीय API पर विचार करें। एंडपॉइंट farm/api/barns/ बार्न की एक सूची वापस कर सकता है, जिसमें से एक farm/api/barns/bigredbarn होगा। नैतिक रूप से मुझे लगता है कि farm/api/barns/bigredbarn/ को पुनर्प्राप्त करने से मुझे बर्न में जानवरों की एक सूची प्रदान की जाएगी, जो इस सवाल को प्रेरित करती है।

लेकिन वास्तव में बर्न में जानवर बिग रेड बार्न का केवल एक पहलू है।

• farm/api/barns/bigredbarn/animals/
• farm/api/barns/bigredbarn/vehicles/
• farm/api/barns/bigredbarn/haybales/

इस दृष्टिकोण दुविधा मैं का सामना करना पड़ा ही नहीं उठता साथ

: यह वाहनों और घास हो सकता है।