एपीआई लिखा - टूट एक्सएमएल (दो)

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

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

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

किसी सेवा के लिए API क्यों बनाते हैं

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

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

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

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

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

पहला मायस्टोर एपीआई

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

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

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

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

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


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

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

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

नंबर दो का प्रयास करें: REST API

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

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

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





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

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

चुस्त-दुरुस्त

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

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

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

MyStore एपीआई आज

आज MyStore API कई समस्याओं को हल करता है:

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

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

अब सूखे नंबर।

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

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

और यहाँ हम सभी MyStore API के साथ आए हैं:

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

आगे क्या है

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

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