एक एपीआई लिखा - एक्सएमएल फाड़ दिया (दो)

पहला MySklad API 10 साल पहले सामने आया था। इस पूरे समय हम एपीआई के मौजूदा संस्करणों पर काम कर रहे हैं और नए विकसित कर रहे हैं। और एपीआई के कई संस्करण पहले ही दफन कर दिए गए हैं।

इस लेख में बहुत सी बातें होंगी: एपीआई कैसे बनाई गई, क्लाउड सेवा को इसकी आवश्यकता क्यों है, यह उपयोगकर्ताओं को क्या देती है, हम किन गलतियों से बच गए और हम आगे क्या करना चाहते हैं।

मेरा नाम ओलेग अलेक्सेव है oalexeev, मैं MySklad का तकनीकी निदेशक और सह-संस्थापक हूं।

किसी सेवा के लिए एपीआई क्यों बनाएं?

हमारे ग्राहक, जो हजारों उद्यमी हैं, सक्रिय रूप से क्लाउड समाधानों का उपयोग करते हैं: बैंकिंग, ऑनलाइन स्टोर, कमोडिटी अकाउंटिंग, सीआरएम। एक बार जब आप किसी से जुड़ जाते हैं, तो उसे रोकना कठिन होता है। और अब पांचवीं, आठवीं, दसवीं सेवा उद्यमी के काम को आसान बनाती है, लेकिन उपयोगकर्ता इन क्लाउड सेवाओं के बीच मैन्युअल रूप से डेटा ट्रांसफर करते हैं। काम एक दुःस्वप्न में बदल जाता है.

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

इसलिए, अगला कदम एपीआई है। इसके साथ, क्लाउड सेवा को इस तथ्य से लाभ होता है कि यह एक ही बिंदु पर कई सेवाओं को जोड़ती है। ऐसे पारिस्थितिकी तंत्र का उद्भव अतिरिक्त अवसरों के कारण नए ग्राहकों को आकर्षित करता है। नई कार्यक्षमता वाला उत्पाद अधिक लाभदायक और उपयोगी हो जाता है।

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

MySklad लेखा प्रणाली सरल प्रक्रियाओं पर आधारित है। मुख्य बात प्राथमिक दस्तावेजों के साथ काम करना, माल स्वीकार करने और भेजने की क्षमता और प्राथमिक दस्तावेजों के आधार पर व्यावसायिक रिपोर्ट प्राप्त करना है। डेटा का स्थानांतरण भी होता है, उदाहरण के लिए क्लाउड अकाउंटिंग में, और बैंकिंग सिस्टम या खुदरा दुकानों से इसकी प्राप्ति। हम ऑनलाइन स्टोर के साथ भी काम करते हैं: हम उत्पादों के बारे में जानकारी प्राप्त करते हैं और शेष राशि के बारे में जानकारी भेजते हैं।

MySklad का पहला एपीआई

MySklad के एपीआई के साथ काम करने के 10 वर्षों में, हमने सभी प्रकार के एकीकरण हासिल कर लिए हैं जो हमें डेटा का आदान-प्रदान करने, बैंकों के साथ काम करने, भुगतान करने और बाहरी टेलीफोनी का उपयोग करने की अनुमति देते हैं।

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

उसी समय, हमने रुसाग्रो कंपनी के साथ सहयोग करना शुरू किया - वे पहले से ही उत्पादन और बिक्री योजना के लिए "वयस्क" ईआरपी का उपयोग कर रहे थे, लेकिन उन्होंने MySklad में कारखानों में कारों की लोडिंग को स्वचालित कर दिया। इस तरह हमें वास्तविक एपीआई की पहली मूल बातें प्राप्त हुईं: हमारी सेवा और ईआरपी के बीच आदान-प्रदान सभी प्रकार के दस्तावेजों पर डेटा के साथ एक बड़ी फ़ाइल भेजकर हुआ।

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

पहला XML API अधिक समय तक नहीं चला - दो साल बाद हमने इसका पुनर्निर्माण शुरू किया। यहां तक ​​कि इसके काम की शुरुआत में, सॉफ़्टवेयर इंटरफ़ेस बनाते समय हमने कई गलतियाँ कीं।

XML API कैसे बनाया गया: हमारे एक आर्किटेक्ट का चित्रण। वैसे, उनके लेखों के लिए बने रहें।

यहाँ हमारी मुख्य गलतियाँ हैं:

1. JAXB मार्कअप सीधे इकाई बीन्स पर किया गया था। हम डेटाबेस के साथ संचार करने के लिए हाइबरनेट का उपयोग करते हैं, और JAXB मार्कअप उसी बीन्स के लिए बनाया गया था। यह त्रुटि लगभग तुरंत सामने आई: डेटा संरचना में किसी भी अपडेट के कारण एपीआई का उपयोग करने वाले सभी लोगों को तत्काल सूचित करने या बैसाखी बनाने की आवश्यकता हुई जो पिछली डेटा संरचना के साथ संगतता सुनिश्चित करेगी।
2. एपीआई एक ऐड-ऑन के रूप में विकसित हुआ, और हमने शुरू में यह परिभाषित नहीं किया कि यह उत्पाद का कौन सा हिस्सा था। उन्होंने इस बारे में नहीं सोचा कि क्या एपीआई कुछ महत्वपूर्ण थी या क्या इसके पहले ग्राहकों के लिए बैकवर्ड संगतता बनाए रखना आवश्यक था। एक समय पर, एपीआई उपयोगकर्ताओं की संख्या छोटी संख्या का लगभग 5% थी, और उन पर कोई ध्यान नहीं दिया गया था। एक समय में की गई सार्वभौमिक फ़िल्टरिंग के कारण हमें बैकएंड के रूप में उपयोग किया जाने लगा। यह फ़िल्टरिंग बिल्कुल भी GraphQL नहीं थी, लेकिन ऐसा कुछ था - यह बहुत सारे क्वेरी स्ट्रिंग पैरामीटर के माध्यम से काम करता था। ऐसे शक्तिशाली टूल के साथ, उपयोगकर्ताओं के लिए विरोध करना मुश्किल था, और अनुरोध हमें स्थानांतरित कर दिए गए ताकि वे सीधे उनके ऑनलाइन स्टोर के यूआई से भेजे जा सकें। स्थिति एक अप्रिय आश्चर्य थी, क्योंकि ऐसी सेवा के प्रावधान के लिए अलग-अलग मूल्य निर्धारण और एक उत्पाद के रूप में एपीआई की आम तौर पर अलग समझ की आवश्यकता होनी चाहिए।
3. इस तथ्य के कारण कि एपीआई को मुख्य उत्पाद के रूप में विकसित नहीं किया गया था, एपीआई दस्तावेज़ीकरण को रिवर्स इंजीनियरिंग के माध्यम से अवशिष्ट आधार पर उत्पादित और प्रकाशित किया गया था। यह रास्ता काफी सरल और सुविधाजनक लगता है, लेकिन यह एक अनुबंध के तहत काम करने के विपरीत है। ऐसा तब होता है जब प्रीसेट ऑपरेटिंग स्कीम के साथ एक निश्चित घटक होता है। डेवलपर इसे इस योजना और कार्य के अनुसार कार्यान्वित करता है, घटक का परीक्षण किया जाता है, और ग्राहक को एक उत्पाद प्राप्त होता है जो विश्लेषक के विचार से मेल खाता है। रिवर्स इंजीनियरिंग बाजार में एक ऐसा उत्पाद लाती है जो बस अस्तित्व में है: आवश्यक कार्यक्षमता के बजाय बैसाखी, अजीब समाधान और साइकिल के साथ।
4. एपीआई के माध्यम से आए अनुरोधों की पूरी धारा का विश्लेषण Nginx या एप्लिकेशन सर्वर लॉग से ज्यादा कुछ नहीं किया जा सकता है। इसने हमें संभवतः उपयोगकर्ताओं और ग्राहकों को छोड़कर, विषय क्षेत्रों की पहचान करने की अनुमति नहीं दी। यदि एप्लिकेशन या क्लाइंट पंजीकरण को विनियमित करने का कोई तरीका नहीं है, तो स्थिति का विश्लेषण करना असंभव हो जाता है। इस समस्या का एपीआई के विकास पर सबसे कम प्रभाव पड़ा, यह इसकी प्रासंगिकता और कार्यक्षमता को समझने के बारे में अधिक था।

प्रयास संख्या दो: REST API

2010 में, हमने ऑनलाइन अकाउंटिंग के साथ एक एक्सचेंज सिस्टम - बुकसॉफ्ट बनाने की कोशिश की। नहीं उतारी. लेकिन एकीकरण प्रक्रिया के दौरान, एक पूर्ण एपीआई सामने आई: एक आरईएसटी एक्सचेंज सेवा, जहां आरपीसी कॉल के रूप में संचालन तक पहुंचने जैसी कोई स्वतंत्रता नहीं थी। एपीआई के साथ सभी संचार को आराम के लिए मानक मोड में लाया गया था: क्वेरी लाइन में इकाई का नाम होता है, और इसके साथ किया जाने वाला ऑपरेशन http विधि का उपयोग करके निर्दिष्ट किया जाता है। हमने इकाइयों को अद्यतन किए जाने के आधार पर फ़िल्टरिंग जोड़ी है, और उपयोगकर्ताओं के पास अब अपने सिस्टम के साथ प्रतिकृति बनाने का अवसर है।

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

दिसंबर 2015 में, RetailCRM ने हमारे एपीआई तक पहुंचने के लिए पहली तृतीय-पक्ष लाइब्रेरी प्रकाशित की। इसका उपयोग काफी सक्रिय रूप से किया जाने लगा, जबकि समग्र रूप से सेवा की लोकप्रियता बढ़ी, एपीआई पर लोड वेब इंटरफ़ेस पर लोड की तुलना में तेजी से बढ़ा। एक दिन वृद्धि भार वृद्धि में बदल गई।

और बाईं ओर तीर द्वारा इंगित इस छलांग ने हमारे एपीआई की सेवा करने वाले सर्वर को पूरी तरह से आश्चर्यचकित कर दिया। हमने यह पता लगाने में एक सप्ताह बिताया कि वास्तव में यह भार किस कारण उत्पन्न हो रहा है। यह पता चला कि ये वही अनुरोध हैं जो क्लाइंट मोर्चों से हमारे एपीआई को प्रेषित किए गए हैं। करीब 50 ग्राहकों ने सब कुछ खा लिया. तब हमें अपनी गलतियों में से एक का एहसास हुआ - सीमाओं का पूर्ण अभाव।

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

आइए इसे क्रम में रखें

2014 से ही, मौजूदा एपीआई की मांग व्यवसाय का एक महत्वपूर्ण हिस्सा बन गई है, और एपीआई ने ही ग्राहकों के साथ डेटा के आदान-प्रदान में सबसे बड़ी मात्रा में डेटा उत्पन्न किया है। 2015 में, हमने एपीआई को साफ़ करने के लिए एक प्रोजेक्ट लॉन्च किया। हमने प्रारूप के रूप में XML के बजाय JSON को चुना और पिछले संस्करण के कार्यान्वयन के दौरान पहचानी गई सुविधाओं के आधार पर इसे बनाना शुरू किया:

1. संस्करणों को प्रबंधित करने की क्षमता. वर्जनिंग आपको मौजूदा एप्लिकेशन को प्रभावित किए बिना या उपयोगकर्ता अनुभव को बाधित किए बिना एक नया संस्करण विकसित करने की अनुमति देता है।
2. उपयोगकर्ता को प्राप्त होने वाली प्रतिक्रिया में ही मेटाडेटा देखने की क्षमता।
3. बड़े दस्तावेज़ों का आदान-प्रदान करने की क्षमता. यदि हम किसी दस्तावेज़ को 4-5 हजार से अधिक पदों के साथ संसाधित करते हैं, तो यह सर्वर के लिए एक समस्या बन जाती है: एक लंबा लेनदेन, एक लंबा http अनुरोध। हमने एक विशेष तंत्र बनाया है जो आपको किसी दस्तावेज़ को भागों में अद्यतन करने और सर्वर पर भेजकर इस दस्तावेज़ की अलग-अलग स्थितियों को प्रबंधित करने की अनुमति देता है।
4. प्रतिकृति के लिए उपकरण पिछले संस्करण में भी मौजूद थे।
5. लोड सीमा उस रेक की विरासत की तरह है जिसे पिछले संस्करण में लगाया गया था। हमने एक समयावधि में अनुरोधों की संख्या, समानांतर अनुरोधों की संख्या और एक आईपी पते से अनुरोधों पर सीमाएं लागू कीं।

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

MySklad API आज

आज, MySklad API कई समस्याओं का समाधान करता है:

• ऑनलाइन स्टोर, लेखा प्रणाली, बैंकों के साथ डेटा विनिमय;
• परिकलित डेटा और रिपोर्ट प्राप्त करना;
• क्लाइंट एप्लिकेशन के लिए बैकएंड के रूप में उपयोग करें - हमारे मोबाइल एप्लिकेशन और डेस्कटॉप कैश रजिस्टर एपीआई के माध्यम से काम करते हैं
• MySklad - वेबहुक में डेटा परिवर्तन के बारे में सूचनाएं भेजना;
• टेलीफोनी;
• वफादारी प्रणाली.

एपीआई के आधार पर, हमारे सीईओ आस्कर राखीम्बरडीव राइनो चार घंटों में मैंने एक टेलीग्राम बॉट लिखा जो एपीआई के माध्यम से बचे हुए को खींचता है: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

अब सूखे नंबर.

पुराने REST API के लिए हमारे आंकड़े यहां दिए गए हैं:

• 400 कंपनियाँ;
• 600 उपयोगकर्ता;
• प्रति दिन 2 मिलियन अनुरोध;
• 200 जीबी/दिन का आउटगोइंग ट्रैफ़िक।

और यहां हम सभी MySklad API के लिए क्या लेकर आए हैं:

• 70 से अधिक एकीकरण (उनमें से कुछ को यहां देखा जा सकता है www.moysklad.ru/integratsii);
• 8500 कंपनियाँ;
• 12 उपयोगकर्ता;
• प्रति दिन 46 मिलियन अनुरोध;
• आउटगोइंग ट्रैफ़िक का 2 टीबी/दिन।

आगे क्या है

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

आप MySklad के साथ एकीकरण के डेवलपर्स के लिए एक विशेष वेबसाइट पर समाचार का अनुसरण कर सकते हैं: dev.moysklad.ru.

स्रोत: www.habr.com