एपीआई पिछड़ा संगतता

Question

के लिए सर्वोत्तम प्रथाएं मैं एक आईफोन/आईपैड/एंड्रॉइड ऐप पर काम कर रहा हूं जो एक JSON API के साथ संचार करता है।

ऐप के संस्करण की पहली रिलीज पूरी हो गई है, और अब विकास के अतिरिक्त चरण हो रहे हैं। अतिरिक्त चरणों में, ऐप को एपीआई के एक नए संस्करण के साथ एकीकृत करने की आवश्यकता है और उपयोगकर्ता को अतिरिक्त स्क्रीन जैसे नई स्क्रीन या मौजूदा स्क्रीन के भीतर संशोधित व्यवहार तक पहुंचने की अनुमति है। ऐप को एपीआई के पिछले संस्करणों के साथ पीछे की ओर होना चाहिए।

ऐसी आवश्यकता से निपटने के लिए सबसे अच्छा अभ्यास क्या है? मैं कोड भर जांच कर सकता है हो सकता है:

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

} else if (APIVersion == ....) { 

}... 

लेकिन मैं इस दृष्टिकोण की क्षमता को लेकर चिंतित हूं। फैक्ट्री विधि दिमाग में आती है लेकिन मुझे यकीन नहीं है कि यह मुझे कितना दूर करेगा।

धन्यवाद, मार्क

Answer 1

एक नए API संस्करण के रिलीज एक बहुत ही दुर्लभ बात है। आम तौर पर आप नए वैकल्पिक पैरामीटर या नई विधियों को जोड़कर पिछड़ा-संगतता प्राप्त कर सकते हैं। उदाहरण के लिए, आप विधि नाम दिया था search, लेकिन अब आप जिस तरह से यह काम करता है से असंतुष्ट हैं, तो आप विभिन्न तरीकों से इसके साथ सौदा हो सकता है:

• परिवर्तन सरल है तो आप एक नया mode पैरामीटर जोड़ सकते हैं जो mode1 पर डिफ़ॉल्ट (इसलिए यह पिछड़ा-संगत है)। यदि उपयोगकर्ता mode2 की आपूर्ति करता है तो आप इसे उचित if स्थिति के साथ पहचानते हैं जैसा आपने स्वयं प्रस्तावित किया था। (इसके अलावा, आमतौर पर आप "मोड" से बेहतर नाम के बारे में सोच सकते हैं।)

• यदि परिवर्तन एक बड़ा है, तो आप एक नया search2 सेवा जोड़ सकते हैं जो नए इंटरफ़ेस का उपयोग करता है। फिर आप search विधि को बहिष्कृत के रूप में चिह्नित करते हैं (लेकिन अभी भी काम कर रहे हैं और पिछड़े-संगत)। आमतौर पर जब आप ऐसा करते हैं, आप refactor इस तरह से अपने कोड, कि लगभग सभी तर्क के search2 विधि के अंदर है सकते हैं, और अपने पुराने search विधि आंतरिक search2 कॉल संशोधित मानकों के साथ (और फिर से प्रारूपों परिणाम उचित रूप से) । यदि आप इसे सही तरीके से करते हैं, तो आपको अब कभी भी search विधि बदलने की आवश्यकता नहीं होगी। जब आप अपनी टेबल इत्यादि बदलते हैं - आपको केवल search2 को संशोधित करने की आवश्यकता होगी।

मेरा मुद्दा है, N+1-एपीआई के संस्करण को जारी करने से बचें।इस तरह की बड़ी रिलीज का मतलब है कि आपकी विधियों के सभी में केवल एक ही बदलाव नहीं है। कई प्रमुख एपीआई ने कभी भी अपने एपीआई के संस्करण 2 को जारी नहीं किया है, फिर भी वे संस्करण 1 का उपयोग करते हैं, बस इसके उदाहरणों में थोड़ा बदलाव करते हैं।

आप पूरी तरह से सुनिश्चित आप एपीआई के N+1 -ST संस्करण जारी के बारे में, सभी अपने तरीकों में से के लिए नए प्रवेश बिंदुओं बनाने हैं। अगर आपके पास services नामक फ़ोल्डर था, तो services-v2 नामक नया नाम बनाएं। अपने services कोड को दोबारा दोहराएं ताकि यह services-v2 का सबसे अधिक उपयोग कर सके। अगर आपको लगता है कि यह अधिक है, तो मुझे लगता है कि आपको अभी तक अपने एपीआई के N+1 -st संस्करण की आवश्यकता नहीं है।

बीटीडब्ल्यू, वितरित लोगों (जैसे एंड्रॉइड) के साथ केंद्रीकृत एपीआई (जैसे Google मानचित्र) को भ्रमित न करें। एंड्रॉइड हर समय नए एपीआई संस्करण जारी करता है, क्योंकि अरबों एंड्रॉइड सर्वर हैं (प्रत्येक एंड्रॉइड डिवाइस एक है), और वे सभी को Google द्वारा दूरस्थ रूप से अपग्रेड नहीं किया जा सकता है। एंड्रॉइड का अगला संस्करण अभी भी पिछले के साथ पिछड़ा-संगत है, संख्या केवल नई सुविधाओं को इंगित करने के लिए बढ़ी है। ईजी। आप अभी भी एंड्रॉइड 7.0 पर एंड्रॉइड 3.0 के लिए बनाए गए ऐप्स चला सकते हैं (उपयोगकर्ता को कुछ अतिरिक्त चेतावनियां मिल सकती हैं, लेकिन ऐप चलाएगा)। एंड्रॉइड ऐप डेवलपर्स इन ऐप्स का उपयोग अपने ऐप्स के लिए "न्यूनतम आवश्यकताओं" का वर्णन करने के लिए करते हैं। जबकि, केंद्रीकृत एपीआई आमतौर पर एक प्रमुख पिछड़ा-असंगत परिवर्तन इंगित करने के लिए अपने संस्करण संख्या को बढ़ाते हैं।

Answer 2

मैं आप पहले से ही चिंताओं में से एक जुदाई है लगता है। मेरा मतलब है, अपने ऐप के लिए डेटा प्राप्त करना केवल मॉडल के माध्यम से किया जाता है (उदाहरण के लिए)।

तो आपको केवल मॉडल को बदलना होगा।

मेरा सुझाव है कि केवल एक प्रविष्टि बिंदु है: "राउटर" फ़ाइल। यह फ़ाइल आवश्यक एपीआई संस्करण की जांच करता है, और सही फ़ाइल लोड करता है। इस तरह, आप प्रत्येक एपीआई के लिए अलग-अलग फाइलें प्राप्त करते हैं। "राउटर" फ़ाइल बहुत बड़ी नहीं होगी, और प्रत्येक नए एपीआई संस्करण की अपनी फाइल होगी, इसलिए आप सबकुछ मिश्रण नहीं कर रहे हैं।

उदाहरण के लिए, "रूटर" फ़ाइल में:

function dispatch() { 
    switch (APIVersion) { 
    case 1: 
     use('file.1.ext'); 
     break; 
    case 2: 
     use('file.2.ext'); 
     break; 
    case 3: 
     use('file.3.ext'); 
     break; 
    } 
}