REST URL नामकरण सम्मेलन/आइटम/{आईडी} बनाम/आइटम? Id = {id}

Question

मैं समझता हूं कि एमवीसी पैटर्न और आरईएसटी सेवाओं में यूआरआई का उपयोग करना सामान्य है जैसे /items/{id} लेकिन क्वेरी पैरामीटर का उपयोग करने के बारे में क्या बुरा बात है यूआरआई?

GET /items/{id} बनाम GET /items?id={id}

इसके अलावा

, मान लीजिए कि एक इकाई 'referenceId' फ़ील्ड कि कुछ संबंधित (जैसे कि माता-पिता) इकाई की ओर इशारा करता है, और मैं मूल इकाई है, जो रास्ते के लिए सभी आइटम पाने के लिए बाकी सेवा बनाने की जरूरत है बेहतर:

GET(POST) /items/parent/{parentId} 

या

GET(POST) /items?parent={parentId} 

अंतर्दृष्टि है कि मेरे व्यक्तिपरक को हल करने में मदद मिलेगी है के लिए आभारी होंगे आरईएसटी सेवाओं के लिए यूआरएल बनाने पर मुकदमा।

Answer 1

मैं निम्नलिखित योजनाओं का उपयोग करूंगा।

/items/id 

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

/parent/id/items 

यहाँ id एक आईडी विशिष्ट माता पिता की एक संसाधन को संबोधित करना है और उन्हें जो हमारे इकट्ठा/से आइटम यह संदर्भ देता है पुनः प्राप्त। प्रश्न में आपने जो कहा है उससे ऐसा लगता है कि माता-पिता एक कंटेनर या संग्रह की तरह कई वस्तुओं का संदर्भ देता है।

मैं जिस सम्मेलन का उपयोग करता हूं वह बाएं से दाएं गुंजाइश को कम करना है। इसलिए यदि आइटम active या inactive हो सकता है। इस प्रकार वस्तुओं की संपत्ति या विशेषता active या inactive है।अपने पहले प्रश्न के लिए

/items/active 
/parent/id/active 

Answer 2

बेशक, आरईएसटी सिद्धांतों को यूआरएल पर सौंदर्य संबंधी विवरणों की परवाह नहीं है। यह सिर्फ यह लागू करता है कि प्रत्येक संसाधन विशिष्ट रूप से संबोधित किया जाना चाहिए।

इसके अलावा, "पैरामीटर" के अर्थशास्त्र का उल्लंघन करने के लिए क्वेरी पैरामीटर का उपयोग विशिष्ट रूप से "पैरामीटर" के अर्थशास्त्र का उल्लंघन करता है, है ना? एक पैरामीटर कुछ वैकल्पिक होना चाहिए, कुछ अतिरिक्त और पैरामीटरकृत होना चाहिए। उदाहरण के लिए, वस्तुओं के संग्रह पर विस्तृत खोज की तरह कुछ।

कुछ मामलों में आपने जो लिखा है, वह समझ सकता है। निर्भर करता है।

आपके उदाहरण में, आइटम वास्तव में एक संसाधन है? यदि नहीं, तो आप बस GET(POST) /parents/{parentId} कर सकते हैं।

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

मुझे उम्मीद है कि मैंने स्वयं को स्पष्ट कर दिया है।

Answer 3

: इस पर नीचे संकुचन मैं निम्नलिखित योजना मिल

/items/{id} अगर यह मौजूद नहीं है निर्दिष्ट आईडी या 404 के साथ एक एकल संसाधन को पुनः प्राप्त करना चाहिए।

/items/?id={id} किसी सरणी को पुनर्प्राप्त करना चाहिए (भले ही सरणी में केवल एक ही) क्योंकि आप संग्रह से पूछताछ कर रहे हैं।

अपने दूसरे प्रश्न के लिए:

मैं @ miguelcobain का आकलन से सहमत - यदि आइटम किसी विशिष्ट संसाधन/संस्था है, बस इसे पुनः प्राप्त करने के लिए उचित संसाधन पथ का उपयोग करें।

उपभोक्ता पर इसे आसान बनाने के लिए, rel="parent" के साथ बनाएं और/या बाल संसाधन में यूरी शामिल करें। लिंक हेडर के उदाहरण के लिए, गिटहब के pagination api देखें।

Answer 4

ऐसा लगता है कि मेरे पालन करने के लिए कोई नियम नहीं हैं।

items/{id} - यह सम्मेलन दिए गए आईडी द्वारा आइटम प्राप्त करने के लिए उपयुक्त है। यदि उपयोगकर्ता आईडी प्रदान नहीं करता है तो यह 404 स्टेटस कोड देता है।

items/id={id}&name={name} - इस प्रकार का सम्मेलन दिए गए मानदंडों से कई वस्तुओं को खोजने के लिए उपयुक्त है। यदि कोई आइटम नहीं मिला है, तो यह एक 404 स्थिति नहीं है, आप बस कहते हैं, "मैंने सफलतापूर्वक आपके खोज मानदंड से मेल नहीं खाया"