मेरे रेल एप्लिकेशन को एक यथार्थ वास्तुकला में फिट करने के लिए मुझे कड़ी मेहनत करने की आवश्यकता क्यों है?

Question

मैंने हाल ही में एक रेल परियोजना शुरू की और RESTful नियंत्रकों का उपयोग करने का फैसला किया। मैंने अपनी प्रमुख इकाइयों (जैसे देश) के लिए नियंत्रक बनाए और index, new, edit, create, show, update और delete जोड़ा। मैंने अपनी map.resources :country को अपनी मार्ग फ़ाइल में जोड़ा और जीवन अच्छा था।

विकास के बाद थोड़ा सा प्रगति हुई, मुझे समस्याओं का सामना करना पड़ा। मुझे कभी-कभी अपने नियंत्रक में अतिरिक्त कार्रवाइयों की आवश्यकता होती है। सबसे पहले search एक्शन था जो मेरे फैंसी ऑटोकंपलेटिंग सर्च बॉक्स के लिए विकल्पों को वापस कर देता था। फिर आवेदन में विभिन्न स्थानों में देशों को दो अलग-अलग तरीकों से प्रदर्शित करने की आवश्यकता आई थी (प्रदर्शित डेटा भी अलग था, इसलिए यह केवल दो विचार नहीं था) - मैंने index_full कार्रवाई को जोड़ा। फिर मैं यूआरएल में नाम से देश दिखाना चाहता था, आईडी द्वारा नहीं, इसलिए मैंने show_by_name एक्शन जोड़ा।

जब आप परे कार्रवाई की जरूरत है क्या करते हो मानक index, new, edit, create, show, update, रेल में एक आरामदायक नियंत्रक में delete? क्या मुझे रूट.आरबी फ़ाइल (जो दर्द है) में मैन्युअल मार्ग जोड़ने (और बनाए रखने) की आवश्यकता है, क्या वे एक अलग नियंत्रक में जाते हैं, क्या मैं अनावश्यक हो जाता हूं या क्या मुझे कुछ मौलिक याद आ रही है?

मुझे लगता है कि मैं पूछ रहा हूं, क्या मुझे कड़ी मेहनत करने और मेरे मार्गों में कार्रवाई जोड़ने की आवश्यकता है। आरबी फ़ाइल रीस्टफुल होने के विशेषाधिकार के लिए? अगर मैं आरईएसटी उपहार जोड़ने के लिए map.resources का उपयोग नहीं कर रहा था, तो मानक :controller/:action, :controller/:action/:id मार्ग स्वचालित रूप से बहुत अधिक सब कुछ संभाल लेंगे।

Answer 1

यदि मैं अपने मॉडल के साथ मानक सीआरयूडी कार्यों से परे जाता हूं, तो मैं आमतौर पर आवश्यकतानुसार विधियों को जोड़ता हूं। सर्च कर रहे हैं कुछ मैं कई नियंत्रकों को जोड़ने के लिए, लेकिन हर एक है, इसलिए मैं इसे सामान्य रूप से जोड़ सकते हैं और बनाए रखने के मार्गों:

map.resources :events, :collection => { :search => :get } 

एक पूरी तरह से अलग नियंत्रक से इन कार्यों ले जाने से आपकी नियंत्रकों के कुछ RESTful रखने सकता है, लेकिन मुझे लगता है कि उन्हें संदर्भ में रखते हुए कहीं अधिक उपयोगी है।

Answer 2

REST निर्दिष्ट नहीं करता है कि आपके पास अतिरिक्त विचार नहीं हो सकते हैं। कोई असली दुनिया का आवेदन केवल आपूर्ति किए गए कार्यों का उपयोग करने में सक्षम नहीं होगा; यही कारण है कि आप अपने स्वयं के कार्यों को जोड़ सकते हैं।

REST सर्वर पर स्टेटलेस कॉल करने में सक्षम होने के बारे में है। आपकी खोज क्रिया हर बार स्टेटलेस है क्योंकि डेटा अब तक आपूर्ति की जाती है, सही? आपकी वैकल्पिक प्रदर्शन कार्रवाई भी स्टेटलेस है, बस एक अलग दृश्य है।

यदि वे मैन्युअल मार्ग या एक नया नियंत्रक होना चाहिए, तो यह इस बात पर निर्भर करता है कि गतिविधि कितनी अलग है। आपका वैकल्पिक दृश्य, यदि यह CRUD का एक पूरा सेट प्रदान करता है (बनाएं, पढ़ें, अपडेट करें, हटाएं) संचालन एक नए नियंत्रक में होना अच्छा होगा। यदि आपके पास डेटा के लिए केवल देखें, तो मैं केवल एक वैकल्पिक दृश्य क्रिया जोड़ूंगा।

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

Answer 3

मैं का index के विशेष मामले के रूप में व्यवहार करता हूं। दोनों कार्य संसाधनों का संग्रह वापस करते हैं। अनुरोध पैरामीटर को पेज, सीमा, सॉर्ट ऑर्डर और खोज क्वेरी जैसी चीजें निर्दिष्ट करनी चाहिए।

उदाहरण के लिए:

/resources/index # normal index 
/resources/index?query=foo # search for 'foo' 

और resources_controller में:

before_filter :do_some_preprocessing_on_parameters 

def index 
    @resources = Resource.find_by_param(@preprocessed_params) 
end 

index_full और search_by_name का सवाल है, तो आप दो में अपने वर्तमान नियंत्रक बंटवारे पर लग सकता है। आपने जो वर्णन किया है उसके बारे में एक गंध है।

यह कहकर, आप बिल्कुल सही हैं कि आपके ऐप को उपयोगकर्ता को सुरक्षित मार्गों पर मजबूर करने में कोई बात नहीं है जब यह /:controller/:action/:id पर कुछ भी वितरित नहीं करता है। निर्णय लेने के लिए, देखें कि आप कितनी बार फॉर्म और लिंक में शेष संसाधन मार्ग सहायकों का उपयोग कर रहे हैं। यदि आप उनका उपयोग नहीं कर रहे हैं, तो मैं इससे परेशान नहीं होगा।

Answer 4

अपने डिज़ाइन में रीस्टफुल रहने के लिए, आपको उस संसाधन पर पुनर्विचार करना होगा जिसे आप संसाधन कहते हैं।

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

मेरा में, मैं एक डैशबोर्ड नियंत्रक (शो) और यथा-स्थान ecditors (शो और अद्यतन)

Answer 5

मेरी राय वे यहाँ रेल बंद एक सा हो गया है हो सकता है में से एक क्षेत्र के लिए नियंत्रकों की है। डीआरवाई के साथ क्या हुआ?

मैं अभी बीटा के बाद से इसके साथ बहुत अधिक विकास नहीं कर रहा रेल में वापस आ रहा हूं और मैं अभी भी प्रकाश-बल्ब के आने का इंतजार कर रहा हूं। मैं अभी भी इसे एक मौका दे रहा हूं लेकिन अगर यह मेरे वर्तमान प्रोजेक्ट के अंत तक मेरे लिए नहीं हुआ है तो शायद मैं पुराने मानक मार्गों पर बस वापस आऊंगा और विधियों को परिभाषित करूँगा क्योंकि मुझे वास्तव में उन्हें अगले के लिए चाहिए ।

Answer 6

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

डिफ़ॉल्ट मार्ग के साथ मेरी मुख्य समस्या यह है कि यदि आपके पास एक ही रेल ऐप का उपयोग करके कई साइटें हैं तो यह भयानक लग सकती है।

http://example1.somesite.com/example_2/foo/bar/1 

/:controller/:action/:id 

को यह तुलना इस नियंत्रक example_2 करने के लिए जाना होगा:

उदाहरण के लिए वहाँ नियंत्रकों है कि आप लोगों के लिए एक अनुप्रयोग पर देखने में सक्षम हो नहीं करना चाहते हो सकता है/foo, एक्शन बार और आईडी 1

मैं इसे रेल के डिफ़ॉल्ट मार्ग का मुख्य दोष मानता हूं और यह ऐसा कुछ है जो विश्वसनीय मार्ग (सबडोमेन एक्सटेंशन के साथ) या केवल नामित मार्ग (map.connect 'foo' ...) ठीक कर सकते हैं।