व्यापार के लिए एपीआई-प्रथम विकास: क्यों और कब
फ्रेज़ एपीआई-फर्स्ट इंजीनियरिंग का एक फैड लग सकता है, लेकिन यह वास्तव में एक व्यावसायिक निर्णय है। यह निर्धारित करता है कि आप नए चैनल कितनी तेजी से और कितनी सस्ती कीमत पर लॉन्च कर सकते हैं, भागीदारों को कैसे ऑनबोर्ड कर सकते हैं और विक्रेता के परिवर्तन से कैसे बच सकते हैं। यह लेख प्रचार को छोड़ता है और बताता है कि एपीआई-फर्स्ट का क्या मतलब है, यह आपके व्यवसाय को क्या देता है, यह कहाँ फायदेमंद है और कहाँ यह अधिक है, और हम इसे अपने उत्पादों में कैसे लागू करते हैं।
API-प्रथम का अर्थ साधारण शब्दों में क्या है
साधारण विकास अक्सर इस तरह होता है: आप पहले वेबसाइट या ऐप बनाते हैं, और जब मोबाइल संस्करण या बाहरी एकीकरण की आवश्यकता होती है, तो एक API को समाप्त कोड पर बाद में जोड़ा जाता है। API-प्रथम क्रम को उलट देता है। आप पहले अनुबंध डिजाइन करते हैं - उन विधियों का सेट जो कोई भी क्लाइंट (वेबसाइट, मोबाइल ऐप, भागीदार, आंतरिक सेवा) डेटा पढ़ने और क्रियाएँ करने के लिए उपयोग करता है - और केवल तब इंटरफ़ेस और इसके चारों ओर सब कुछ बनाते हैं।
मुख्य विचार यह है कि API एक सेवा द्वार बनना बंद कर देता है और मुख्य उत्पाद बन जाता है। इस चित्र में वेबसाइट आपके API का केवल एक क्लाइंट है, जो मोबाइल ऐप या भागीदार डैशबोर्ड के साथ समान स्तर पर है। अनुबंध पहले से सहमति की जाती है: कौन से फ़ील्ड, कौन से स्थिति, त्रुटि पर क्या होता है। वहां से टीमें उस समझौते के खिलाफ काम करती हैं न कि किसी और के कोड के खिलाफ।
एक तर्क, कई चैनल
API-प्रथम का मुख्य व्यावसायिक लाभ है पुनः उपयोग. भुगतान, कैटलॉग, प्रमाणीकरण या मूल्य गणना के लिए लॉजिक एक बार लिखा और परीक्षण किया जाता है। वेब, मोबाइल ऐप, चैटबॉट, एक इन-स्टोर टिल और एक पार्टनर डैशबोर्ड सभी एक ही विधियों को कॉल करते हैं। आप तीन बार ऑर्डर बनाने को लागू नहीं करते और इसमें तीन अलग-अलग बग्स का पीछा नहीं करते।
व्यवसाय के लिए यह सीधे बचत है। वेबसाइट के बाद मोबाइल ऐप लॉन्च करना अब एक नए सिरे से प्रोजेक्ट नहीं है: इंटरफेस नया है, लेकिन पूरी सर्वर-साइड लॉजिक पहले से ही बनाई और परीक्षण की गई है। एक नया बिक्री चैनल तेजी से और सस्ते में शिप होता है, और व्यवहार हर जगह समान रहता है - ऐप में मूल्य साइट पर मूल्य से भटकता नहीं है, क्योंकि सत्य का एक ही स्रोत है।
एकीकरण, भागीदार और पारिस्थितिकी तंत्र
एक व्यवसाय लगभग कभी भी एक वैक्यूम में नहीं रहता: सीआरएम, लेखांकन, विश्लेषण, भुगतान प्रणाली, मार्केटप्लेस। जब एक उत्पाद के पास पहले दिन से एक साफ एपीआई होता है, तो प्रत्येक ऐसा एकीकरण एक मौजूदा अनुबंध से जुड़ाव होता है न कि एक मोनोलिथ पर सर्जरी। एक पार्टनर आपकी सेवा को एम्बेड कर सकता है, और आप किसी और के उत्पाद का हिस्सा बन सकते हैं।
एक सार्वजनिक एपीआई एक अलग विकास मॉडल को अनलॉक करता है। यह पार्टनरों को आपके उत्पाद के शीर्ष पर अपने स्वयं के परिदृश्य बनाने की अनुमति देता है और आपको दूसरों के हाथों के माध्यम से स्केल करने की अनुमति देता है। यही भुगतान गेटवे और सास प्लेटफार्मों का काम करने का तरीका है: एकीकरणकर्ता ग्राहकों को लाते हैं क्योंकि कनेक्ट करना आसान है, और हर नया एकीकरण आपके पहुंच को बिना सीधे विपणन खर्च के बढ़ाता है।
समानांतर कार्य और टीम की गति
एक सहमति अनुबंध भी काम को समानांतर करने का एक तरीका है। एक बार जब टीमों ने विधियों के आकार पर समझौता कर लिया, तो फ्रंटेंड और बैकेंड एक-दूसरे का इंतजार करना बंद कर देते हैं। मोबाइल डेवलपर्स एक के खिलाफ कोड करते हैं मॉक सर्वरजो अनुबंध को दर्शाता है जबकि सर्वर साइड अभी भी पूरा किया जा रहा है। जब टुकड़े मिलते हैं, तो दोनों पक्ष तैयार होते हैं और परियोजना कभी भी रुकती नहीं है।
यहां तक कि जब आप विक्रेता बदलते हैं या टीम बढ़ाते हैं, तो यही सिद्धांत मदद करता है। एक नए व्यक्ति को पूरे कोडबेस को पढ़ने की आवश्यकता नहीं है - API दस्तावेज़ यह समझने के लिए पर्याप्त है कि सिस्टम क्या कर सकता है। अनुबंध व्यवसाय, डिज़ाइन और इंजीनियरिंग के बीच एक साझा भाषा बन जाता है, और उस एक डेवलपर पर निर्भरता को कम करता है जो सब कुछ याद रखता है।
जब API-प्रथम इसके लायक है, और जब यह नहीं है
यह दृष्टिकोण मुफ्त नहीं है, और यह स्वीकार करना उचित है कि यह हमेशा आवश्यक नहीं है। API-प्रथम तब लाभदायक होता है जब आप योजना बनाते हैंकई चैनल (साइट और ऐप), एकीकरण और भागीदारों की अपेक्षा करते हैं, दीर्घकालिक के लिए निर्माण कर रहे हैं, या बड़े समानांतर टीमों का संचालन कर रहे हैं। एक उत्पाद जितना लंबा जीवित रहता है और जितने अधिक उपभोक्ता होते हैं, उतनी ही अधिक प्रारंभिक अनुशासन अपने आप को चुकता करता है।
- लागू करने लायक: मार्केटप्लेस, फिनटेक, SaaS, ऐसे उत्पाद जिनमें मोबाइल ऐप और वेब संस्करण दोनों हैं, भागीदार कार्यक्रम के साथ प्लेटफार्म।
- सरल बनाया जा सकता है: एकल-पृष्ठ लैंडिंग, एक प्रोमो साइट, एक MVP जो जल्दी से एक परिकल्पना का परीक्षण करने के लिए बनाया गया है, जहां एक दूसरा चैनल अभी भी बहुत दूर है।
एक छोटे साइट के लिए, एक पूर्ण अनुबंध का डिज़ाइन करना अत्यधिक है। फिर भी, यह डेटा और प्रस्तुति के बीच एक साफ विभाजन बनाए रखने में मदद करता है ताकि आपको बाद में सब कुछ फिर से लिखना न पड़े।
इस दृष्टिकोण की लागत
API-प्रथम की अपनी कीमत है, और इसे शुरू में सहमत करना महत्वपूर्ण है। अनुबंध को लिखने से पहले अच्छी तरह से सोचना होगा - परियोजना की शुरुआत में एक विश्लेषक और एक आर्किटेक्ट के लिए अतिरिक्त काम। इसके बाद API को संस्करणित: एक बार जब बाहरी ग्राहक इस पर निर्भर हो जाते हैं, तो आप उनकी एकीकरण को तोड़े बिना चुपचाप प्रतिक्रिया प्रारूप को नहीं बदल सकते।
ऐसी दस्तावेज़ीकरण जोड़ें जिसे वर्तमान में बनाए रखा जाना चाहिए, और सुरक्षा पर समर्पित ध्यान: प्रमाणीकरण, दर सीमित करना, इनपुट मान्यता। इनमें से सभी का लाभ होता है, लेकिन यह परिपक्व प्रक्रियाओं की मांग करता है। इसलिए यह महत्वपूर्ण है कि API-प्रथम को एक पंथ में न बदलें: आज और निकट भविष्य में उत्पाद की आवश्यकता के अनुसार ठीक अनुबंध डिज़ाइन करें, बिना किसी इंटरफेस के सिर्फ मामले में।
हम अपने उत्पादों में API-प्रथम कैसे लागू करते हैं
हम डिजिटल उत्पादों का डिज़ाइन करते हैं, केवल वेबसाइटों का नहीं, इसलिए API-प्रथम हमारे लिए एक कार्य मानक है न कि एक नारा। एक अच्छा उदाहरण है Payora, हमारा भुगतान गेटवे। पूरी एकीकरण एक छोटे सेट के REST विधियों के चारों ओर बनाई गई है: एक चालान बनाना, इसकी स्थिति की जांच करना, भुगतान विवरण प्राप्त करना। इसके साथ एक तैयार-निर्मित होस्टेड चेकआउट और साइन किए गए वेबहुक्स जो दुकान को बताता है कि भुगतान हो गया है। दुकान को भुगतान स्क्रीन बनाने या ब्लॉकचेन को समझने की आवश्यकता नहीं है - यह एक स्पष्ट अनुबंध के साथ काम करता है।
एक और उदाहरण है Astrina, एक SaaS प्लेटफॉर्म जिसमें एक सार्वजनिक डेवलपर API है। बाहरी डेवलपर्स इसके विधियों को एक कुंजी के साथ कॉल करते हैं, और कोटा और स्थिति प्रतिक्रिया में वापस आती है। आर्किटेक्चरल रूप से हम भागों को उपडोमेन में विभाजित करते हैं - API अलग, भुगतान स्क्रीन अलग, प्रशासन पैनल अलग - ताकि प्रत्येक अपनी खुद की कैशिंग और सुरक्षा नीति रख सके और स्वतंत्र रूप से स्केल कर सके। आप देख सकते हैं कि यह हमारे पोर्टफोलियो.
कहाँ से शुरू करें
में अन्य परियोजनाओं में कैसा दिखता है। यदि आप एक से अधिक चैनल, एकीकरण या एक भागीदार कार्यक्रम की योजना बना रहे हैं, तो API-प्रथम लगभग निश्चित रूप से आपको पैसे और सिरदर्द बचाएगा - लेकिन निर्णय विकास शुरू होने से पहले किया जाना चाहिए, बाद में नहीं। सही पहला कदम तुरंत API लिखना नहीं है, बल्कि यह परिभाषित करना है कि कौन एक या दो साल में सिस्टम का उपभोग करेगा और उनके लिए अनुबंध डिजाइन करना है।
हम डिजाइन चरण में ठीक यही करने में मदद करते हैं: हम परिदृश्यों के माध्यम से काम करते हैं, अनुबंध और संस्करणन को स्थापित करते हैं, और यह आंकलन करते हैं कि दृष्टिकोण कहां सार्थक है और कहां यह अधिक है। हमें अपने कार्य के बारे में बताएं संपर्क फ़ॉर्म के माध्यम से — हम एक आर्किटेक्चर का प्रस्ताव देंगे जिसे आपको दूसरे चैनल के लॉन्च होने पर फिर से लिखने की आवश्यकता नहीं होगी।
अक्सर पूछे जाने वाले प्रश्न
सरल शब्दों में API-first क्या है?
यह एक दृष्टिकोण है जहाँ आप पहले API अनुबंध को डिज़ाइन करते हैं — डेटा पढ़ने और क्रियाएँ करने के लिए विधियों का एक सेट — और वेबसाइट, मोबाइल ऐप और साझेदार एकीकरण सभी इसके समान ग्राहक बन जाते हैं। API मुख्य उत्पाद है, सेवा का एक अतिरिक्त नहीं।
API-first एक व्यवसाय को कैसे लाभ पहुंचाता है?
लॉजिक एक बार लिखा और परीक्षण किया जाता है और हर चैनल: वेब, मोबाइल, बॉट्स, साझेदार डैशबोर्ड में पुनः उपयोग किया जाता है। यह नए चैनलों को तेज करता है, एकीकरण को सरल बनाता है और एकल विक्रेता पर निर्भरता को कम करता है।
क्या आपको हमेशा API-first की आवश्यकता होती है?
नहीं। एक लैंडिंग पृष्ठ, एक प्रोमो साइट या एक त्वरित MVP के लिए एक पूर्ण अनुबंध अधिक है। यह दृष्टिकोण तब लाभदायक होता है जब आप कई चैनलों, एकीकरणों, एक साझेदार कार्यक्रम या एक लंबे उत्पाद जीवन की योजना बनाते हैं।
नुकसान क्या हैं?
आपको कोड से पहले अनुबंध को डिज़ाइन करना होगा, दस्तावेज़ बनाए रखना होगा, API का संस्करण करना होगा और सुरक्षा को अलग से संभालना होगा। यह प्रारंभ में अतिरिक्त काम है जो समय के साथ खुद को चुकता करता है लेकिन इसके लिए परिपक्व प्रक्रियाओं की आवश्यकता होती है।
सार्वजनिक API क्या है और एक व्यवसाय को इसकी आवश्यकता क्यों होती है?
यह एक API है जो बाहरी डेवलपर्स और भागीदारों के लिए खोला गया है। यह दूसरों को आपके उत्पाद को उनकी सेवाओं में एम्बेड करने और इंटीग्रेटर्स के माध्यम से आपके ग्राहक आधार को बढ़ाने की अनुमति देता है - जैसे कि भुगतान गेटवे और SaaS प्लेटफार्मों की तरह जैसे हमारा Payora और Astrina।
आप API-प्रथम में कैसे स्थानांतरित करना शुरू करते हैं?
डिज़ाइन से शुरू करें: प्रणाली के भविष्य के उपभोक्ताओं को परिभाषित करें, अनुबंध और संस्करणन नियमों का वर्णन करें, और यह आंकलन करें कि यह दृष्टिकोण कहाँ सार्थक है। संपर्क फ़ॉर्म के माध्यम से हमसे संदेश भेजें और हम आपके मामले के लिए एक आर्किटेक्चर का प्रस्ताव देंगे।
