रीस्ट एपीआई बेस्ट प्रैक्टिस: मापदंडों को कहां रखा जाए? [बन्द है]

Question

REST API में कम से कम दो तरीके से पैरामीटर हो सकते हैं:

1. URL- पथ के भाग के रूप में (अर्थात /api/resource/parametervalue )
2. क्वेरी तर्क के रूप में (यानी /api/resource?parameter=value )

यहां सबसे अच्छा अभ्यास क्या है? क्या 1 का उपयोग करने के लिए और कब 2 का उपयोग करने के लिए कोई सामान्य दिशानिर्देश हैं?

वास्तविक दुनिया उदाहरण: ट्विटर अंतराल निर्दिष्ट करने के लिए क्वेरी मापदंडों का उपयोग करता है। ( http://api.twitter.com/1/statuses/home_timeline.json?since_id=12345&max_id=54321)

क्या इन मापदंडों को URL पथ में रखना बेहतर डिज़ाइन माना जाएगा?

Answer 1

यदि सर्वोत्तम प्रलेखित दस्तावेज हैं, तो मैंने उन्हें अभी तक नहीं पाया है। हालांकि, यहां कुछ दिशा-निर्देश दिए गए हैं जिनका उपयोग करते समय मैं यह निर्धारित करता हूं कि एक यूआरएल में पैरामीटर कहां रखें:

वैकल्पिक पैरामीटर क्वेरी स्ट्रिंग में डालने के लिए आसान होते हैं।

यदि आप 404 त्रुटि वापस करना चाहते हैं जब पैरामीटर मान किसी मौजूदा संसाधन के अनुरूप नहीं होता है तो मैं एक पथ खंड पैरामीटर की ओर रुख करूंगा। उदाहरण के लिए /customer/232जहां 232 एक वैध ग्राहक आईडी नहीं है।

यदि फिर भी आप एक खाली सूची वापस करना चाहते हैं तो जब पैरामीटर नहीं मिलता है तो मैं क्वेरी स्ट्रिंग मापदंडों का उपयोग करने का सुझाव देता हूं। जैसे/contacts?name=dave

यदि कोई पैरामीटर आपके यूआरआई स्थान के पूरे उपप्रकार को प्रभावित करता है तो एक पथ खंड का उपयोग करें। जैसे भाषा पैरामीटर /en/document/foo.txt बनाम/document/foo.txt?language=en

मैं एक क्वेरी पैरामीटर के बजाय पथ सेगमेंट में होने के लिए विशिष्ट पहचानकर्ता पसंद करता हूं।

URI के लिए आधिकारिक नियम इस RFC कल्पना में पाए जाते हैं । यहाँ एक और बहुत उपयोगी RFC युक्ति भी है जो URI के पैरामीटर के नियमों को परिभाषित करती है।

Comments

आधिकारिक नियम URI और ड्राफ्ट sepc वास्तव में उपयोगी और दिलचस्प थे! :-)

— काजमग्नस

404 त्रुटि परीक्षण मुझे क्वेरी पैरामीटर, हेडर या अनुरोध निकाय के पथ में जानकारी डालने से बचने में बहुत मदद करता है। इस बिंदु के लिए धन्यवाद!

— केविन कॉन्डन

Answer 2

देर से जवाब लेकिन मैं कुछ अतिरिक्त अंतर्दृष्टि जोड़ूंगा जो कि साझा की गई है, अर्थात् अनुरोध के लिए कई प्रकार के "पैरामीटर" हैं, और आपको इसे ध्यान में रखना चाहिए।

1. लोकेटर - जैसे संसाधन पहचानकर्ता जैसे आईडी या कार्रवाई / दृश्य
2. फ़िल्टर - जैसे पैरामीटर जो परिणामों के सेट को खोज, छँटाई या संकीर्ण करते हैं।
3. राज्य - उदाहरण सत्र पहचान, एपीआई कुंजी, whatevs।
4. सामग्री - उदाहरण के लिए संग्रहीत डेटा।

अब आइए उन विभिन्न स्थानों को देखें जहां ये पैरामीटर जा सकते हैं।

1. हेडर और कुकीज़ का अनुरोध करें
2. URL क्वेरी स्ट्रिंग ("GET" vars)
3. URL पथ
4. बॉडी क्वेरी स्ट्रिंग / मल्टीपार्ट ("POST" संस्करण)

आमतौर पर आप चाहते हैं कि राज्य हेडर या कुकीज़ में सेट हो, यह किस प्रकार की राज्य सूचना पर निर्भर करता है। मुझे लगता है कि हम सभी इस पर सहमत हो सकते हैं। जरूरत पड़ने पर कस्टम http हेडर (X-My-Header) का उपयोग करें।

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

लोकेटर जैसे "आईडी = 5" या "एक्शन = रिफ्रेश" या "पेज = 2" का अर्थ URL पथ के रूप में होगा, जैसे कि mysite.com/article/5/page=2जहां आंशिक रूप से आप जानते हैं कि प्रत्येक भाग का क्या अर्थ है (मूल बातें जैसे कि लेख और 5 जाहिर तौर पर मुझे आईडी 5 के साथ टाइप आर्टिकल का डेटा मिलता है) और अतिरिक्त पैरामीटर यूआरआई के हिस्से के रूप में निर्दिष्ट हैं। वे के रूप में हो सकते हैं page=2, या page/2यदि आप जानते हैं कि यूआरआई में एक निश्चित बिंदु के बाद "फ़ोल्डर" की-वैल्यूज हैं।

फिल्टर हमेशा क्वेरी स्ट्रिंग में जाते हैं, क्योंकि जब वे सही डेटा ढूंढने का एक हिस्सा होते हैं, तो वे केवल एक सबसेट या संशोधन को लौटाने के लिए वहां होते हैं जो लोकेटर अकेले लौटते हैं। mysite.com/article/?query=Obama(सबसेट) में खोज एक फिल्टर है, और इसलिए /article/5?order=backwards(संशोधन) है। यह क्या करता है के बारे में सोचो, न कि यह क्या कहा जाता है!

यदि "दृश्य" आउटपुट स्वरूप को निर्धारित करता है, तो यह एक फिल्टर ( mysite.com/article/5?view=pdf) है क्योंकि यह पाया गया संसाधन का एक संशोधन देता है जिसमें हम चाहते हैं कि संसाधन किस पर आधारित हैं। यदि इसके बजाय यह तय होता है कि लेख का कौन सा विशिष्ट भाग हमें देखने को मिलता है ( mysite.com/article/5/view=summary) तो यह एक लोकेटर है।

याद रखें, संसाधनों के एक सेट को कम करना फ़िल्टरिंग है। एक संसाधन के भीतर कुछ विशिष्ट का पता लगाने ... duh है। सबसेट फ़िल्टरिंग परिणाम के किसी भी संख्या को वापस कर सकता है (यहां तक ​​कि 0)। पता लगाने से हमेशा कुछ का विशिष्ट उदाहरण (यदि यह मौजूद है) मिलेगा। संशोधन फ़िल्टरिंग लोकेटर के समान डेटा को लौटाएगा, संशोधित को छोड़कर (यदि इस तरह के संशोधन की अनुमति है)।

आशा है कि इससे लोगों को कुछ यूरेका क्षण देने में मदद मिलेगी यदि वे खो गए हैं कि सामान कहाँ रखा जाए!

Comments

idफिर फिल्टर क्यों नहीं है? यह संसाधन का एक सबसेट लौटाता है

— जोनाथन।

@Jonathan। नहीं, यह एक विशिष्ट संसाधन देता है, अर्थात् लेख संख्या 5. एक फिल्टर हमेशा संसाधनों के संग्रह में खोज को कम करने का एक तरीका है। यदि आप केवल उस विशिष्ट संसाधन को चाहते हैं, तो उसे प्राप्त करने के लिए एक निर्दिष्ट तरीका होना चाहिए। फ़िल्टरिंग का मतलब है कि आपके पास कई संसाधनों को वापस करने की संभावना है। एक आईडी एक फिल्टर नहीं है, यह एक निश्चित एकल संसाधन है। यदि आपके पास आईडी की एक श्रेणी है, तो यह एक फिल्टर होगा, भले ही रेंज में सिर्फ एक आईडी शामिल हो। यदि फ़िल्टर में भी संसाधनों के प्रकार शामिल हैं, तो यह केवल लेख नहीं, बल्कि आईडी 5 के साथ सभी संसाधनों को लौटाएगा।

— Tor Valamo

@ जोनाथन: जैसे कि डारेलमिलर ने उल्लेख किया है, आप अज्ञात आईडी के मामले में 404 पर लौटने के लिए ऑब्जेक्ट / आईडी पर एक अनुरोध की उम्मीद करेंगे, जबकि आप ऑब्जेक्ट की उम्मीद करेंगे? आईडी = आईडी रिटर्न और खाली सूची। इसके अलावा, मैं इस बात पर विचार करूंगा कि किसी भी प्रकार का फ़िल्टरिंग / सब्मिटिंग एक सूची लौटा दे।

— njzk2

पृष्ठ एक कठिन है, क्योंकि जैसा कि आप कहते हैं कि यह एक संसाधन (पृष्ठों का संग्रह) का एक फिल्टर हो सकता है, लेकिन फिर उसी समय यह उस संग्रह के भीतर एक विशिष्ट संसाधन होता है। मैं हमेशा फ़िल्टर द्वारा नहीं, लोकेटर द्वारा एक लेख पृष्ठ का अनुरोध करूंगा। हालाँकि, पृष्ठ किसी चीज़ की सूची का फ़िल्टर हो सकता है, उपयोगकर्ताओं की सूची कह सकते हैं। लेकिन फिर पेज स्वाभाविक रूप से एक सीमांकक है, उर्फ ​​"आइटम पर शुरू करें और आइटम (page-1)*perpageदिखाएं perpage"। एक फिल्टर के रूप में इसका उपयोग करना सही है, लेकिन विभिन्न कारणों से। इसे "पेज" कहना तकनीकी रूप से गलत है। इसे "से" या "startAt" कहने के लिए अधिक शब्दार्थिक रूप से सही होगा

— Tor Valamo

(जारी) "पृष्ठ" का अर्थ यह है कि यह एक विशिष्ट संसाधन है जो बदलता नहीं है। यह फिजिकल प्रिंट से आता है। अगर हमारे पास किताबें या मुद्रित सामान नहीं थे, तो "पेज" वास्तव में एक शब्द नहीं होगा। यदि आपके पास वस्तुओं की एक गतिशील सूची है, तो "पृष्ठों" में विभाजित करें, आपको वास्तव में एक विशिष्ट प्रारंभिक बिंदु प्रदान करना चाहिए, या तो संख्यात्मक, वर्णमाला या यहां तक ​​कि आइटम-विशिष्ट, साथ ही साथ "प्रति पृष्ठ कितने" फ़िल्टर। अगर मैं आपकी सूची में कुछ संदर्भ देना चाहता हूं, तो मुझे विशेष जानकारी चाहिए। इसके अलावा, मैं केवल यह महसूस करने के लिए पेज 5 पर नहीं जाना चाहता कि आपने अब आंतरिक perpageको 20 के बजाय 50 में बदल दिया है।

— Tor Valamo

Answer 3

यह एक डिजाइन पर निर्भर करता है। HTTP पर REST में URI के लिए कोई नियम नहीं हैं (मुख्य बात यह है कि वे अद्वितीय हैं)। अक्सर यह स्वाद और अंतर्ज्ञान के मामले में आता है ...

मैं निम्नलिखित दृष्टिकोण अपनाता हूं:

• url path-element: संसाधन और इसका पाथ-एलिमेंट एक डायरेक्टरी ट्रैवर्सल और एक सबर्ससोर्स (जैसे / आइटम / {id}, / यूजर्स / आइटम) बनाता है। जब अनिश्चित अपने सहयोगियों से पूछते हैं, अगर उन्हें लगता है कि ट्रैवर्सल और वे "एक और निर्देशिका" में सोचते हैं, तो सबसे अधिक संभावना पथ-तत्व सही विकल्प है
• url पैरामीटर: जब कोई ट्रैवर्सल वास्तव में नहीं है (कई क्वेरी मापदंडों के साथ खोज संसाधन इसके लिए एक बहुत अच्छा उदाहरण हैं)

Comments

वास्तव में एक URI कैसे दिखना चाहिए, इस पर बहुत स्पष्ट नियम हैं, और उन्हें RESTful URI के लिए कैसे लागू किया जाए, इस पर बहुत कम अस्पष्टता है।

— डैनमैन

Answer 4

IMO पैरामीटर क्वेरी तर्क के रूप में बेहतर होना चाहिए। Url का उपयोग संसाधन की पहचान करने के लिए किया जाता है, जबकि अतिरिक्त क्वेरी पैरामीटर यह निर्दिष्ट करने के लिए कि आप कौन सा संसाधन चाहते हैं, किसी भी राज्य के पास संसाधन है, आदि।

Comments

दरअसल, संसाधन की पहचान करने के लिए संयोजन में पथ और क्वेरी दोनों का उपयोग किया जाता है। यह RFC 3986http://labs.apache.org/webarch/uri/rfc/rfc3986.html#query

— डारेल मिलर

@DarrelMiller मुझे पता है कि यह एक पुरानी पोस्ट है, लेकिन मुझे इस तथ्य के बारे में अधिक जानने की दिलचस्पी है कि संसाधन की पहचान करने के लिए क्वेरी पैरामीटर का भी उपयोग किया जाता है। आपके द्वारा प्रदत्त लिंक अब मृत हो गया है। मैंने RFC3986 को देखा है, लेकिन मैं यह नहीं देखता कि आपने इस तथ्य को कैसे घटाया। इसके अलावा, परिभाषा के अनुसार, एक पहचानकर्ता पैरामीटर वैकल्पिक नहीं होना चाहिए ताकि पहचान के लिए क्वेरी मापदंडों का उपयोग करना उचित न लगे।

— मिकेल मार्राच

@MickaelMarrache 3.4 अनुभाग में पहली पंक्ति देखें tools.ietf.org/html/rfc3986#section-3.4

— डेरेल मिलर

@DarrelMiller धन्यवाद! मेरा प्रश्न इस तथ्य से आता है कि आम तौर पर, मध्यस्थ HTTP घटक अनुरोधों की प्रतिक्रियाओं को कैश नहीं करते हैं जिसमें एक क्वेरी स्ट्रिंग होती है। इसलिए, ऐसा लगता है कि क्वेरी पैरामीटर कुछ मानदंडों के अनुसार खोज संसाधनों के लिए अधिक विनियोजित हैं और किसी संसाधन की विशिष्ट पहचान करने के लिए नहीं।

— मिकेल मार्राचे

Answer 5

बाकी कार्यान्वयन के अनुसार,

1) संसाधनों पर प्रत्यक्ष कार्रवाई के लिए पथ चर का उपयोग किया जाता है, जैसे संपर्क या गीत पूर्व ..
GET आदि / एपीआई / संसाधन / {गीत} या
GET आदि / एपीआई / संसाधन / { contactid} संबंधित डेटा लौटाएगा।

2) क्वेरी परमिट / तर्क का उपयोग प्रत्यक्ष संसाधनों के लिए किया जाता है जैसे किसी गीत का मेटाडेटा। .., GET / api / resource / {songid}? मेटाडेटा = शैलियों यह उस विशेष गीत के लिए शैली का डेटा लौटाएगा।

Comments

वास्तव में एक REST मानक नहीं है । प्रति विकिपीडिया : SOAP- आधारित वेब सेवाओं के विपरीत, RESTful वेब APIs के लिए कोई "आधिकारिक" मानक नहीं है। [१४] ऐसा इसलिए है क्योंकि REST SOAP के विपरीत एक वास्तुशिल्प शैली है, जो एक प्रोटोकॉल है। भले ही REST एक मानक नहीं है, फिर भी Restful कार्यान्वयन जैसे कि वेब HTTP, URI, XML, आदि जैसे मानकों का उपयोग कर सकता है

— DavidRR

मुझे 2 दृष्टिकोण पसंद नहीं है। मैं इसके बजाय प्रीफ़र / एपी / जींस / गाना चाहूंगा! गाने के लिए = 123 या / एपीआई / गाने / {गीत-आईडी} / शैलियों

— बार्ट कैलिक्सो

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

— ब्रेट कैसवेल

@BrettCaswell मिल गया! इस पर ध्यान दिलाने के लिए धन्यवाद। मैं इसकी प्रशंसा करता हूँ!

— बार्ट कैलीक्सो

Answer 6

"पैक" और अपने डेटा को उस "संदर्भ" के खिलाफ पोस्ट करें जो ब्रह्मांड-संसाधन-लोकेटर प्रदान करता है, जिसका अर्थ है लोकेटर के लिए # 1।

# 2 के साथ सीमाओं का ध्यान रखें। मैं POST को # 1 पसंद करता हूं।

नोट: सीमाओं के लिए चर्चा कर रहे हैं

POST क्या POST पैरामीटर सामग्री के लिए अधिकतम आकार है?

में मिलता है वहाँ एक GET अनुरोध की लंबाई की एक सीमा होती है? और _GET में URL मापदंडों का अधिकतम आकार

ps ये सीमाएँ क्लाइंट क्षमताओं (ब्राउज़र) और सर्वर (कॉन्फ़िगरेशन) पर आधारित हैं।

Comments

ऐड-ऑन: मजाकिया मार्गों संस्करणों (हेडर के माध्यम से प्रतिष्ठित) हो सकता है इस प्रकार बदलने कोड करने की कोई जरूरत के साथ विकसित कार्यक्षमता प्रदान कि खपत बाकी भरा (एपीआई) कोड है कि आप के रूप में लिखने restify -> संस्करणीकृत मार्गों के लिए देखो

— डीजीएम

Answer 7

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

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

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

• /users/123 तथा /users/123?fields="name, age"
• /users तथा /users?name="John"&age=30

मानचित्र को कम करने के लिए मुझे निम्नलिखित तरीकों का उपयोग करना पसंद है:

• /users?name="John"&age=30
• /users/name:John/age:30

तो यह वास्तव में आप (और आपके सर्वर साइड राउटर) पर निर्भर है कि आप अपने यूआरआई का निर्माण कैसे करते हैं।

नोट: बस इन मापदंडों का उल्लेख करने के लिए क्वेरी पैरामीटर हैं। तो आप वास्तव में क्या कर रहे हैं एक सरल क्वेरी भाषा को परिभाषित कर रहा है। जटिल प्रश्नों द्वारा (जिसमें ऑपरेटर जैसे और, या, से अधिक, आदि शामिल हैं) मैं आपको पहले से मौजूद क्वेरी भाषा का उपयोग करने का सुझाव देता हूं। URI टेम्प्लेट की क्षमताएं बहुत सीमित हैं ...

Answer 8

क्लाइंट-एंड पर एक प्रोग्रामर के रूप में, मैं क्वेरी तर्क पसंद करता हूं। साथ ही, मेरे लिए, यह URL पथ को मापदंडों से अलग करता है, स्पष्टता में जोड़ता है, और अधिक विस्तार प्रदान करता है। यह मुझे URL / URI भवन और पैरामीटर बिल्डर के बीच अलग-अलग तर्क रखने की भी अनुमति देता है।

मुझे पसंद है कि मानव अलदाना ने दूसरे विकल्प के बारे में कहा कि यदि कोई पेड़ शामिल है। मैं उपयोगकर्ता-विशिष्ट भागों को इस तरह से छेड़छाड़ करते हुए देख सकता हूं।

Answer 9

कोई कठिन और तेज़ नियम नहीं हैं, लेकिन विशुद्ध रूप से वैचारिक दृष्टिकोण से अंगूठे का नियम जो मैं उपयोग करना चाहता हूं, उसे संक्षेप में इस तरह से अभिव्यक्त किया जा सकता है: एक यूआरआई पथ (परिभाषा के अनुसार) एक संसाधन का प्रतिनिधित्व करता है और क्वेरी पैरामीटर अनिवार्य रूप से उस संसाधन पर संशोधक होते हैं । अब तक संभावना है कि मदद नहीं करता है ... एक REST API के साथ आप का उपयोग कर एक भी संसाधन पर काम के प्रमुख तरीकों GET, PUTऔर DELETE। इसलिए, क्या किसी चीज़ को मार्ग में दर्शाया जाना चाहिए या एक पैरामीटर के रूप में कम किया जा सकता है, क्या उन विधियों को प्रश्न में प्रतिनिधित्व के लिए समझ में आता है। क्या आप PUTउस रास्ते पर उचित रूप से कुछ करेंगे और ऐसा करने के लिए शब्दार्थ होगा? आप निश्चित रूप से PUTकहीं भी कुछ भी कर सकते हैं और इसे संभालने के लिए बैक-एंड को मोड़ सकते हैं, लेकिन आपको होना चाहिएPUTवास्तविक संसाधन के प्रतिनिधित्व के लिए मात्रा क्या है और इसके बारे में कुछ अनावश्यक रूप से प्रासंगिक संस्करण नहीं है। संग्रह के लिए उसी के साथ किया जा सकता है POST। यदि आप किसी विशेष संग्रह में जोड़ना चाहते हैं, तो ऐसा URL क्या होगा जिससे कोई मतलब POSTहो।

यह अभी भी कुछ ग्रे क्षेत्रों को छोड़ता है क्योंकि कुछ पथ माता-पिता के संसाधनों के बच्चों को क्या राशि दे सकते हैं जो कुछ हद तक विवेकाधीन है और उनके उपयोग पर निर्भर है। एक कठिन रेखा जो यह खींचती है कि किसी भी प्रकार का सकर्मक प्रतिनिधित्व एक क्वेरी पैरामीटर का उपयोग करके किया जाना चाहिए, क्योंकि इसमें अंतर्निहित संसाधन नहीं होगा।

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

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

Answer 10

यहाँ मेरी राय है

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

उदाहरण:

/calendar/2014-08-08/events

उस दिन के लिए कैलेंडर कार्यक्रम देना चाहिए।

यदि आप किसी विशिष्ट श्रेणी के लिए ईवेंट चाहते हैं

/calendar/2014-08-08/events?category=appointments

या यदि आपको 30 मिनट से अधिक समय की घटनाओं की आवश्यकता है

/calendar/2014-08-08/events?duration=30

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

Answer 11

मैं आमतौर पर एक क्वेरी तर्क (यानी / एपीआई / संसाधन? पैरामीटर = मूल्य) के रूप में # 2 की ओर जाता हूं।

एक तीसरा विकल्प वास्तव में शरीर में पैरामीटर = मान पोस्ट करना है।

ऐसा इसलिए है क्योंकि यह मल्टी पैरामीटर संसाधनों के लिए बेहतर काम करता है और भविष्य में उपयोग के लिए अधिक उपयोगी है।

कोई फर्क नहीं पड़ता कि आप किसे चुनते हैं, सुनिश्चित करें कि आप केवल एक को चुनते हैं, मिश्रण और मैच नहीं करते हैं। यह एक भ्रमित एपीआई की ओर जाता है।

Answer 12

इस विषय के एक "आयाम" को अभी तक छोड़ दिया गया है यह बहुत महत्वपूर्ण है: ऐसे समय होते हैं जब "सर्वोत्तम प्रथाओं" को उन विकृतियों के संदर्भ में आना होता है जिन्हें हम लागू कर रहे हैं या आरईएसटी क्षमताओं के साथ बढ़ रहे हैं।

व्यावहारिक उदाहरण:

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

बस एक काफी प्रसिद्ध वेब एप्लिकेशन का उल्लेख करने के लिए: एक ओपनकार्ट ई-कॉमर्स शॉप। जब व्यवस्थापक "SEO URL" को सक्षम करता है तो यह उम्मीद करता है कि URL काफी मानक MVC प्रारूप में आते हैं जैसे:

http://www.domain.tld/special-offers/list-all?limit=25

कहाँ पे

• special-offers MVC नियंत्रक है जो URL को संसाधित करेगा (विशेष-ऑफ़र पृष्ठ दिखा रहा है)

• list-allकॉल करने के लिए नियंत्रक की क्रिया या फ़ंक्शन का नाम है। (*)

• सीमा = 25 एक विकल्प है, जिसमें कहा गया है कि प्रति पृष्ठ 25 आइटम दिखाए जाएंगे।

(*) list-allएक काल्पनिक फ़ंक्शन नाम है जिसका उपयोग मैंने स्पष्टता के लिए किया था। वास्तव में, OpenCart और अधिकांश MVC फ्रेमवर्क में एक डिफ़ॉल्ट, निहित (और आमतौर पर URL में छोड़ा गया) indexफ़ंक्शन होता है, जिसे तब कॉल किया जाता है जब उपयोगकर्ता डिफ़ॉल्ट कार्रवाई करना चाहता है। तो असली दुनिया URL होगा:

http://www.domain.tld/special-offers?limit=25

उपरोक्त के समान अब काफी मानक एप्लिकेशन या फ्रेमवर्क संरचना के साथ, आपको अक्सर एक वेब सर्वर मिलेगा जो इसके लिए अनुकूलित है, जो इसके लिए URL को फिर से लिखता है (सही "गैर SEOed URL" होगा:) http://www.domain.tld/index.php?route=special-offers/list-all&limit=25।

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

इसलिए, आपका REST API अक्सर संदर्भित वेब एप्लिकेशन के मानकों का पालन करते हुए बहुत बेहतर होगा, इसके साथ सुसंगतता और आसानी / गति (और इस प्रकार बजट की बचत)।

उपरोक्त व्यावहारिक उदाहरण पर वापस जाने के लिए, एक संगत REST API URL के साथ कुछ होगा:

http://www.domain.tld/api/special-offers-list?from=15&limit=25

या (गैर एसईओ यूआरएल)

http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25

"रास्तों का गठन" तर्कों और "क्वेरी का गठन" तर्कों के मिश्रण के साथ।

Answer 13

मुझे बहुत सारे REST API दिखाई देते हैं जो मापदंडों को अच्छी तरह से हैंडल नहीं करते हैं। एक उदाहरण जो अक्सर सामने आता है जब यूआरआई व्यक्तिगत रूप से पहचान योग्य जानकारी शामिल करता है।

http://software.danielwatrous.com/design-principles-for-rest-apis/

मुझे लगता है कि एक कोरोलरी सवाल यह है कि जब पैरामीटर को पैरामीटर बिल्कुल नहीं होना चाहिए, बल्कि इसके बजाय अनुरोध के हेडर या बॉडी में ले जाना चाहिए ।

Answer 14

यह एक बहुत ही दिलचस्प सवाल है।

आप दोनों का उपयोग कर सकते हैं, इस विषय में कोई सख्त नियम नहीं है, लेकिन URI पथ चर का उपयोग करने के कुछ फायदे हैं:

• कैश : जब वे क्वेरी पैरामीटर होते हैं, तो इंटरनेट पर अधिकांश वेब कैश सेवाएँ GET अनुरोध को कैश नहीं करती हैं। वे ऐसा इसलिए करते हैं क्योंकि सर्वर में डेटा बदलने के लिए जीईटी अनुरोधों का उपयोग करते हुए बहुत सारे आरपीसी सिस्टम हैं (विफल !! सुरक्षित रूप से सुरक्षित होना चाहिए)

लेकिन अगर आप पथ चर का उपयोग करते हैं, तो यह सभी सेवाएँ आपके GET अनुरोधों को कैश कर सकती हैं।

• पदानुक्रम : पथ चर पदानुक्रम का प्रतिनिधित्व कर सकते हैं: / शहर / सड़क / स्थान

यह उपयोगकर्ता को डेटा की संरचना के बारे में अधिक जानकारी देता है।

लेकिन यदि आपके डेटा में कोई पदानुक्रम संबंध नहीं है, तो आप अभी भी पथ चर का उपयोग कर सकते हैं, अल्पविराम या अर्ध-उपनिवेश का उपयोग कर सकते हैं:

/ शहर / देशांतर, अक्षांश

एक नियम के रूप में, पैरामा का उपयोग तब करें जब पैरामीटर्स के ऑर्डर के मामले में, सेमी-कोलोन का उपयोग करें जब ऑर्डर मायने नहीं रखता है:

/ IconGenerator / लाल, नीले, हरे

उन कारणों के अलावा, कुछ मामले हैं जब क्वेरी स्ट्रिंग चर का उपयोग करना बहुत आम है:

• जब आपको ब्राउज़र को स्वचालित रूप से URI में HTML फॉर्म चर डालने की आवश्यकता होती है
• जब आप एल्गोरिथ्म के साथ काम कर रहे हैं। उदाहरण के लिए, Google इंजन क्वेरी स्ट्रिंग का उपयोग करता है:

http: // www.google.com/search?q=rest

योग करने के लिए, इस तरीके में से एक का उपयोग करने का कोई मजबूत कारण नहीं है लेकिन जब भी आप कर सकते हैं, यूआरआई चर का उपयोग करें।