एपीआई टूट को रोकने में मदद करने के लिए किसी को आमतौर पर REST सेवाओं के लिए एक क्लाइंट लाइब्रेरी विकसित करनी चाहिए?

Question

हमारे पास एक परियोजना है जहां यूआई कोड एक ही टीम द्वारा विकसित किया जाएगा लेकिन सेवाओं की परत (REST / Java) से एक अलग भाषा (पायथन / Django) में। प्रत्येक परत के लिए कोड अलग-अलग कोड रिपॉजिटरी में बाहर निकलता है और जो अलग-अलग रिलीज चक्र का पालन कर सकता है। मैं एक ऐसी प्रक्रिया के साथ आने की कोशिश कर रहा हूं, जो यूआई परत के परिप्रेक्ष्य से सेवाओं की परत में परिवर्तन को रोक / कम कर देगी।

मैंने UI लेयर स्तर पर एकीकरण परीक्षण लिखने के लिए सोचा है कि जब भी हम UI या सेवाओं की परत का निर्माण करेंगे (हम कोड को बनाने के लिए हमारे CI टूल के रूप में जेनकिंस का उपयोग कर रहे हैं जो दो Git repos में है) और यदि विफलताएं हैं, तो सेवाओं की परत में कुछ टूट गया और कमिट स्वीकार नहीं किया गया।

क्या यह भी एक अच्छा विचार होगा (क्या यह एक सर्वोत्तम अभ्यास है?) यूआई लेयर में मौजूद REST सेवा के लिए क्लाइंट लायब्रेरी बनाने और बनाए रखने के लिए डेवलपर की परत है कि जब भी कोई ब्रेकिंग चेंज होगा तो वे अपडेट करेंगे। उनकी सेवा एपीआई यकीनन, तब हमें एक स्टेटिकली टाइप्ड एपीआई का फायदा होगा जो यूआई कोड बनाता है। यदि क्लाइंट लाइब्रेरी API बदलता है, तो UI कोड संकलित नहीं होगा (इसलिए हम जल्द ही जान लेंगे कि एक ब्रेकिंग परिवर्तन था)। मैं अभी भी यूआई या सेवाओं की परत बनाने पर एकीकरण परीक्षण चलाऊंगा ताकि यह साबित हो सके कि यूआई और सेवा (एस) के बीच एकीकरण अभी भी काम करता है।

Comments

जब एपीआई में बदलाव किया जाता है तो क्या यह आपको सूचित नहीं किया जाता है? इन मामलों में अक्सर एपीआई का सबसे अच्छा संस्करण होता है, इसलिए आपके यूआई में हमेशा काम करने वाला संस्करण होता है। फिर जल्द से जल्द अंतिम एपीआई संस्करण में "अपग्रेड" करें।

— मैट एस

@ मैट्स: मैं आपसे सहमत हूं। लेकिन संचार के साथ या बिना: एक बदले हुए एपीआई में अपग्रेड करना बहुत आसान है जब कंपाइलर आपको बताता है कि आपको अपने कोड में सभी स्थानों को बदलना होगा। हालांकि ओपी अभी भी यह बताने से चूकता है कि उसका पायथन कोड एक वैधानिक रूप से टाइप किया हुआ एपीआई कैसे प्रदान करेगा।

— डॉक ब्राउन

Answer 1

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

सेवा एपीआई के भीतर प्रवेश करना एक बात है, लेकिन उपभोग करने वाले ग्राहकों को सचेत करना एक और बात है। बाकी के लिए, मुझे नहीं लगता कि एक ठोस, मानक अभ्यास है। फोरस्क्वेयर एपीआई क्लाइंट पदावनत विधियों की खोज कर सकते हैं, भले ही कहा गया तरीका सफल हो (HTTP 200 कोड, हालाँकि एरर टाइप 'डिप्रेस्ड' पर सेट होगा)। संभवतः ब्रेक के कारण के बिना एपीआई के भीतर एक पदावनत विधि के ज्ञान के अवसर के साथ उपभोग्य ग्राहकों को प्रदान करने के लिए एक उचित रणनीति।

https://developer.foursquare.com/overview/responses

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

Answer 2

अपने एपीआई का संस्करण एक और संभावना है। जब एक नया संस्करण तैनात किया जाता है, तो पुराने संस्करण को भी सक्रिय छोड़ दें और अनुरोध के माध्यम से बातचीत की अनुमति दें। यदि आप हाल के 2 या 3 संस्करणों को बनाए रखते हैं, तो UI कोड अपनी गति से अपग्रेड कर सकता है।

Answer 3

एक साथ कम से कम तीन प्रश्न हैं, चलो उन्हें एक-एक करके करते हैं

• "REST सेवा के लिए क्लाइंट लाइब्रेरी होना एक अच्छा विचार है?"

जब तक आप अपने सभी यूआई कोड के माध्यम से सीधे बिखरे हुए मनमाने ढंग से REST कॉल नहीं चाहते हैं, तब तक शायद सबसे हाँ, हाँ।

• "क्या यह एक अच्छा विचार है कि सर्विस लेयर के डेवलपर को लेबर बनाने और बनाए रखने दें?"

जो आपकी टीम के व्यक्तियों पर निर्भर करता है। एपीआई के अनुरक्षक को दोनों को पता होना चाहिए, सेवाओं की परत में उपलब्ध चीजें और साथ ही UI परत की आवश्यकताएं। तो यह या तो सेवाओं की परत से एक व्यक्ति हो सकता है या यूआई परत से एक हो सकता है, या दोनों टीमों के एक व्यक्ति (आकार और अन्य कार्यों के आधार पर) स्वतंत्र रूप से हो सकता है।

• [क्या हम इस तथ्य से लाभ प्राप्त करेंगे कि] "यदि क्लाइंट लाइब्रेरी API बदलता है, तो UI कोड संकलित नहीं होगा"

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