एउटा एपीआई लेखियो - XML ​​(दुई) च्यात्यो

पहिलो MySklad API 10 वर्ष पहिले देखा पर्‍यो। यो सबै समय हामी API को अवस्थित संस्करणहरूमा काम गर्दैछौं र नयाँहरू विकास गर्दैछौं। र API को धेरै संस्करणहरू पहिले नै गाडिएको छ।

यस लेखमा धेरै चीजहरू समावेश हुनेछ: कसरी एपीआई सिर्जना गरियो, किन क्लाउड सेवालाई यसको आवश्यकता छ, यसले प्रयोगकर्ताहरूलाई के दिन्छ, हामीले कुन गल्तीहरूमा कदम चाल्न व्यवस्थित गर्यौं र हामी के गर्न चाहन्छौं।

मेरो नाम Oleg Alekseev हो oleexeev, म MySklad को प्राविधिक निर्देशक र सह-संस्थापक हुँ।

किन सेवाको लागि एपीआई बनाउनुहोस्

हाम्रा ग्राहकहरू, जो हजारौं उद्यमीहरू छन्, सक्रिय रूपमा क्लाउड समाधानहरू प्रयोग गर्छन्: बैंकिङ, अनलाइन स्टोर, कमोडिटी लेखा, CRM। एकपटक तपाईंले एकसँग जडान गर्नुभयो, यसलाई रोक्न गाह्रो छ। र अब पाँचौं, आठौं, दशौं सेवाले उद्यमीको कामलाई सजिलो बनाउँछ, तर प्रयोगकर्ताहरूले यी क्लाउड सेवाहरू बीच म्यानुअल रूपमा डेटा स्थानान्तरण गर्छन्। काम दुःस्वप्नमा परिणत हुन्छ।

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

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

यदि तपाइँ तपाइँको आफ्नै प्रोग्रामिंग इन्टरफेसहरू सिर्जना गर्नुहुन्छ भने, यसले तेस्रो-पक्ष बिक्री व्यक्तिहरूलाई प्रोग्रामरहरूको रूपमा आकर्षित गर्दछ जसले API लाई तपाइँको उत्पादनको बारेमा जान्दछन्। तिनीहरू प्रस्तावित API मा आधारित समाधानहरू निर्माण गर्न थाल्छन् र आफ्ना ग्राहकहरूको कार्यहरू स्वचालित गरेर पैसा कमाउँछन्।

MySklad लेखा प्रणाली सरल प्रक्रियाहरूमा आधारित छ। मुख्य कुरा भनेको प्राथमिक कागजातहरू, सामानहरू स्वीकार गर्ने र ढुवानी गर्ने क्षमता, र प्राथमिक कागजातहरूमा आधारित व्यापार रिपोर्टहरू प्राप्त गर्ने काम गर्नु हो। त्यहाँ डेटाको स्थानान्तरण पनि छ, उदाहरणका लागि क्लाउड लेखा, र बैंकिङ प्रणाली वा खुद्रा आउटलेटहरूबाट यसको रसिद। हामी अनलाइन स्टोरहरूसँग पनि काम गर्छौं: हामी उत्पादनहरूको बारेमा जानकारी प्राप्त गर्छौं र ब्यालेन्सको बारेमा जानकारी पठाउँछौं।

MySklad को पहिलो API

MySklad API सँग काम गरेको १० वर्षमा, हामीले सबै प्रकारका एकीकरणहरू प्राप्त गरेका छौं जसले हामीलाई डाटा आदानप्रदान गर्न, बैंकहरूसँग काम गर्न, भुक्तानी गर्न र बाह्य टेलिफोनी प्रयोग गर्न अनुमति दिन्छ।

पहिलो वर्षमा, हामीले XML ढाँचामा कुनै पनि डाटा डाउनलोड गर्न सम्भव बनायौं। त्यसबेला, प्रयोगकर्ताहरूका लागि डाटा अफलाइन राख्नु धेरै स्पष्ट र सामान्य थियो, र केही क्लाउडमा होइन, र हामीले तिनीहरूलाई दियौं। अपलोड इन्टरफेसबाट म्यानुअल निर्यात द्वारा सुरु गरिएको थियो। अर्थात्, यसलाई अझै API भन्न सकिँदैन।

एकै समयमा, हामीले रुसाग्रो कम्पनीसँग सहकार्य गर्न थाल्यौं - तिनीहरूले उत्पादन र बिक्री योजनाको लागि पहिले नै "वयस्क" ईआरपी प्रयोग गरिरहेका थिए, तर तिनीहरूले माइस्क्लाडका कारखानाहरूमा कारहरूको लोडिङ स्वचालित गरे। यसरी हामीले वास्तविक API को पहिलो आधारहरू पायौं: हाम्रो सेवा र ERP बीचको आदानप्रदान सबै प्रकारका कागजातहरूमा डेटा सहितको ठूलो फाइल पठाएर भयो।

यो ब्याच डाटा एक्सचेन्जको लागि राम्रो विकल्प हो, तर कागजातहरूको साथमा हामीले तिनीहरूको निर्भरताहरू स्थानान्तरण गर्नुपर्‍यो: सामानहरू, ठेकेदारहरू र गोदामहरू बारे जानकारी। यस्तो डम्प निर्यात गर्दा उत्पन्न गर्न गाह्रो छैन, तर आयात गर्दा पार्स गर्न धेरै गाह्रो छ, किनकि सबै जानकारी एक प्याकेजमा आउँछ: दुवै नयाँ कागजातहरू र अवस्थितको बारेमा।

पहिलो XML API लामो समयसम्म बाँच्न सकेन - दुई वर्ष पछि हामीले यसलाई पुन: निर्माण गर्न थाल्यौं। यसको कामको सुरुमा पनि, हामीले सफ्टवेयर इन्टरफेस निर्माण गर्दा धेरै गल्तीहरू गर्यौं।

XML API कसरी बनाइयो: हाम्रा आर्किटेक्टहरू मध्ये एकबाट चित्रण। खैर, उहाँका लेखहरूको लागि ट्युन रहनुहोस्।

यहाँ हाम्रा मुख्य गल्तीहरू छन्:

1. JAXB मार्कअप सिधै इकाई बीन्समा गरिएको थियो। हामी डाटाबेससँग सञ्चार गर्न हाइबरनेट प्रयोग गर्छौं, र JAXB मार्कअप उही बीन्सका लागि बनाइएको थियो। यो त्रुटि लगभग तुरुन्तै देखा पर्‍यो: डाटा संरचनामा कुनै पनि अद्यावधिकले एपीआई प्रयोग गर्ने सबैलाई तुरुन्तै सूचित गर्न वा अघिल्लो डेटा संरचनासँग अनुकूलता सुनिश्चित गर्ने बैसाखीहरू निर्माण गर्न आवश्यक भयो।
2. API एड-अनको रूपमा बढ्यो, र हामीले सुरुमा उत्पादनको कुन भाग हो भनेर परिभाषित गरेका थिएनौं। तिनीहरूले एपीआई महत्त्वपूर्ण कुरा हो कि भनेर सोचेनन्, चाहे यसको पहिलो ग्राहकहरूको लागि पछाडि अनुकूलता कायम राख्न आवश्यक थियो। एक बिन्दुमा, API प्रयोगकर्ताहरूको संख्या सानो संख्याको लगभग 5% थियो, र तिनीहरूलाई कुनै ध्यान दिइएन। एकै समयमा गरिएको सार्वभौमिक फिल्टरिङले हामीलाई ब्याकइन्डको रूपमा प्रयोग गरिदियो। यो फिल्टरिङ बिल्कुल GraphQL थिएन, तर यस्तो केहि - यसले धेरै क्वेरी स्ट्रिङ प्यारामिटरहरू मार्फत काम गर्यो। यस्तो शक्तिशाली उपकरणको साथ, प्रयोगकर्ताहरूलाई प्रतिरोध गर्न गाह्रो थियो, र अनुरोधहरू हामीलाई हस्तान्तरण गरियो ताकि तिनीहरू सीधै तिनीहरूको अनलाइन स्टोरहरूको UI बाट पठाइयो। स्थिति एक अप्रिय आश्चर्य थियो, किनभने यस्तो सेवा को प्रावधान फरक मूल्य निर्धारण र एक उत्पादन को रूप मा API को सामान्य रूपमा फरक बुझाइ आवश्यक पर्छ।
3. एपीआई मुख्य उत्पादनको रूपमा विकसित नभएको कारणले गर्दा, एपीआई कागजातहरू अवशिष्ट आधारमा उत्पादन र प्रकाशित गरिएको थियो - रिभर्स इन्जिनियरिङ मार्फत। यो बाटो एकदम सरल र सुविधाजनक देखिन्छ, तर यो एक सम्झौता अन्तर्गत काम विरोधाभास छ। यो तब हुन्छ जब त्यहाँ प्रिसेट अपरेटिङ योजनाको साथ एक निश्चित घटक हुन्छ। विकासकर्ताले यसलाई यो योजना र कार्य अनुसार लागू गर्दछ, कम्पोनेन्ट परीक्षण गरिन्छ, र ग्राहकले विश्लेषकको विचारसँग मेल खाने उत्पादन प्राप्त गर्दछ। रिभर्स इन्जिनियरिङले बजारमा एउटा उत्पादन फ्याँक्छ जुन केवल अवस्थित छ: आवश्यक कार्यक्षमताको सट्टा बैसाखी, अनौठो समाधान र साइकलहरू।
4. एपीआई मार्फत आएका अनुरोधहरूको सम्पूर्ण स्ट्रिमलाई Nginx वा अनुप्रयोग सर्भर लग भन्दा बढीको रूपमा विश्लेषण गर्न सकिन्छ। यसले हामीलाई विषय क्षेत्रहरू पहिचान गर्न अनुमति दिँदैन, सायद प्रयोगकर्ताहरू र सदस्यहरू बाहेक। यदि त्यहाँ आवेदन वा ग्राहक दर्ता विनियमित गर्न कुनै तरिका छैन भने, यो स्थिति विश्लेषण गर्न असम्भव हुन्छ। यस समस्याले API को विकासमा कम प्रभाव पारेको थियो; यो यसको सान्दर्भिकता र कार्यक्षमता बुझ्नको बारेमा हो।

प्रयास नम्बर दुई: REST API

2010 मा, हामीले अनलाइन लेखा - BukhSoft को साथ एक विनिमय प्रणाली निर्माण गर्ने प्रयास गर्यौं। उडेको छैन । तर एकीकरण प्रक्रियाको क्रममा, एक पूर्ण विकसित API देखा पर्‍यो: एक REST एक्सचेन्ज सेवा, जहाँ RPC कलहरूको रूपमा सञ्चालनहरू पहुँच गर्ने जस्ता कुनै स्वतन्त्रताहरू थिएनन्। एपीआई संग सबै संचार आराम को लागी मानक मोड मा ल्याइएको थियो: क्वेरी लाइन इकाई को नाम समावेश गर्दछ, र यो संग प्रदर्शन गरिएको अपरेशन HTTP विधि प्रयोग गरी निर्दिष्ट गरिएको छ। हामीले संस्थाहरू कहिले अद्यावधिक गरिएका थिए भन्ने आधारमा फिल्टरिङ थप्यौं, र प्रयोगकर्ताहरूसँग अब तिनीहरूको प्रणालीहरूसँग प्रतिकृति निर्माण गर्ने अवसर छ।

सोही वर्षमा, गोदाम र इन्भेन्टरी ब्यालेन्स अनलोड गर्ने API देखा पर्‍यो। प्रणालीको सबैभन्दा मूल्यवान भागहरू API मार्फत प्रयोगकर्ताहरूका लागि उपलब्ध भएका छन् - प्राथमिक कागजातहरूको आदानप्रदान र ब्यालेन्स र सामानको लागतमा गणना गरिएको डाटा।

डिसेम्बर 2015 मा, RetailCRM ले हाम्रो API पहुँच गर्न पहिलो तेस्रो-पक्ष पुस्तकालय प्रकाशित गर्‍यो। यो एकदम सक्रिय रूपमा प्रयोग हुन थाल्यो, जबकि सेवाको लोकप्रियता समग्र रूपमा बढ्यो, API मा लोड वेब इन्टरफेसमा लोड भन्दा छिटो बढ्यो। एक दिनको वृद्धि लोड वृद्धिमा परिणत भयो।

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

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

यसलाई क्रमबद्ध गरौं

2014 देखि पहिले नै, अवस्थित API को लागि माग व्यापार को एक महत्वपूर्ण भाग भएको छ, र API ले ग्राहकहरु संग डाटा को आदान प्रदान मा डाटा को सबैभन्दा ठूलो मात्रा उत्पन्न गर्दछ। 2015 मा, हामीले API सफा गर्न एउटा परियोजना सुरु गर्यौं। हामीले XML को सट्टा JSON लाई ढाँचाको रूपमा रोज्यौं र अघिल्लो संस्करणको कार्यान्वयनको क्रममा पहिचान गरिएका सुविधाहरूको आधारमा यसलाई निर्माण गर्न थाल्यौं:

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

त्यसबेलादेखि, हामीले API को दुई साना संस्करणहरू जारी गरेका छौं र धेरै विशेष API हरू सुरू गरेका छौं, तर समग्र दृष्टिकोण अपरिवर्तित रहेको छ। अपडेट गरिएको एक्सचेन्ज ढाँचा र नयाँ वास्तुकलाले API मा भएका त्रुटिहरूलाई धेरै छिटो सुधार गर्न सम्भव बनायो।

MySklad API आज

आज, MySklad API ले धेरै समस्याहरू समाधान गर्दछ:

• अनलाइन स्टोर, लेखा प्रणाली, बैंकहरु संग डाटा विनिमय;
• गणना डाटा र रिपोर्ट प्राप्त गर्दै;
• ग्राहक अनुप्रयोगहरूको लागि ब्याकइन्डको रूपमा प्रयोग गर्नुहोस् - हाम्रो मोबाइल अनुप्रयोगहरू र डेस्कटप नगद दर्ता API मार्फत काम गर्दछ
• MySklad - webhooks मा डाटा परिवर्तन बारे सूचनाहरू पठाउँदै;
• टेलिफोनी;
• वफादारी प्रणालीहरू।

API मा आधारित, हाम्रो सीईओ Askar Rakhimberdiev रियोनो चार घण्टामा मैले एउटा टेलिग्राम बोट लेखें जसले एपीआई मार्फत अवशेषहरू तान्छ: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

अब सुक्खा नम्बरहरू।

यहाँ पुरानो REST API को लागि हाम्रो तथ्याङ्कहरू छन्:

• 400 कम्पनीहरु;
• 600 प्रयोगकर्ताहरू;
• प्रति दिन 2 मिलियन अनुरोधहरू;
• 200 GB/दिन बाहिर जाने ट्राफिक।

र यहाँ हामीले सबै MySklad API को लागि के लिएर आएका छौं:

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

अब के

API विकास योजनाहरू सक्रिय छलफलमा छन्। हामी प्रयोगकर्ताहरूले हामीलाई प्रदान गर्ने अपरेटिङ अनुभवलाई ध्यानमा राख्ने प्रयास गर्छौं। सबै कुरा एकै पटक गर्न सधैं सम्भव छैन, तर API को नयाँ संस्करण अधिक सुविधाजनक मेटाडेटा र कम फ्लफी संरचना, प्रमाणीकरणको लागि OAuth, र इन्टरफेसमा निर्मित अनुप्रयोगहरूको लागि API को साथ कुनाको वरिपरि छ।

तपाईं MySklad सँग एकीकरणका विकासकर्ताहरूको लागि विशेष वेबसाइटमा समाचारहरू पालना गर्न सक्नुहुन्छ: dev.moysklad.ru मा.

स्रोत: www.habr.com