खोज के लिए प्रतिष्ठित URL डिज़ाइन

Question

मैं एक उचित URL के रूप में खोजों का प्रतिनिधित्व करने के लिए एक उचित तरीके की तलाश कर रहा हूं।

सेटअप: मेरे पास दो मॉडल हैं, कारें और गैरेज, जहां कारें गैरेज में हो सकती हैं। तो मेरे उर जैसे दिखते हैं:

/car/xxxx
  xxx == car id
  returns car with given id

/garage/yyy
  yyy = garage id
  returns garage with given id

एक कार अपने आप में मौजूद हो सकती है (इसलिए / कार), या यह एक गैरेज में मौजूद हो सकती है। किसी दिए गए गैरेज में सभी कारों का प्रतिनिधित्व करने, कहने का सही तरीका क्या है? कुछ इस तरह:

/garage/yyy/cars     ?

गेराज yyy और zzz में कारों के मिलन के बारे में कैसे?

कुछ विशेषताओं के साथ कारों की खोज का प्रतिनिधित्व करने का सही तरीका क्या है? कहो: मुझे 4 दरवाजों वाली सभी नीली सेडान दिखाओ:

/car/search?color=blue&type=sedan&doors=4

या इसके बजाय / कारें होनी चाहिए?

"खोज" का उपयोग वहां अनुचित लगता है - एक बेहतर तरीका / शब्द क्या है? क्या यह सिर्फ होना चाहिए:

/cars/?color=blue&type=sedan&doors=4

क्या खोज मापदंडों को PATHINFO या QUERYSTRING का हिस्सा होना चाहिए?

संक्षेप में, मैं क्रॉस-मॉडल REST url डिज़ाइन के लिए मार्गदर्शन और खोज के लिए देख रहा हूँ।

[अपडेट] मुझे जस्टिन का जवाब पसंद है, लेकिन वह बहु-क्षेत्र खोज मामले को कवर नहीं करता है:

/cars/color:blue/type:sedan/doors:4

या कुछ इस तरह का। हम कैसे जाते हैं?

/cars/color/blue

कई क्षेत्र के मामले के लिए?

Comments

यद्यपि यह अंग्रेजी में बेहतर दिखता है, मिक्सिंग /carsऔर /carशब्दार्थ नहीं है और इसलिए यह एक बुरा विचार है। उस श्रेणी के अंतर्गत एक से अधिक आइटम होने पर हमेशा बहुवचन का उपयोग करें।

— ज़ाज़

ये बुरे उत्तर हैं। खोज में क्वेरी स्ट्रिंग का उपयोग करना चाहिए। क्वेरी स्ट्रिंग्स ठीक से उपयोग किए जाने पर 100% RESTful हैं (यानी, खोज के लिए)।

— pbreitenbach

बाहर की जाँच doriantaylor.com/policy/http-url-path-parameter-syntax

— अनातोली जी

Answer 1

खोज के लिए, querystrings का उपयोग करें। यह पूरी तरह से Restful है:

/cars?color=blue&type=sedan&doors=4

नियमित रूप से querystrings का एक फायदा यह है कि वे मानक और व्यापक रूप से समझे जाते हैं और उन्हें फॉर्म-गेट से उत्पन्न किया जा सकता है।

Comments

यह सही है। क्वेरी स्ट्रिंग्स का पूरा बिंदु खोज जैसी चीजों को करने के लिए है।

— aehlke

वास्तव में, यह सही है, RFC3986 के अनुसार , मार्ग और querystring संसाधन की पहचान करते हैं। क्या अधिक है, उचित नामकरण बस होगा /cars?color=whatever।

— ललकेई

उन मामलों के बारे में जहां आप तुलना करना चाहते हैं (>, <, <=,> =)? / कारों? रेटिंग <= 3?

— जेसी

क्या होगा यदि आप क्वेरी स्ट्रिंग के नीचे नेस्टेड संसाधनों का उपयोग करना चाहते हैं? जैसे /cars?color=blue&type=sedan&doors=4/enginesकाम नहीं करेगा

— अबे वोल्कर

@ एमजे कार सूची पर /cars?param=valueसरल फ़िल्टरिंग के लिए है और /cars/search?param=valueएक खोज बनाने के लिए है ( ओओ के साथ दृढ़ता के बिना) जहां परिणाम में खोज स्कोरिंग, श्रेणीकरण आदि हो सकते हैं। आप एक नामित खोज की तरह बना / हटा भी सकते हैं /cars/search/mysearch। उस पर देखो: stackoverflow.com/a/18933902/1480391

— यवेस एम।

Answer 2

RESTful सुंदर यूआरएल डिजाइन एक संरचना के आधार पर एक संसाधन प्रदर्शित करने के बारे में (निर्देशिका की तरह संरचना, तारीख: लेख / 2005/5/13, वस्तु और यह की विशेषताओं, ..), स्लैश /सौपानिक संरचना को इंगित करता है, का उपयोग -idकरने के बजाय।

वर्गीकृत संरचना

मैं पसंद करूंगा:

/garage-id/cars/car-id
/cars/car-id   #for cars not in garages

यदि उपयोगकर्ता /car-idभाग को हटाता है , तो यह carsपूर्वावलोकन - सहज ज्ञान युक्त लाता है । उपयोगकर्ता वास्तव में जानता है कि वह पेड़ में कहां है, वह क्या देख रहा है। वह पहली नज़र से जानता है, कि गैरेज और कारें संबंध में हैं। /car-idयह भी दर्शाता है कि यह एक साथ विपरीत है /car/id।

खोज कर

खोज करना ठीक है जैसा कि यह है , केवल आपकी प्राथमिकता है, जिसे ध्यान में रखा जाना चाहिए। खोज में शामिल होने पर मजेदार हिस्सा आता है (नीचे देखें)।

/cars?color=blue;type=sedan   #most prefered by me
/cars;color-blue+doors-4+type-sedan   #looks good when using car-id
/cars?color=blue&doors=4&type=sedan   #I don't recommend using &*

या मूल रूप से कुछ भी जो एक स्लैश नहीं है जैसा कि ऊपर बताया गया है।
सूत्र: /cars[?;]color[=-:]blue[,;+&]*, हालांकि मैं &संकेत का उपयोग नहीं करूंगा क्योंकि यह पहली नज़र में पाठ से अपरिचित है।

** क्या आप जानते हैं कि URI में JSON ऑब्जेक्ट को पास करना RESTful है? **

विकल्पों की सूची

/cars?color=black,blue,red;doors=3,5;type=sedan   #most prefered by me
/cars?color:black:blue:red;doors:3:5;type:sedan
/cars?color(black,blue,red);doors(3,5);type(sedan)   #does not look bad at all
/cars?color:(black,blue,red);doors:(3,5);type:sedan   #little difference

संभव सुविधाएँ?

(!) निगेट तलाश किए जाने
किसी भी कारों खोजने के लिए, लेकिन नहीं काले और लाल :
?color=!black,!red
color:(!black,!red)

शामिल हों
खोजें लाल या नीले या काले रंग की कारों के साथ 3 दरवाजे गैरेज आईडी 1..20 या 101..103 या 999 लेकिन 5 नहीं तो आप अधिक जटिल खोज क्वेरी का निर्माण कर सकते हैं। ( सब्सट्रेट मिलान के विचार के लिए सीएसएस 3 विशेषता को देखें । जैसे "बार" वाले उपयोगकर्ताओं को खोजना । /garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
user*=bar

निष्कर्ष

वैसे भी, इस के लिए, आप के लिए सबसे महत्वपूर्ण हिस्सा हो सकता है, क्योंकि आप इसे लेकिन आप सब के बाद की तरह कर सकते हैं, बस ध्यान रखें कि RESTful यूआरआई एक संरचना है जो आसानी से समझा जैसे निर्देशिका की तरह है का प्रतिनिधित्व करता है /directory/file, /collection/node/item, दिनांक /articles/{year}/{month}/{day}.. और जब आप छोड़ देते हैं अंतिम खंडों में से कोई भी, आप तुरंत जानते हैं कि आपको क्या मिलता है।

तो .., इन सभी पात्रों को अनएन्कोड किया गया है :

• अनारक्षित: a-zA-Z0-9_.-~
  आमतौर पर दोनों एन्कोडेड की अनुमति है और नहीं, दोनों का उपयोग तो समकक्ष हैं।
• विशेष वर्ण: $-_.+!*'(),
• आरक्षित: ;/?:@=&
  जिस उद्देश्य का वे प्रतिनिधित्व करते हैं, उसके लिए अनएन्कोडेड का उपयोग किया जा सकता है, अन्यथा उन्हें एनकोड किया जाना चाहिए।

• असुरक्षित: <>"#%{}|\^~[]`
  क्यों असुरक्षित है और क्यों नहीं बल्कि इनकोड किया जाना चाहिए: RFC 1738 में 2.2 देखें

  अधिक वर्ण वर्गों के लिए RFC 1738 # पृष्ठ -20 भी देखें ।

RFC 3986 में 2.2 देखें
कि मैंने पहले जो कहा था उसके बावजूद, यहां डेलिमीटर का एक सामान्य अंतर है, जिसका अर्थ है कि कुछ " दूसरों की तुलना में " अधिक महत्वपूर्ण हैं।

• सामान्य delimeters: :/?#[]@
• उप delimeters: !$&'()*+,;=

और अधिक पढ़ने:
पदानुक्रम: 2.3 देखें , 1.2.3
url पथ पैरामीटर सिंटैक्स
CSS3 विशेषता मिलान
IBM देखें: प्रतिष्ठित वेब सेवाएं - मूल बातें
नोट: RFC 1738 को RFC 3986 द्वारा अद्यतन किया गया था

Comments

मुझे विश्वास नहीं होता कि मैंने क्वेरी स्ट्रिंग में JSON का उपयोग करने के बारे में नहीं सोचा है। यह एक ऐसी समस्या का जवाब है जिसका मैं सामना कर रहा था - बिना उपयोग के जटिल खोज संरचना POST। साथ ही, आपके उत्तर में दिए गए अन्य विचार भी बहुत प्रशंसनीय हैं। बहुत बहुत धन्यवाद!

— 20

@ क्वर्टी: बढ़िया पोस्ट! मैं सोच रहा था: पठनीयता के ;विपरीत उपयोग करने का एकमात्र कारण &? क्योंकि अगर ऐसा है, तो मुझे लगता है कि मैं वास्तव में पसंद करूंगा &क्योंकि यह अधिक सामान्य सीमांकक है ... सही है? :) धन्यवाद!

— फ्लो

@ ठीक हाँ :), लेकिन ध्यान रखें कि &एक सीमांकक केवल डेवलपर्स के लिए जाना जाता है। माता-पिता, दादा-दादी और गैर-पढ़ी-लिखी आबादी परिसीमन को आम लिखित पाठ के रूप में स्वीकार करती है।

— क्वर्टी

क्यों गैर-मानक योजना बनाते हैं जब क्वेरी तार अच्छी तरह से समझा और मानक हैं?

— pbreitenbach

? @Qwerty कुछ नहीं से / खोज कारों आप रोक = लाल, नीले, हरे और गैरेज = 1,2,3 या आप एक <एकाधिक चयन करें> फार्म का उपयोग करता है, तो: / खोज कारों = लाल और कारों = नीले और गैरेज = 1 & गैरेज = 2?

— pbreitenbach

Answer 3

यद्यपि पथ में पैरामीटर होने के कुछ फायदे हैं, आईएमओ हैं, कुछ आउटवेइंग कारक हैं।

• URL में खोज क्वेरी के लिए आवश्यक सभी वर्णों की अनुमति नहीं है। अधिकांश विराम चिह्न और यूनिकोड वर्णों को क्वेरी स्ट्रिंग पैरामीटर के रूप में URL एनकोडेड करना होगा। मैं उसी समस्या से जूझ रहा हूं। मैं URL में XPath का उपयोग करना चाहूंगा, लेकिन सभी XPath सिंटैक्स URI पथ के साथ संगत नहीं है। तो सरल रास्तों के लिए, ड्राइवर के दरवाजे XML दस्तावेज़ में /cars/doors/driver/lock/combination' combination' तत्व का पता लगाना उचित होगा । लेकिन /car/doors[id='driver' and lock/combination='1234']इतना अनुकूल नहीं है।

• इसकी किसी विशेषता के आधार पर किसी संसाधन को फ़िल्टर करने और संसाधन को निर्दिष्ट करने के बीच अंतर है।

  उदाहरण के लिए, चूंकि

  /cars/colors सभी कारों के लिए सभी रंगों की एक सूची देता है (लौटाया गया संसाधन रंग वस्तुओं का एक संग्रह है)

  /cars/colors/red,blue,green लाल रंग, नीले या हरे रंग की वस्तुओं की सूची लौटाएगा, कारों का संग्रह नहीं।

  कारों को वापस करने के लिए, रास्ता होगा

  /cars?color=red,blue,green या /cars/search?color=red,blue,green

• पथ में पैरामीटर पढ़ने में अधिक कठिन होते हैं क्योंकि नाम / मान जोड़े शेष पथ से पृथक नहीं होते हैं, जो कि नाम / मान जोड़े नहीं हैं।

एक आखिरी टिप्पणी। मैं /garages/yyy/cars(हमेशा बहुवचन) को पसंद करता हूं /garage/yyy/cars(शायद यह मूल उत्तर में एक टाइपो था) क्योंकि यह एकवचन और बहुवचन के बीच का रास्ता बदलने से बचता है। एक अतिरिक्त 'एस' के साथ शब्दों के लिए, परिवर्तन इतना बुरा नहीं है, लेकिन बदलते /person/yyy/friendsको /people/yyyबोझिल लगता है।

Comments

हां, मैं सहमत हूं ... इसके अलावा मैं बात करता हूं कि पथ संरचना संस्थाओं के बीच प्राकृतिक संबंधों को प्रतिबिंबित करना चाहिए, मेरे संसाधनों के नक्शे के कुछ प्रकार, जैसे गेराज में कई कारें हैं, एक कार गैरेज से संबंधित है और इसलिए ... और जाने दें फ़िल्टर पैरामीटर, कारण यह है कि हम किस बारे में बात कर रहे हैं, क्वेरिस्ट्रिंग को ... आप क्या सोचते हैं?

— खुलता है

Answer 4

पीटर के उत्तर पर विस्तार करने के लिए - आप खोज को प्रथम श्रेणी संसाधन बना सकते हैं:

POST    /searches          # create a new search
GET     /searches          # list all searches (admin)
GET     /searches/{id}     # show the results of a previously-run search
DELETE  /searches/{id}     # delete a search (admin)

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

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

इस Railscast में विचार को और अधिक विस्तार से समझाया गया है ।

Comments

क्या यह दृष्टिकोण एक बेचैन प्रोटोकॉल के साथ काम करने के विचार के खिलाफ नहीं जाता है? मेरा मतलब है, एक db के लिए एक खोज जारी रखने के एक राज्य संबंध होने की तरह है ... है ना?

— खुलता है

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

— रिच एपोडाका

उपरोक्त कैसे एक URI सम्मेलन को परिभाषित करता है?

— रिच अपोडका

REST का सुंदर URI या URI घोंसले आदि से कोई संबंध नहीं है। यदि आप URI को अपने API के भाग के रूप में परिभाषित करते हैं, तो यह REST नहीं है।

— aehlke

मैंने पहले भी यह तर्क दिया है। यह कोई रास्ता नहीं है, लेकिन यह एक भयानक बात है। खोज का 'हटाना' पूरी तरह से स्पष्ट नहीं है, यहाँ आप कह रहे हैं कि यह इस खोज इकाई को हटा देता है, लेकिन मैं इसका उपयोग उस खोज के माध्यम से प्राप्त परिणामों को हटाने के लिए करना चाहूंगा। कृपया संसाधन के रूप में 'खोजें' न जोड़ें।

— Theoshman

Answer 5

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

/search/{searchQuery}

या

/search/{savedSearchName}

Comments

नहीं। यह कभी नहीं समझ में आता है कि एक कार्रवाई के लिए एक संसाधन होना चाहिए।

— thecoshman

@ टिप्पणी के रूप में उपरोक्त टिप्पणी के अनुसार, खोज भी एक संज्ञा है।

— औरो

Answer 6

मैं खोजों को लागू करने के लिए दो तरीकों का उपयोग करता हूं।

1) सरलतम मामला, संबद्ध तत्वों को क्वेरी करने के लिए, और नेविगेशन के लिए।

    /cars?q.garage.id.eq=1

इसका मतलब है, ऐसी क्वेरी कारें जिनके पास गैराज आईडी 1 के बराबर है।

अधिक जटिल खोज बनाना भी संभव है:

    /cars?q.garage.street.eq=FirstStreet&q.color.ne=red&offset=300&max=100

FirstStreet में सभी गैरेज की कारें जो लाल नहीं हैं (3 पेज, प्रति पृष्ठ 100 तत्व)।

2) जटिल प्रश्नों को नियमित संसाधन माना जाता है जो बनाए जाते हैं और उन्हें पुनर्प्राप्त किया जा सकता है।

    POST /searches  => Create
    GET  /searches/1  => Recover search
    GET  /searches/1?offset=300&max=100  => pagination in search

खोज निर्माण के लिए POST निकाय इस प्रकार है:

    {  
       "$class":"test.Car",
       "$q":{
          "$eq" : { "color" : "red" },
          "garage" : {
             "$ne" : { "street" : "FirstStreet" }
          }
       }
    }

यह ग्रेल्स (मापदंड DSL) में आधारित है: http://grails.org/doc/2.4.3/ref/Domain%20Classes/createCriteria.html

Answer 7

यह REST नहीं है। आप अपने API के अंदर संसाधनों के लिए URI को परिभाषित नहीं कर सकते। संसाधन नेविगेशन हाइपरटेक्स्ट-चालित होना चाहिए। यदि आप बहुत URI और भारी मात्रा में युग्मन चाहते हैं तो यह ठीक है, लेकिन इसे केवल REST नहीं कहेंगे, क्योंकि यह सीधे Restful वास्तुकला की बाधाओं का उल्लंघन करता है।

इस लेख को REST के आविष्कारक द्वारा देखें ।

Comments

आप सही हैं कि यह REST नहीं है, यह RESTful सिस्टम के लिए URL डिज़ाइन है। आप यह कहने में भी गलत हैं कि यह रेस्टफुल आर्किटेक्चर का उल्लंघन करता है। REST का हाइपरटेक्स्ट अवरोध एक अच्छी प्रणाली के लिए अच्छे URL डिज़ाइन के लिए रूढ़िवादी है; मुझे याद है कि कई साल पहले राय टी। फील्डिंग पर रॉय टी। फील्डिंग के साथ एक चर्चा हो रही थी जिसमें मैंने भाग लिया था जहां उन्होंने इतने स्पष्ट रूप से कहा था। कहा कि हाइपरटेक्स्ट और URL डिज़ाइन करना संभव है। Restful सिस्टम के लिए URL डिज़ाइन प्रोग्रामिंग में इंडेंटेशन जैसा है; आवश्यक नहीं है लेकिन एक बहुत अच्छा विचार (पायथन को अनदेखा करना)

— माइकस्किनल

मुझे क्षमा करें, आप सही हैं। मुझे सिर्फ ओपी से यह आभास हुआ कि वह ग्राहकों को URL बनाने के तरीके से अवगत कराने जा रहा है - वह URL को अपने API का "लेआउट" भाग बनाएगा। यह REST का उल्लंघन होगा।

— ऐहल्के

@ टिप्पणी, आपको अपनी टिप्पणी से मेल खाने के लिए अपने उत्तर को अपडेट करना चाहिए।

— जेम्स मैकमोहन

यह स्तर 2 रिचर्डसन परिपक्वता मॉडल का अनुपालन है। आप स्तर 3 का उल्लेख कर रहे हैं। बस आरईएस को कुछ उत्तरोत्तर अपनाने योग्य के रूप में स्वीकार करें।

— जूल्स रैंडोल्फ

@ जूल्स रैंडोल्फ - माफी, मेरा जवाब रिचर्डसन परिपक्वता मॉडल को पहली बार गढ़ा गया था और मार्टिन फावलर से पहले और अन्य लेखकों ने इसे लोकप्रिय बनाने के कुछ महीने बाद ही लिखा था :) वास्तव में, यह पालन करने के लिए एक शिक्षाप्रद मॉडल है। जवाब को संपादित करने के लिए स्वतंत्र महसूस करें।

— aehlke

Answer 8

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

जिस तरह से मैं इसे देखता हूं, आप इसे विशिष्ट संसाधनों को संभालने के तरीके से बना सकते हैं:
/ कारें / कैम *

या, आप बस इसे फिल्टर में जोड़ सकते हैं:
/ कारें / दरवाजे / 4 / नाम / कैम * / रंग / लाल, नीली, हरी

व्यक्तिगत रूप से, मैं बाद को पसंद करता हूं, लेकिन मैं किसी भी तरह से REST पर विशेषज्ञ नहीं हूं (पहली बार 2 या इतने सप्ताह पहले ही सुना था ...)

Comments

इस तरह:/cars?name=cam*

— DanMan

Answer 9

Restful URL / कारों / क्रियाओं में क्रियाओं का उपयोग करने की सलाह नहीं देता है और खोज बाकी नहीं है। अपने एपीआई को क्वेरी पैरामीटर्स के माध्यम से फ़िल्टर / सर्च / पगेट करने का सही तरीका है। हालांकि ऐसे मामले हो सकते हैं जब आपको आदर्श को तोड़ना होगा। उदाहरण के लिए, यदि आप कई संसाधनों को खोज रहे हैं, तो आपको कुछ का उपयोग करना होगा जैसे / खोज? Q = क्वेरी

RESTful API के डिजाइन करने के सर्वोत्तम तरीकों को समझने के लिए आप http://saipraveenblog.wordpress.com/2014/09/29/rest-api-best-practices/ पर जा सकते हैं

Comments

खोज एक संज्ञा भी है 😀

— jith912

Answer 10

इसके अलावा मैं यह भी सुझाव दूंगा:

/cars/search/all{?color,model,year}
/cars/search/by-parameters{?color,model,year}
/cars/search/by-vendor{?vendor}

यहाँ, Searchसंसाधन का एक बाल संसाधन माना जाता है Cars।

Answer 11

यहां आपके मामले के लिए बहुत सारे अच्छे विकल्प हैं। फिर भी आपको POST बॉडी का उपयोग करने पर विचार करना चाहिए।

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

यह खोज के अधिक लचीले विवरण की अनुमति देता है, साथ ही सर्वर URL की लंबाई सीमा से भी बचता है।

Answer 12

मेरी सलाह यह होगी:

/garages
  Returns list of garages (think JSON array here)
/garages/yyy
  Returns specific garage
/garage/yyy/cars
  Returns list of cars in garage
/garages/cars
  Returns list of all cars in all garages (may not be practical of course)
/cars
  Returns list of all cars
/cars/xxx
  Returns specific car
/cars/colors
  Returns lists of all posible colors for cars
/cars/colors/red,blue,green
  Returns list of cars of the specific colors (yes commas are allowed :) )

संपादित करें:

/cars/colors/red,blue,green/doors/2
  Returns list of all red,blue, and green cars with 2 doors.
/cars/type/hatchback,coupe/colors/red,blue,green/
  Same idea as the above but a lil more intuitive.
/cars/colors/red,blue,green/doors/two-door,four-door
  All cars that are red, blue, green and have either two or four doors.

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

यहाँ REST में क्वेरी स्ट्रिंग्स की बुराइयों का वर्णन करने वाले पृष्ठ का लिंक दिया गया है: http://web.archive.org/web/20070815111413/http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

मैंने Google के कैश का उपयोग किया क्योंकि सामान्य पृष्ठ मेरे लिए उस लिंक के साथ भी काम नहीं कर रहा था: http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

Comments

विस्तृत उत्तर के लिए धन्यवाद। पिछले एक पर, क्या होगा अगर मैं दरवाजे के रंग और संख्या दोनों से खोज करना चाहता हूं? / कारें / रंग / लाल, नीले, हरे / दरवाजे / 4 यह सही नहीं लगता है।

— Parand

URL में Commas मुझे सही नहीं लगता, लेकिन फिर भी मान्य बाकी है। मुझे लगता है कि यह सिर्फ एक बदलाव है।

— जस्टिन बोजोनियर

मुझे यह सुझाव पसंद नहीं आया। तुम कैसे /cars/colors/red,blue,greenऔर के बीच अंतर पता होगा /cars/colors/green,blue,red? यूआरआई का पथ तत्व पदानुक्रमित होना चाहिए, और मुझे वास्तव में यह नहीं दिखता कि यहां मामला है। मुझे लगता है कि यह एक ऐसी स्थिति है जहां क्वेरी-स्ट्रिंग सबसे उपयुक्त विकल्प है।

— troelskn

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

— pbreitenbach

कई मापदंडों के साथ, संसाधन की क्वेरी करने की समस्या को हल करने के लिए मुख्य रूप से querystrings बनाया गया। URI को "रेस्टफुल" एपीआई को सक्षम करने के लिए खतरनाक और कम दृष्टि वाला लगता है - खासकर जब से आपको यूआरआई पर मापदंडों के विभिन्न क्रमांकन को संभालने के लिए अपने स्वयं के जटिल मैपिंग लिखना होगा। बेहतर अभी तक, अपने यूआरआई में अर्धविराम का उपयोग करने की पहले से मौजूद धारणा का उपयोग करें: doriantaylor.com/policy/http-url-path-parameter-syntax

— अनातोली जी