LIKE मानदंडों के साथ एक आरईएसटी एपीआई कैसे डिजाइन करें?

Question

मैं एक REST API डिजाइनिंग रहा हूँ और "लोगों के लिए" एक इकाई है:

GET http://localhost/api/people 

प्रणाली

GET http://localhost/api/people/1 

में सभी लोगों की एक सूची रिटर्न आईडी 1.

के साथ व्यक्ति रिटर्न

GET http://localhost/api/people?forename=john&surname=smith 

मिलान करने वाले उपनामों और उपनामों के साथ सभी लोगों को वापस लौटाता है लेकिन मुझे और आवश्यकता है। एपीआई उपभोक्ताओं को उन सभी लोगों को पुनर्प्राप्त करने की इजाजत देने का सबसे साफ/सर्वोत्तम अभ्यास तरीका क्या है, जिनके पूर्वनाम उदाहरण के लिए "जो" से शुरू होता है।

मैंने देखा है कुछ APIs इस तरह कार्य करें:

GET http://localhost/api/people?forename=jo~&surname=smith 

जहां टिल्ड एक "फजी" मैच का प्रतीक है। दूसरी तरफ मैंने इसे पूरी तरह से अलग मानदंडों के साथ लागू किया है।

GET http://localhost/api/people?forename-startswith=jo&surname=smith 

जो -soundslike (soundex मैच के कुछ प्रकार के लिए) पर विचार मैं -endswith हो सकता है, -contains, थोड़ा बोझिल लगता है

।

कोई भी ऐसे अनुभव से सुझाव दे सकता है जो बेहतर काम करता है और अच्छी तरह से डिज़ाइन किए गए आरईएसटी एपीआई के किसी भी उदाहरण के समान कार्यक्षमता है।

Answer 1

AFAIK, ऊपर से कोई भी काफी विश्वसनीय नहीं है। वे दोनों प्रश्न पूछने के तरीके पर क्लाइंट के हिस्से पर एक प्राइरी ज्ञान पर भरोसा करते हैं (पहले मामले में, क्वेरी पैटर्न और दूसरे पर एक प्रश्न डीएसएल)। दूसरे उदाहरण में, वास्तव में, एपीआई केवल डेटा स्टोर के चारों ओर एक रैपर तक कम हो जाती है। इस प्रकार, एपीआई एक सर्वर डोमेन को परिभाषित नहीं करता है - यह एक डेटा प्रदाता है। यह क्लाइंट-सर्वर बाधा REST के विपरीत है।

आप सभी विभिन्न क्वेरी क्षमताओं के साथ एक पूर्ण विकसित डेटा संग्रह को बेनकाब करने की जरूरत है, तो आप में जाना जाता मानकों जो हम OData के लिए बेहतर छड़ी थी। ओडाटा को आरईएसटी के रूप में बेचा गया है लेकिन कई आरईएसटी-हेड्स के साथ समस्याएं हैं। किसी भी तरह, दिन के अंत में यह काम करता है और आरईएसटी चर्चा आमतौर पर विश्लेषण-पक्षाघात का कारण बन सकती है।

यदि मैं ऐसा कर रहा था, तो शायद मैं एपीआई को एक सामान्य उपयोग-मामले में बाध्य कर दूंगा, इसलिए क्वेरी डीएसएल को परिभाषित किए बिना दूसरे की तरह कुछ और (forenameStarts forename-startwith के बजाय)।

यह कहकर कि, यदि आपको कई क्षेत्रों और विभिन्न स्थितियों के आधार पर पूछताछ की आवश्यकता है, तो मैं ओडाटा का उपयोग करूंगा।

Answer 2

दोनों उदाहरण फ़िल्टरिंग के लिए क्वेरी पैरामीटर का उपयोग करते हैं। मुझे नहीं लगता कि यह महत्वपूर्ण है कि इन क्वेरी पैरामीटर को क्या कहा जाता है या यदि कुछ वाइल्डकार्ड वाक्यविन्यास का उपयोग किया जाता है।

दोनों दृष्टिकोण समान रूप से RESTFul हैं।

Answer 3

आईएमएचओ इससे कोई फर्क नहीं पड़ता कि आपके पास अस्पष्ट मैचों हैं या आपके साथ-साथ इत्यादि हैं। क्या मायने रखता है कि यदि आपका आरईएसटी एपीआई ऐसे पैरामीटरों की आसान पार्सिंग की अनुमति देता है ताकि आप अपने डेटा स्रोत से डेटा लाने के लिए कार्यों को परिभाषित कर सकें (डीबी या एक्सएमएल फ़ाइल इत्यादि) तदनुसार

यदि आप PHP का उपयोग कर रहे हैं ... मेरे अनुभव से, SlimFramework एक हल्का हल्का वजन, आसान-शुरू-शुरू समाधान है।

Answer 4

मैं आपको OData protocol की सलाह दूंगा जो Query String Options प्रदान करता है। आपने जो किया वह ठीक है और आरईएसटी सम्मेलनों का पालन करता है।

लेकिन, ओडाटा प्रोटोकॉल $expand पैरामीटर और यहां तक ​​कि $filter पैरामीटर का वर्णन करता है। यह $ उपसर्ग "सिस्टम क्वेरी विकल्प" को दर्शाता है और क्योंकि यह आप निम्नलिखित यूआरआई लिखने के लिए अनुमति देता है आप पिछले एक में रुचि होगी:

http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=tolower(CompanyName) eq 'foobar' &select=FirstName,LastName&$orderby=Name desc 

यह आप डेटा की तरह एसक्यूएल पारित करने के लिए अनुमति देता है, यह एक अच्छा विकल्प हो सकता है आपने जो वर्णन किया है (दोनों समाधान ठीक हैं, यह सिर्फ स्वाद का मामला है)।