rest - वर्जन एपीआई के लिए अंतर्निहित कोडबेस कैसे प्रबंधित करते हैं?




versioning api-versioning (2)

मैं रीस्ट एपीआई के लिए वर्जनिंग रणनीतियों पर पढ़ रहा हूं, और इनमें से कोई भी पता लगाने के लिए प्रकट नहीं होता है कि आप अंतर्निहित कोडबेस का प्रबंधन कैसे करते हैं।

आइए मान लें कि हम एक एपीआई में परिवर्तनों को तोड़ने का एक गुच्छा बना रहे हैं - उदाहरण के लिए, हमारे ग्राहक संसाधन को बदलना ताकि वह एक ही name फ़ील्ड के बजाय अलग-अलग forename और surname फ़ील्ड लौटा सके। (इस उदाहरण के लिए, मैं यूआरएल वर्जनिंग समाधान का उपयोग करूंगा क्योंकि इसमें शामिल अवधारणाओं को समझना आसान है, लेकिन सवाल सामग्री बातचीत या कस्टम HTTP शीर्षकों पर समान रूप से लागू होता है)

अब हमारे पास http://api.mycompany.com/v1/customers/{id} पर एक एंडपॉइंट है, और http://api.mycompany.com/v2/customers/{id} पर एक और असंगत अंतराल है। हम अभी भी v1 एपीआई में बगफिक्स और सुरक्षा अपडेट जारी कर रहे हैं, लेकिन नया फीचर डेवलपमेंट अब सभी v2 पर केंद्रित है। हम अपने एपीआई सर्वर में परिवर्तन कैसे लिखते हैं, परीक्षण करते हैं और तैनात करते हैं? मैं कम से कम दो समाधान देख सकता हूं:

  • V1 codebase के लिए स्रोत नियंत्रण शाखा / टैग का उपयोग करें। v1 और v2 को विकसित किया गया है, और स्वतंत्र रूप से तैनात किया गया है, संशोधन नियंत्रण विलय दोनों संस्करणों के लिए एक ही बगफिक्स को लागू करने के लिए आवश्यक रूप से विलय करता है - जैसा कि आप पिछले संस्करण का समर्थन करते हुए एक प्रमुख नए संस्करण को विकसित करते समय मूल ऐप्स के लिए कोडबेस प्रबंधित करते हैं।

  • कोडबेस स्वयं को एपीआई संस्करणों से अवगत कराएं, ताकि आप एक कोडबेस के साथ समाप्त हो जाएं जिसमें वी 1 ग्राहक प्रतिनिधित्व और v2 ग्राहक प्रतिनिधित्व दोनों शामिल हैं। तैनाती के मुद्दे के बजाय अपने समाधान आर्किटेक्चर के हिस्से के रूप में वर्जनिंग का इलाज करें - शायद नामस्थानों और रूटिंग के कुछ संयोजन का उपयोग करके यह सुनिश्चित करने के लिए कि सही संस्करण द्वारा अनुरोधों को संभाला जा सके।

शाखा मॉडल का स्पष्ट लाभ यह है कि पुराने एपीआई संस्करणों को हटाने के लिए यह छोटा है - बस उपयुक्त शाखा / टैग को तैनात करना बंद करें - लेकिन यदि आप कई संस्करण चला रहे हैं, तो आप वास्तव में एक मजबूत शाखा संरचना और तैनाती पाइपलाइन के साथ समाप्त हो सकते हैं। "एकीकृत कोडबेस" मॉडल इस समस्या से बचाता है, लेकिन (मुझे लगता है?) कोडबेज से बहिष्कृत संसाधनों और अंतराल को हटाने के लिए इसे अधिक कठिन बना देगा जब उन्हें अब आवश्यकता नहीं है। मुझे पता है कि यह संभवतः व्यक्तिपरक है क्योंकि एक साधारण सही उत्तर होने की संभावना नहीं है, लेकिन मुझे यह समझने में उत्सुकता है कि संगठन जो जटिल संस्करणों को कई संस्करणों में बनाए रखते हैं, इस समस्या को हल कर रहे हैं।


ब्रांचिंग मेरे लिए बहुत बेहतर लगती है, और मैंने अपने मामले में इस दृष्टिकोण का उपयोग किया।

हां जैसा कि आपने पहले ही उल्लेख किया है - बैक फिक्स को बैकपोर्ट करने के लिए कुछ प्रयासों की आवश्यकता होगी, लेकिन साथ ही साथ एक स्रोत बेस (रूटिंग और अन्य सभी सामानों के साथ) के कई संस्करणों का समर्थन करने के लिए आपको कम आवश्यकता होगी, लेकिन कम से कम एक ही प्रयास, सिस्टम को और अधिक बनाना तर्क के अंदर की विभिन्न शाखाओं के साथ जटिल और राक्षसी (संस्करण के कुछ बिंदु पर आप निश्चित रूप से बड़े case() आ जाएंगे case() कोड मॉड्यूल वाले संस्करण मॉड्यूल को इंगित करते हैं, या फिर भी if(version == 2) then... भी बदतर है। यह भी न भूलें कि रिग्रेशन प्रयोजनों के लिए आपको अभी भी परीक्षणों को ब्रांच करना है।

वर्जनिंग पॉलिसी के बारे में: मैं मौजूदा से अधिकतम -2 संस्करणों को रखता हूं, पुराने लोगों के लिए समर्थन को कम करता हूं - जो उपयोगकर्ताओं को स्थानांतरित करने के लिए कुछ प्रेरणा देगा।


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

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

कोडबेस को केवल नवीनतम संस्करण लागू करना चाहिए, v3 कहें। संगतता परत को नवीनतम संस्करण v3 और समर्थित संस्करणों जैसे v1 और v2 के बीच अनुरोध और प्रतिक्रिया को परिवर्तित करना चाहिए। संगतता परत में प्रत्येक समर्थित संस्करण के लिए एक अलग एडाप्टर हो सकते हैं जिसे श्रृंखला के रूप में जोड़ा जा सकता है।

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

क्लाइंट v1 अनुरोध: v1 v2 ---> v2 के अनुकूल है v3 ----> codebase के अनुकूल

क्लाइंट v2 अनुरोध: v1 v2 (वगैरह) के अनुकूल है ---> v2 v3 ----> codebase के अनुकूल

प्रतिक्रिया के लिए एडेप्टर बस विपरीत दिशा में काम करते हैं। यदि आप जावा ईई का उपयोग कर रहे हैं, तो आप उदाहरण के लिए एडाप्टर श्रृंखला के रूप में सर्वलेट फ़िल्टर श्रृंखला कर सकते हैं।

एक संस्करण को हटाने में आसान है, संबंधित एडाप्टर और टेस्ट कोड हटाएं।







api-versioning