रूबी - फर्क बहुवचन बनाम एक REST API

Question

मैं अपने बाकी एपीआई के लिए यूआरएल के निर्माण से पहले मैं किसी भी कोड लिखने शुरू पर काम कर रहा हूँ में विलक्षण संसाधन। रेल बाकी जादू शानदार है, लेकिन मैं थोड़ा के रूप में एक URL का प्रारूप परेशान कर रहा हूँ:

http://myproject/projects/5

जहां परियोजना मेरी संसाधन है और 5 PROJECT_ID है। मुझे लगता है कि यदि कोई उपयोगकर्ता अपनी सभी परियोजनाओं को पुनर्प्राप्त करने की तलाश में है, तो एक संबंधित HTTP GET http://myproject/projects समझ में आता है। हालांकि अगर वे एक एकल संसाधन जैसे सूचना को पुनर्प्राप्त करना चाहते हैं, तो यह http://myproject/project/5 बनाम http://myproject/projects/5 है। क्या यह सिरदर्द से बचने के लिए सबसे अच्छा है, या आप में से कुछ एक समान चिंता साझा करते हैं और इससे भी बेहतर - एक समाधान समाधान है?

Answer 1

रेल (3) में एकवचन बनाम बहुवचन की बात आती है जब बहुत सारे सम्मेलन होते हैं। उदाहरण के लिए, मॉडल कक्षाएं हमेशा एकवचन (Person) होती हैं, जबकि संबंधित तालिकाओं हमेशा बहुवचन (people) होती हैं। (उदाहरण के लिए, Person.all मानचित्र select * from people पर।)

मार्गों के लिए, एकवचन संसाधन के साथ-साथ एक बहुवचन संसाधन की अवधारणा भी है। इसलिए यदि आपने resource :account किया है तो आपको खाता संपादित करने के लिए किसी फ़ॉर्म के पथ के लिए डिफ़ॉल्ट पथ या /account/edit के लिए /account जैसे पथ प्राप्त होंगे। (ध्यान दें कि रेल एक PUT विधि के साथ /account का उपयोग करता है वास्तव में खाता अपडेट करने /account/edit खाते को संपादित करने के लिए एक रूप है, जो खाते में ही। से एक अलग संसाधन है।) आप resources :people किया है, हालांकि, तो आप /people तरह रास्तों मिलेगा , /people/1, और /people/1/edit। पथ स्वयं इंगित करते हैं कि किसी दिए गए प्रकार के संसाधन का केवल एक उदाहरण हो सकता है, या क्या कुछ प्रकार के पहचानकर्ता द्वारा विशिष्ट उदाहरण हो सकते हैं।

Answer 2

मैं सहमत हूं, प्रवाह के साथ जाओ। विचार करें कि यूआरएल कैसे पदानुक्रम बनाता है।

आपकी वेबसाइट की जड़ वह जगह है जहां आप कुछ भी एक्सेस करना शुरू करते हैं।

/परियोजनाओं/इसे केवल परियोजनाओं तक सीमित करता है, कुछ और नहीं। परियोजनाओं से आप बहुत सी चीजें,/सूची,/सूचकांक /,/निर्यात, आदि कर सकते हैं .../id चीजों को और भी सीमित करता है।

प्रत्येक पर/क्या कर के दायरे से संकरा हो जाता है, और मुझे लगता है कि यह समझ में आता है।

आगे प्रोग्रामिंग मनमाने ढंग से नियमों के बारे में है। 1 बनाम 0 से शुरू होने वाले इंडेक्स, और इसी तरह से। आपके यूआरएल के साथ काम करने वाला कोई भी व्यक्ति छोटी क्रम में चीजों को हल करेगा।

Answer 3

ऐसे मामले हैं जहां संसाधन के लिए एकवचन पथ सहायक होता है। यदि आपके संसाधन आईडी गैर-संख्यात्मक उपयोगकर्ता परिभाषित नाम हैं तो राउटिंग संघर्ष संभव है। उदाहरण:

/अनुप्रयोगों/नई -> एक नया आवेदन या उपयोगकर्ता के शो आवेदन नई नामित बनाने?

class ActionDispatch::Routing::Mapper 
    module Resources 
    RESOURCE_OPTIONS << :singular_resource 
    class Resource 
     def member_scope 
     @options[:singular_resource] ? "#{singular}/:id" : "#{path}/:id" 
     end 

     def nested_scope 
     @options[:singular_resource] ? "#{singular}/:#{singular}_id" : "#{path}/:#{singular}_id" 
     end 
    end 
    end 
end 

फिर जब एक नया संसाधन मार्ग को निर्दिष्ट:

इस स्थिति में आप संघर्ष से बचने के लिए उपयोगकर्ता इनपुट को सीमित करने के लिए चुन सकते हैं, या इस डिफ़ॉल्ट रेल 3 व्यवहार ओवरराइट करके चारों ओर काम किया जा सकता है:

resources :applications, :singular_resource => true 

कौन सा मार्गों उत्पन्न करेगा:

GET  /applications 
    GET  /applications/new 
    POST /applications 
    GET  /application/:id 
    GET  /application/:id/edit 
    PUT  /application/:id 
    DELETE /application/:id