"सार्वजनिक एपीआई हमेशा के लिए हैं: इसे सही करने का केवल एक मौका"?


20

OS पुस्तक में मैंने सिर्फ यह पढ़ा है कि, "सार्वजनिक API हमेशा के लिए है: इसे सही करने का केवल एक मौका"। क्या यह सच है? क्या यह केवल ऑपरेटिंग सिस्टम के एपीआई या अन्य एपीआई में भी लागू है? उदाहरण के लिए, क्या यह एंड्रॉइड एप्लिकेशन के एपीआई जैसे कि टास्कर, लोकेल और पुशओवर के लिए सही होगा?


2
मैं सिद्धांत को सभी कोड तक विस्तारित करूंगा। एक ही चीज़ को कई बार लिखने के लिए पर्याप्त समय नहीं है। परफेक्ट कोड लिखना एक कौशल है जिसे सीखा जा सकता है।
tp1

22
@ tp1: सही कोड लिखना एक कौशल है जो वास्तविक दुनिया में मौजूद नहीं है।
माइकल बोर्गवर्ड

4
@michael बोर्गवर्ड: बस किस संस्करण का उपयोग करने की आवश्यकता है।
tp1

1
मैंने इसे वास्तविक दुनिया में देखा है, और यह इस बात पर निर्भर करता है कि एपीआई किस प्रकार का है। सबक सीखा: किसी भी "सार्वजनिक सामना" वेब एपीआई में पहली आवश्यकता एपीआई उपयोगकर्ता के लिए एपीआई के किस संस्करण का उपयोग करने की क्षमता है।
जोश पेटिट

जवाबों:


32

यह आम तौर पर किसी भी सार्वजनिक एपीआई के लिए सही है, हाँ। एक बार जब आप जनता के लिए एक एपीआई को उजागर करते हैं और लोग उस एपीआई पर निर्भर अनुप्रयोगों का निर्माण करना शुरू करते हैं, तो एपीआई को बदलना बहुत मुश्किल हो जाता है क्योंकि ऐसा करने से उन सभी अनुप्रयोगों को तोड़ दिया जाएगा। यह एक कठिन तकनीकी समस्या और एक कठिन राजनीतिक समस्या दोनों है।

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


2
"दोनों एक कठिन तकनीकी समस्या और एक कठिन तकनीकी समस्या" आपने दो बार "तकनीकी" दोहराई।
luiscubal

12
@luiscubal: ऐसा इसलिए है क्योंकि यह वास्तव में एक कठिन तकनीकी समस्या है।
माइकल बोर्गवर्ड

3
@luiscubal आप एक बार मतलब है। एक बार दोहराया, दो बार कहा।
जो जे।

4
"सार्वजनिक उत्तर हमेशा के लिए नहीं हैं ..."
क्रिस

3
@ क्रिस वास्तव में नहीं। जस्टिन का जवाब अब लुइसुबल की टिप्पणी के अनुकूल नहीं है। :-)
svick

12

उद्धरण लेखक जोशुआ बलोच हैं, यह कथन उनके बम्पर-स्टिकर एपीआई डिज़ाइन लेख से है:

सार्वजनिक एपीआई, हीरे की तरह, हमेशा के लिए हैं। आपके पास इसे पाने का एक मौका है इसलिए इसे अपना सर्वश्रेष्ठ दें।

उस पर अधिक जानकारी के लिए, लेखक अपने सम्मेलन सत्र की प्रस्तुति के लिए पाठकों को संदर्भित करता है, "हाउ टू डिजाईन ए गुड एपीआई एंड व्हाई इट मैटर्स" । स्लाइड क्यों एपीआई डिजाइन करने के लिए महत्वपूर्ण है आप यह कहा गया सुंदर स्पष्ट रूप से है कि इस किसी भी प्रोग्रामिंग गतिविधि के लिए प्रासंगिक (ऑपरेटिंग सिस्टम नहीं है बात करने के लिए लेखक या न मानो,) है:

  • यदि आप प्रोग्राम करते हैं, तो आप एक एपीआई डिजाइनर हैं

    • अच्छा कोड मॉड्यूलर है - प्रत्येक मॉड्यूल में एक एपीआई है
  • उपयोगी मॉड्यूल पुन: उपयोग करने के लिए करते हैं

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

स्लाइड निष्कर्ष भी एक सामान्य दृष्टिकोण के रूप में इस पर जोर देता है:

  • एपीआई डिजाइन एक महान और पुरस्कृत शिल्प है

    • प्रोग्रामर, अंत उपयोगकर्ताओं, कंपनियों के बहुत सुधार ...

2
तकनीकी रूप से हीरा मेटास्टेबल है। थर्मोडायनामिक रूप से बोलना, ग्रेफाइट कार्बन का अधिक स्थिर रूप है।
3

3

एपीआई हमेशा बदलते हैं, अन्यथा सिस्टम अपग्रेड का क्या मतलब होगा? केवल आंतरिक बदलना?

सिस्टम का प्रत्येक संस्करण नए एपीआई लाता है, पुराने एपीआई अप्रचलित हो जाते हैं और अप्रचलित एपीआई गायब हो जाते हैं।

एपीआई परिवर्तन केवल तकनीकी रूप से और संचार के मामले में बहुत सावधान रहना होगा।


जब तक आप अपने सभी उपभोक्ताओं के साथ अच्छी तरह से बातचीत कर सकते हैं और वे अपने उपयोगकर्ताओं से बात नहीं कर सकते हैं - विंडोज को देखें: विंडोज में पुराने, अपवित्र, खराब एपीआई जैसे अंत उपयोगकर्ता हैं जो आधुनिक सिस्टम पर भी बेहद पुराने एप्लिकेशन चलाना पसंद करते हैं
'24

2

मेरी राय यह होगी कि एक बार जारी होने के बाद, एपीआई का वह 'संस्करण' हमेशा के लिए है, लेकिन आप इसे '2.0' एपीआई जारी करके इसे अलग कर सकते हैं (ऐसे कई उदाहरण हैं जहां यह हो रहा है - वर्तमान में, मैं स्ट्रवा के बारे में सोच सकता हूं जिन्होंने जारी किया है उनकी सेवाओं का उपभोग करने के खिलाफ विकास के लिए एक एपीआई का 2.0 संस्करण)।

समस्या यह है कि मूल API विज्ञापन infinitum का समर्थन कर रहा है ... मुझे लगता है कि यह पुराने API के उपयोग पर निर्भर करता है, और उन API उपभोक्ताओं का मूल्य आपके लिए क्या है।

विंडोज 3.x और 9x आदि के 'पुराने दिनों' में जाने के बाद, एक बार रिलीज़ होने के बाद, उन ओएस एपीआई को किया गया और सेट किया गया। अब, OS अपडेट को हर समय धकेल दिया जाता है, इसलिए नए API जारी किए जा सकते हैं, लेकिन मुझे लगता है कि जब तक आप किसी विशेष OS फ्लेवर (प्रमुख रिलीज़) को चला रहे हैं, उन API को केवल जोड़ा जाएगा, कभी हटाया नहीं ... हो सकता है हालांकि 'अगली' प्रमुख रिलीज के लिए मामला हो।

हम्म, शायद मैं मूल प्रश्न इरादे से भटक गया।


1

यह इस बात पर निर्भर करता है कि यह किस तरह का एपीआई है (और मैं ब्रेकिंग परिवर्तन मान रहा हूं, अन्यथा कथन स्पष्ट रूप से सत्य नहीं है)।

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

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

ग्रिपिंग हाथ पर, कम से कम एक एपीआई प्रदाता है जो लगातार एपीआई में परिवर्तन तोड़ना शुरू करता है और वैसे भी हास्यास्पद रूप से सफल होता है: फेसबुक। लेकिन वे बहुत सावधानी से परिवर्तनों का प्रबंधन करते हैं: एक प्रकाशित नीति है , कम से कम 90 दिन पहले परिवर्तन की घोषणा की जाती है और समझाया जाता है, और डेवलपर्स उस समय सीमा के भीतर उन्हें सक्रिय करने का विकल्प चुन सकते हैं।


1

यदि आपके पास एपीआई में ही संस्करण संख्या शामिल करने की दूरदर्शिता है। या तो कनेक्शन / आरंभीकरण कॉल पर, या, कहीं न कहीं प्रत्येक कॉल पर पैरामीटर सूची की शुरुआत के पास, तो आपका एपीआई मौजूदा क्लाइंट को बाधित किए बिना समय के साथ विकसित और म्यूट कर सकता है।


0

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


-1

किसी भी समय आप किसी भी प्रकार के संचार प्रोटोकॉल जारी करते हैं, जिसमें स्पष्ट रूप से एक एपीआई शामिल होता है, आपके पास इसे सही अर्थों में प्राप्त करने का एक मौका होता है कि प्रोटोकॉल / इंटरफ़ेस पीछे की ओर संगत और एक्स्टेंसिबल होना चाहिए।

यह आपको नई कार्यक्षमता जोड़ने और पुराने संस्करणों का उपयोग करने वाले लोगों को तोड़ने की चिंता किए बिना नए संस्करण जारी करने की अनुमति देता है। कभी भी सॉफ्टवेयर की दुनिया में आप एक ऐसी स्थिति में नहीं जा सकते हैं जहाँ आप एक निश्चित समय में एक कठिन कटओवर पा सकते हैं, और हर कोई पुराने संस्करण को छोड़ देता है और नए संस्करण का उपयोग करना शुरू कर देता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.