2015-02-18 8 views
8

एक विश्वसनीय API को डिज़ाइन करते समय, यदि अनुरोध के साथ जुड़े विशिष्ट पैरामीटर हैं तो कोई GET अनुरोध केवल तभी समझता है जब कोई अनुरोध हो? क्या पैरामीटर को क्वेरी स्ट्रिंग के रूप में पास किया जाना चाहिए, और यदि हां, तो क्या करें जब सभी पैरामीटर निर्दिष्ट नहीं हैं या गलत तरीके से स्वरूपित हैं?RESTful एपीआई क्वेरी स्ट्रिंग में पैरामीटर की आवश्यकता है?

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

मैं इस मामले में 2 विकल्प के बारे में सोच सकते हैं:
1. क्वेरी स्ट्रिंग में पैरामीटर लाना: api/posts/?lat=5.54158&lng=71.5486&radius=10
2. URL में पैरामीटर लाना: api/posts/lat/5.54158/lng/71.5486/radius/10

इनमें से कौन सा सही दृष्टिकोण होगा ? क्वेरी स्ट्रिंग में आवश्यक पैरामीटर डालना गलत लगता है, लेकिन बाद वाला दृष्टिकोण कुछ हद तक 'उलझन' लगता है।

पीएस। मुझे पता है कि इस विषय पर पहले से ही कई चर्चाएं हैं (उदाहरण के लिए: REST API Best practices: Where to put parameters?), लेकिन मेरे प्रश्न को विशेष रूप से मामले के लिए संबोधित किया जाता है जब पैरामीटर आवश्यक होते हैं, वैकल्पिक नहीं।

+0

http://programmers.stackexchange.com/questions/270898/designing-a-rest-api-by-uri-vs-query-string –

उत्तर

2

जब एक RESTful API डिजाइनिंग, क्या हुआ अगर एक GET अनुरोध केवल समझ में आता है अगर वहाँ अनुरोध के साथ जुड़े विशिष्ट मानदंडों हैं करना है? पैरामीटर को क्वेरी स्ट्रिंग के रूप में पास किया जाना चाहिए, और यदि ऐसा है, तो क्या करें जब सभी पैरामीटर निर्दिष्ट नहीं हैं या गलत तरीके से प्रारूपित हैं?

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

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

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

+1

लेकिन, यह भी सुझाव दिया जाता है कि जब आप 404 त्रुटि वापस करना चाहते हैं जब पैरामीटर मान मौजूदा संसाधन से मेल नहीं खाता है तो पथ खंड पैरामीटर का उपयोग किया जाना चाहिए। निम्न प्रश्न में पहले उत्तर पर नज़र डालें: http://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters – abc

+0

@StenSootla आप सही हैं "सर्वर नहीं है अनुरोध-यूआरआई से मेल खाने वाली कुछ भी मिली। इस बात का कोई संकेत नहीं दिया गया है कि स्थिति अस्थायी या स्थायी है या नहीं। " तो इस मामले में 404 अच्छी प्रतिक्रिया है। 400 विकृत अनुरोध निकाय द्वारा है। – inf3rno

+0

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

4

आपको क्वेरी स्ट्रिंग में सबकुछ रखना चाहिए और सर्वर को 3 आवश्यक पैरामीटर प्राप्त नहीं करते समय त्रुटि कोड वापस करने के लिए सेट करना चाहिए।

क्योंकि यह किसी ऑब्जेक्ट की पहचान करने वाले पैरामीटर का समूह है।

उदाहरण लेना: लैट = 5.54158; एलएनजी = 71.5486 त्रिज्या = 10

यह इस यूआरएल मेकअप भावना को बहुत संभावना नहीं होगा:

api/posts/lat/5.54158/lng/yyyy/radius/zz

यह अलग है की तुलना में:

api/memb/35/..

क्योंकि साथ आईडी 35 कर सकते हैं सदस्य बहुत सारे फ़ंक्शन (इसलिए, वैध यूआरएल) हैं:

api/memb/35/status या api/memb/35/lastlogin

7

पहला दृष्टिकोण बेहतर है।

api/posts/?lat=5.54158&lng=71.5486&radius=10 



दूसरा दृष्टिकोण एक छोटे से भ्रामक है।

api/posts/lat/5.54158/lng/71.5486/radius/10 

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

संबंधित मुद्दे