एपीआय लिहिले - एक्सएमएल फाडले (दोन)

पहिले MySklad API 10 वर्षांपूर्वी दिसले. या सर्व काळात आम्ही API च्या विद्यमान आवृत्त्यांवर काम करत आहोत आणि नवीन विकसित करत आहोत. आणि API च्या अनेक आवृत्त्या आधीच पुरल्या गेल्या आहेत.

या लेखात बर्‍याच गोष्टी असतील: API कसे तयार केले गेले, क्लाउड सेवेला त्याची आवश्यकता का आहे, ते वापरकर्त्यांना काय देते, आम्ही कोणत्या चुकांवर पाऊल ठेवण्यास व्यवस्थापित केले आणि आम्हाला पुढे काय करायचे आहे.

माझे नाव ओलेग अलेक्सेव्ह आहे ओअलेक्सीव्ह, मी MySklad चा तांत्रिक संचालक आणि सह-संस्थापक आहे.

सेवेसाठी API का बनवा

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

वापरकर्त्यांना क्लाउड सेवांमध्ये डेटा हस्तांतरित करण्याची क्षमता देणे हा स्पष्ट उपाय आहे. उदाहरणार्थ, फायली म्हणून डेटा आयात आणि निर्यात करा, जो नंतर इच्छित सेवेवर अपलोड केला जाऊ शकतो. फायली सहसा प्रत्येक सेवेच्या स्वरूपानुसार बदलल्या जातात. हे कमी-अधिक सोपे मॅन्युअल कार्य आहे, परंतु या सेवांच्या संख्येत वाढ झाल्यामुळे ते करणे अधिकाधिक कठीण होत आहे.

म्हणून, पुढील चरण API आहे. यासह, क्लाउड सेवेचा फायदा होतो की ती एकाच वेळी अनेक सेवांना जोडते. अशा इकोसिस्टमचा उदय अतिरिक्त संधींमुळे नवीन ग्राहकांना आकर्षित करतो. नवीन कार्यक्षमतेसह उत्पादन अधिक फायदेशीर आणि उपयुक्त बनते.

तुम्ही तुमचे स्वतःचे प्रोग्रॅमिंग इंटरफेस तयार केल्यास, हे तृतीय-पक्ष सेल्स लोकांना प्रोग्रॅमरच्या रूपात आकर्षित करते ज्यांना API ला तुमच्या उत्पादनाबद्दल माहिती असते. ते प्रस्तावित API वर आधारित उपाय तयार करण्यास सुरवात करतात आणि त्यांच्या ग्राहकांची कार्ये स्वयंचलित करून पैसे कमवतात.

MySklad लेखा प्रणाली सोप्या प्रक्रियांवर आधारित आहे. मुख्य गोष्ट म्हणजे प्राथमिक कागदपत्रांसह कार्य करणे, वस्तू स्वीकारण्याची आणि पाठविण्याची क्षमता आणि प्राथमिक कागदपत्रांवर आधारित व्यवसाय अहवाल प्राप्त करणे. डेटाचे हस्तांतरण देखील आहे, उदाहरणार्थ क्लाउड अकाउंटिंगमध्ये, आणि बँकिंग सिस्टम किंवा रिटेल आउटलेटमधून त्याची पावती. आम्ही ऑनलाइन स्टोअरसह देखील कार्य करतो: आम्ही उत्पादनांबद्दल माहिती प्राप्त करतो आणि शिल्लक माहिती पाठवतो.

MySklad चे पहिले API

MySklad ने API सोबत काम करत असलेल्या 10 वर्षांमध्ये, आम्ही सर्व प्रकारचे एकत्रीकरण प्राप्त केले आहे जे आम्हाला डेटाची देवाणघेवाण करण्यास, बँकांसोबत काम करण्यास, पेमेंट करण्यास आणि बाह्य टेलिफोनी वापरण्याची परवानगी देतात.

पहिल्या वर्षी, आम्ही XML स्वरूपात कोणताही डेटा डाउनलोड करणे शक्य केले. तेव्हा, वापरकर्त्यांसाठी डेटा ऑफलाइन ठेवणे अधिक स्पष्ट आणि सामान्य होते, आणि काही क्लाउडमध्ये नाही, आणि आम्ही त्यांना ते दिले. इंटरफेसवरून मॅन्युअल एक्सपोर्ट करून अपलोड सुरू केले होते. म्हणजेच, त्याला अद्याप एपीआय म्हणता आले नाही.

त्याच वेळी, आम्ही रुसाग्रो कंपनीला सहकार्य करण्यास सुरवात केली - ते उत्पादन आणि विक्री नियोजनासाठी आधीपासूनच "प्रौढ" ईआरपी वापरत होते, परंतु त्यांनी मायस्क्लॅडमधील कारखान्यांमध्ये कार लोड करणे स्वयंचलित केले. अशा प्रकारे आम्हाला वास्तविक API चे पहिले मूलतत्त्व मिळाले: आमची सेवा आणि ERP मधील देवाणघेवाण सर्व प्रकारच्या दस्तऐवजांवर डेटा असलेली एक मोठी फाइल पाठवून झाली.

बॅच डेटा एक्सचेंजसाठी हा एक चांगला पर्याय आहे, परंतु दस्तऐवजांसह आम्हाला त्यांचे अवलंबित्व हस्तांतरित करावे लागले: वस्तू, कंत्राटदार आणि गोदामांची माहिती. निर्यात करताना असा डंप तयार करणे इतके अवघड नाही, परंतु आयात करताना विश्लेषण करणे खूप अवघड आहे, कारण सर्व माहिती एकाच पॅकेजमध्ये येते: नवीन कागदपत्रांबद्दल आणि विद्यमान कागदपत्रांबद्दल.

पहिले XML API फार काळ जगले नाही - दोन वर्षांनंतर आम्ही ते पुन्हा तयार करण्यास सुरुवात केली. अगदी त्याच्या कामाच्या सुरूवातीस, सॉफ्टवेअर इंटरफेस तयार करताना आम्ही अनेक चुका केल्या.

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

आमच्या मुख्य चुका येथे आहेत:

1. JAXB मार्कअप थेट एंटिटी बीन्सवर केले गेले. डेटाबेसशी संवाद साधण्यासाठी आम्ही हायबरनेट वापरतो आणि त्याच बीन्ससाठी JAXB मार्कअप बनवले होते. ही त्रुटी जवळजवळ लगेचच दिसून आली: डेटा संरचनेच्या कोणत्याही अद्यतनामुळे API वापरणार्‍या प्रत्येकाला त्वरित सूचित करण्याची किंवा मागील डेटा संरचनेशी सुसंगतता सुनिश्चित करणार्‍या क्रॅच तयार करण्याची आवश्यकता निर्माण झाली.
2. API एक ऍड-ऑन म्हणून वाढले आणि आम्ही उत्पादनाचा कोणता भाग आहे हे सुरुवातीला परिभाषित केले नाही. एपीआय काहीतरी महत्त्वाचे आहे का, त्याच्या पहिल्या क्लायंटसाठी मागास सुसंगतता राखणे आवश्यक आहे की नाही याचा त्यांनी विचारही केला नाही. एका क्षणी, API वापरकर्त्यांची संख्या लहान संख्येच्या सुमारे 5% होती आणि त्यांच्याकडे लक्ष दिले गेले नाही. एका वेळी केलेल्या सार्वत्रिक फिल्टरिंगमुळे आम्हाला बॅकएंड म्हणून वापरले जाऊ लागले. हे फिल्टरिंग अजिबात ग्राफक्यूएल नव्हते, परंतु असे काहीतरी होते - ते बर्याच क्वेरी स्ट्रिंग पॅरामीटर्सद्वारे कार्य करते. अशा शक्तिशाली साधनासह, वापरकर्त्यांना प्रतिकार करणे कठीण होते आणि आमच्याकडे विनंत्या हस्तांतरित केल्या गेल्या ज्यामुळे त्या थेट त्यांच्या ऑनलाइन स्टोअरच्या UI वरून पाठविल्या गेल्या. परिस्थिती एक अप्रिय आश्चर्यचकित होती, कारण अशा सेवेच्या तरतुदीसाठी भिन्न किंमत आणि उत्पादन म्हणून स्वतः API ची सामान्यत: भिन्न समज असणे आवश्यक आहे.
3. एपीआय मुख्य उत्पादन म्हणून विकसित न केल्यामुळे, एपीआय दस्तऐवजीकरण अवशिष्ट आधारावर तयार केले गेले आणि प्रकाशित केले गेले - उलट अभियांत्रिकीद्वारे. हा मार्ग अगदी सोपा आणि सोयीस्कर वाटतो, परंतु तो कराराच्या अंतर्गत काम करण्यास विरोध करतो. जेव्हा प्रीसेट ऑपरेटिंग स्कीमसह विशिष्ट घटक असतो तेव्हा असे होते. विकासक या योजनेनुसार आणि कार्यानुसार त्याची अंमलबजावणी करतो, घटकाची चाचणी केली जाते आणि क्लायंटला विश्लेषकाच्या कल्पनेशी जुळणारे उत्पादन प्राप्त होते. रिव्हर्स इंजिनिअरिंग एक उत्पादन बाजारात आणते जे फक्त अस्तित्वात आहे: आवश्यक कार्यक्षमतेऐवजी क्रॅच, विचित्र उपाय आणि सायकलीसह.
4. API द्वारे आलेल्या विनंत्यांच्या संपूर्ण प्रवाहाचे विश्लेषण Nginx किंवा ऍप्लिकेशन सर्व्हर लॉगपेक्षा अधिक काही नाही म्हणून केले जाऊ शकते. हे आम्हाला कदाचित वापरकर्ते आणि सदस्यांशिवाय विषय क्षेत्र ओळखू देत नाही. अर्ज किंवा क्लायंट नोंदणीचे नियमन करण्याचा कोणताही मार्ग नसल्यास, परिस्थितीचे विश्लेषण करणे अशक्य होते. या समस्येचा API च्या विकासावर कमीत कमी परिणाम झाला; त्याची प्रासंगिकता आणि कार्यक्षमता समजून घेणे अधिक आहे.

प्रयत्न क्रमांक दोन: REST API

2010 मध्ये, आम्ही ऑनलाइन अकाउंटिंगसह एक्सचेंज सिस्टम तयार करण्याचा प्रयत्न केला - BukhSoft. उतरवले नाही. परंतु एकीकरण प्रक्रियेदरम्यान, एक पूर्ण वाढ झालेला API दिसू लागला: एक REST एक्सचेंज सेवा, जिथे RPC कॉल्सच्या स्वरूपात ऑपरेशन्समध्ये प्रवेश करण्यासारखे कोणतेही स्वातंत्र्य नव्हते. एपीआयसह सर्व संप्रेषण विश्रांतीसाठी मानक मोडमध्ये आणले गेले: क्वेरी लाइनमध्ये घटकाचे नाव आहे आणि त्यासह केले जाणारे ऑपरेशन http पद्धत वापरून निर्दिष्ट केले आहे. संस्था कधी अद्यतनित केल्या गेल्या यावर आधारित आम्ही फिल्टरिंग जोडले आहे आणि वापरकर्त्यांना आता त्यांच्या सिस्टमसह प्रतिकृती तयार करण्याची संधी आहे.

त्याच वर्षी, वेअरहाऊस आणि इन्व्हेंटरी बॅलन्स अनलोड करण्यासाठी एपीआय दिसू लागले. सिस्टमचे सर्वात मौल्यवान भाग 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 वर आधारित, आमचे CEO Askar Rakhimberdiev गॅनो चार तासांत मी एक टेलीग्राम बॉट लिहिला जो API द्वारे उरलेला भाग खेचतो: 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