आरईएसटी एपीआई वर्जनिंग - मॉडल क्यों नहीं हैं

Question

मैं संस्करण आरईएसटी एपीआई के सभी दृष्टिकोणों पर पढ़ रहा हूं। लगभग सभी कार्यान्वयन में, नियंत्रक और विचार संस्करणित होते हैं, हालांकि मॉडल नहीं होते हैं।

# app/controllers/api/v1/events_controller.rb 
class Api::V1::EventsController < Api::ApiController 

end 

विचारों के अनुरूप के रूप में विभिन्न संस्करणीकृत निर्देशिका में में डाल दिया और साथ ही:

रेल उदाहरण के लिए, नियंत्रकों के रूप में व्यवस्थित होते हैं। हम संस्करण मॉडल क्यों नहीं करते? क्या ऐसा इसलिए है क्योंकि हम उम्मीद करते हैं कि हमारे मॉडल (अंतर्निहित डेटाबेस स्कीमा) को बदलने के लिए एपीआई विकसित नहीं होगा? क्या होता है जब मैं डेटाबेस में कॉलम नाम का नाम बदलता हूं और उसके लिए खाते के लिए एक नया मॉडल चाहिए?

Answer 1

मॉडल एप्लिकेशन के आंतरिक भाग का हिस्सा हैं, न कि इसकी सार्वजनिक एपीआई। कुंजी को वर्जनिंग करते समय इनपुट/आउटपुट विचलित नहीं होता है।

डेटाबेस में विभिन्न संस्करण डेटा को बनाए रखना - उदाहरण के लिए एक एपीआई के विभिन्न संस्करणों से संबंधित डेटा विशेष रूप से आकर्षक या व्यावहारिक नहीं है।

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

GET api/v1/users/:id 
    username (String) 
    first_name (String) 
    lastname (String) 

रिहाई आपको लगता है कि नामकरण असंगत है के बाद:

कहते हैं कि तुम जल्दी में एक API v 1 प्रकाशित किया है देता है। तो आप एक माइग्रेशन बनाएंगे जो lastname से last_name का नाम बदलता है।

तो एपीआई संस्करण 2 निम्नलिखित हस्ताक्षर होगा:

GET api/v2/users/:id 
    username (String) 
    first_name (String) 
    last_name (String) 

लेकिन चूंकि प्रतिक्रिया नहीं रह गया है lastname शामिल इस API v 1 के लिए एक परीक्षण का विश्लेषण करना चाहिए।

तो यह तय करने के लिए हम कुछ ऐसा बनाना होगा:

Api::V1::UserSerializer < ActiveModel::Serializer 
    attributes :username, :first_name, :lastname 

    def lastname 
    object.last_name 
    end 
end 

Answer 2

क्यों हम संस्करण मॉडल नहीं करते हैं?

मॉडल आमतौर पर डेटाबेस स्कीमा के साथ गठबंधन होते हैं। आम तौर पर डेटाबेस एपीआई के सभी संस्करणों द्वारा साझा किया गया एक कैनोलिक डेटा स्टोर है, इसलिए यह मॉडल के संस्करण के लिए ज्यादा समझ में नहीं आता है।

प्लस, रेल अनुप्रयोगों में, अक्सर थोक buisness तर्क मॉडल में रहता है। वर्जनिंग मॉडलों को या तो अवशोषण की दूसरी परत के तर्क या जोड़ को दोहराने की आवश्यकता होगी जो रखरखाव ओवरहेड पेश करता है।

क्या ऐसा इसलिए है क्योंकि हम उम्मीद करते हैं कि हमारे मॉडल (अंतर्निहित डेटाबेस स्कीमा) को एपीआई विकसित होने के रूप में बदलने की उम्मीद नहीं है?

नहीं डेटाबेस स्कीमा बहुत बार बदल सकता है और बदलता है।

क्या होता है जब मैं डेटाबेस में कॉलम नाम का नाम बदलता हूं और उसके लिए खाते के लिए एक नया मॉडल चाहिए?

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

एपीआई प्रतिक्रियाओं के लिए आपके buisness इकाइयों (मॉडल) के इस मैपिंग के बाद, नियंत्रकों (या धारावाहिक, या जेसन टेम्पलेट्स - आपके पसंदीदा कार्यान्वयन के आधार पर) में होता है - आपके आवेदन के इन हिस्सों को पिछड़ा सुनिश्चित करने के लिए संशोधित करना होगा संगतता।