API i parë MySklad u shfaq 10 vjet më parë. Gjatë gjithë kësaj kohe ne kemi punuar në versionet ekzistuese të API dhe kemi zhvilluar të reja. Dhe disa versione të API tashmë janë varrosur.
Ky artikull do të përmbajë shumë gjëra: si u krijua API, pse i nevojitet shërbimit cloud, çfarë u jep përdoruesve, çfarë gabimesh arritëm të shkelim dhe çfarë duam të bëjmë më pas.
Emri im është Oleg Alekseev , Unë jam drejtor teknik dhe bashkëthemelues i MySklad.
Pse të bëni një API për një shërbim
Klientët tanë, të cilët janë dhjetëra mijëra sipërmarrës, përdorin në mënyrë aktive zgjidhjet e cloud: banka, dyqane online, kontabilitet mallrash, CRM. Pasi të lidheni me një, është e vështirë të ndalosh. Dhe tani shërbimi i pestë, i teti, i dhjetë e bën punën e sipërmarrësit më të lehtë, por përdoruesit transferojnë manualisht të dhënat midis këtyre shërbimeve cloud. Puna kthehet në një makth.
Zgjidhja e dukshme është t'u japë përdoruesve mundësinë për të transferuar të dhëna midis shërbimeve cloud. Për shembull, importoni dhe eksportoni të dhëna si skedarë, të cilët më pas mund të ngarkohen në shërbimin e dëshiruar. Skedarët zakonisht ndryshohen për t'iu përshtatur formatit të secilit shërbim. Kjo është pak a shumë punë e thjeshtë manuale, por me rritjen e numrit të këtyre shërbimeve bëhet gjithnjë e më e vështirë për t'u kryer.
Prandaj, hapi tjetër është API. Me të, shërbimi cloud përfiton nga fakti që lidh disa shërbime në një pikë. Shfaqja e një ekosistemi të tillë tërheq klientë të rinj për shkak të mundësive shtesë. Një produkt me funksionalitet të ri bëhet më fitimprurës dhe i dobishëm.
Nëse krijoni ndërfaqet tuaja të programimit, kjo tërheq shitësit e palëve të treta në formën e programuesve që dinë për produktin tuaj falë API-së. Ata fillojnë të ndërtojnë zgjidhje bazuar në API-në e propozuar dhe fitojnë para duke automatizuar detyrat e klientëve të tyre.
Sistemi i kontabilitetit MySklad bazohet në procese të thjeshta. Gjëja kryesore është të punosh me dokumente parësore, aftësinë për të pranuar dhe dërguar mallra dhe për të marrë raporte biznesi bazuar në dokumentet parësore. Ekziston edhe transferimi i të dhënave, për shembull në kontabilitetin cloud, dhe marrja e tyre nga sistemet bankare ose pikat e shitjes me pakicë. Ne gjithashtu punojmë me dyqane online: marrim informacione për produktet dhe dërgojmë informacione për bilancet.
API-ja e parë e MySklad
Gjatë 10 viteve të punës së MySklad me API, ne kemi marrë të gjitha llojet e integrimeve që na lejojnë të shkëmbejmë të dhëna, të punojmë me bankat, të bëjmë pagesa dhe të përdorim telefoninë e jashtme.
Në vitin e parë, ne bëmë të mundur shkarkimin e të dhënave në formatin XML. Në atë kohë, ishte shumë më e qartë dhe më e zakonshme për përdoruesit që t'i mbanin të dhënat jashtë linje, sesa në ndonjë cloud, dhe ne ua dhamë atyre. Ngarkimi filloi me eksportim manual nga ndërfaqja. Kjo do të thotë, nuk mund të quhej ende një API.
Në të njëjtën kohë, ne filluam të bashkëpunojmë me kompaninë Rusagro - ata tashmë po përdornin një ERP "të rritur" për planifikimin e prodhimit dhe shitjeve, por ata automatizuan ngarkimin e makinave në fabrikat në MySklad. Kështu morëm bazat e para të një API të vërtetë: shkëmbimi midis shërbimit tonë dhe ERP u bë duke dërguar një skedar të madh me të dhëna për të gjitha llojet e dokumenteve.
Ky është një opsion i mirë për shkëmbimin e të dhënave të grupeve, por së bashku me dokumentet na është dashur të transferojmë varësitë e tyre: informacione për mallrat, kontraktorët dhe magazinat. Një hale e tillë nuk është aq e vështirë të krijohet kur eksportohet, por është mjaft e vështirë të analizohet kur importohet, pasi të gjitha informacionet vijnë në një paketë: si për dokumentet e reja ashtu edhe për ato ekzistuese.
API i parë XML nuk jetoi shumë - dy vjet më vonë filluam ta rindërtonim atë. Edhe në fillim të punës së tij, ne bëmë disa gabime gjatë ndërtimit të ndërfaqes së softuerit.
Si u krijua XML API: ilustrim nga një prej arkitektëve tanë. Meqë ra fjala, qëndroni të sintonizuar për artikujt e tij.
Këtu janë gabimet tona kryesore:
- Shënimi JAXB u bë direkt në fasulet e entitetit. Ne përdorim Hibernate për të komunikuar me bazën e të dhënave, dhe shënjimi JAXB është bërë për të njëjtat fasule. Ky gabim u shfaq pothuajse menjëherë: çdo përditësim i strukturës së të dhënave çoi në nevojën për të njoftuar urgjentisht të gjithë ata që përdorin API, ose për të ndërtuar paterica që do të siguronin përputhshmëri me strukturën e mëparshme të të dhënave.
- API u rrit si një shtesë dhe ne fillimisht nuk e përcaktuam se cila pjesë e produktit ishte. Ata as nuk menduan nëse API ishte diçka e rëndësishme, nëse ishte e nevojshme të ruhej përputhshmëria e prapambetur për klientët e saj të parë. Në një moment, numri i përdoruesve të API ishte rreth 5% e numrit të vogël dhe nuk iu kushtua vëmendje. Filtrimi universal i bërë në një kohë bëri që ne të përdorim si një prapavijë. Ky filtrim nuk ishte aspak GraphQL, por diçka e tillë - funksionoi përmes shumë parametrave të vargut të pyetjeve. Me një mjet kaq të fuqishëm, ishte e vështirë për përdoruesit të rezistonin dhe kërkesat u transferuan tek ne në mënyrë që ato të dërgoheshin direkt nga UI-ja e dyqaneve të tyre online. Situata ishte një surprizë e pakëndshme, sepse ofrimi i një shërbimi të tillë duhet të kërkojë çmime të ndryshme dhe një kuptim përgjithësisht të ndryshëm të vetë API-së si produkt.
- Për shkak të faktit se API nuk u zhvillua si një produkt kryesor, dokumentacioni API u prodhua dhe u publikua në bazë të mbetur - përmes inxhinierisë së kundërt. Kjo rrugë duket mjaft e thjeshtë dhe e përshtatshme, por bie ndesh me punën me kontratë. Kjo është kur ekziston një komponent i caktuar me një skemë funksionimi të paracaktuar. Zhvilluesi e zbaton atë në përputhje me këtë skemë dhe detyrë, komponenti testohet dhe klienti merr një produkt që përputhet me idenë e analistit. Inxhinieria e kundërt hedh në treg një produkt që ekziston thjesht: me paterica, zgjidhje të çuditshme dhe biçikleta në vend të funksionalitetit të nevojshëm.
- E gjithë rrjedha e kërkesave që erdhën përmes API mund të analizohej si asgjë më shumë se një Nginx ose regjistër i serverit të aplikacionit. Kjo nuk na lejoi të identifikonim fushat e temave, përveç ndoshta nga përdoruesit dhe abonentët. Nëse nuk ka asnjë mënyrë për të rregulluar aplikimin ose regjistrimin e klientit, bëhet e pamundur të analizohet situata. Ky problem pati ndikimin më të vogël në zhvillimin e API-së; ka të bëjë më shumë me të kuptuarit e rëndësisë dhe funksionalitetit të tij.
Përpjekja numër dy: REST API
Në vitin 2010, ne u përpoqëm të ndërtonim një sistem shkëmbimi me kontabilitet online - BukhSoft. Nuk u ngrit. Por gjatë procesit të integrimit, u shfaq një API e plotë: një shërbim shkëmbimi REST, ku nuk kishte liri të tilla si qasja në operacione në formën e thirrjeve RPC. I gjithë komunikimi me API u soll në modalitetin standard për pushim: linja e pyetjes përmban emrin e entitetit dhe operacioni që kryhet me të specifikohet duke përdorur metodën http. Ne shtuam filtrimin bazuar në kohën kur entitetet u përditësuan dhe përdoruesit tani kanë mundësinë të ndërtojnë përsëritje me sistemet e tyre.
Në të njëjtin vit, u shfaq një API për shkarkimin e bilanceve të magazinës dhe inventarit. Pjesët më të vlefshme të sistemit janë bërë të disponueshme për përdoruesit përmes API - shkëmbimi i dokumenteve parësore dhe të dhënat e llogaritura për bilancet dhe koston e mallrave.
Në dhjetor 2015, RetailCRM publikoi bibliotekën e parë të palëve të treta për të hyrë në API-në tonë. Filloi të përdoret mjaft aktivisht, ndërsa popullariteti i shërbimit në tërësi u rrit, ngarkesa në API u rrit më shpejt sesa ngarkesa në ndërfaqen në internet. Një ditë rritja u shndërrua në rritje të ngarkesës.
Dhe ky kërcim, i treguar nga shigjeta në të majtë, mahniti plotësisht serverin që shërben API-në tonë. Kaluam një javë duke kuptuar se çfarë saktësisht po e krijonte këtë ngarkesë. Doli se këto janë të njëjtat kërkesa të transmetuara në API-në tonë nga frontet e klientëve. Rreth 50 klientë hëngrën gjithçka. Ishte atëherë që ne kuptuam një nga gabimet tona - mungesën e plotë të kufijve.
Si rezultat, ne vendosëm një kufi në numrin e kërkesave të njëkohshme. Tani është e mundur të hapen jo më shumë se dy kërkesa njëkohësisht nga një llogari. Kjo është e mjaftueshme për të punuar në modalitetin e riprodhimit për shkëmbimin e të dhënave në modalitetin batch. Dhe ata që donin të na përdornin si backend, që nga ai moment, u detyruan të respektonin më mirë tarifat, pasi futën punën në disa llogari në softuerin e tyre.
Le ta vendosim në rregull
Tashmë që nga viti 2014, kërkesa për API ekzistuese është bërë një pjesë e rëndësishme e biznesit dhe vetë API gjeneron vëllimin më të madh të të dhënave në shkëmbimin e të dhënave me klientët. Në vitin 2015, ne filluam një projekt për të pastruar API-në. Ne zgjodhëm JSON në vend të XML si format dhe filluam ta ndërtojmë atë bazuar në veçoritë që u identifikuan gjatë zbatimit të versionit të mëparshëm:
- Aftësia për të menaxhuar versionet. Versionimi ju lejon të zhvilloni një version të ri pa ndikuar në aplikacionin ekzistues ose pa ndërprerë përvojën e përdoruesit.
- Mundësia që përdoruesi të shohë meta të dhënat në vetë përgjigjen që ai merr.
- Aftësia për të shkëmbyer dokumente të mëdha. Nëse përpunojmë një dokument me më shumë se 4-5 mijë pozicione, kjo bëhet problem për serverin: një transaksion i gjatë, një kërkesë e gjatë http. Ne ndërtuam një mekanizëm të veçantë që ju lejon të përditësoni një dokument në pjesë dhe të menaxhoni pozicionet individuale të këtij dokumenti duke i dërguar ato në server.
- Mjetet për përsëritje ishin gjithashtu të pranishme në versionin e mëparshëm.
- Kufijtë e ngarkesës janë si një trashëgimi e raketës që është shkelur në versionin e mëparshëm. Ne vendosëm kufizime në numrin e kërkesave në një periudhë kohore, numrin e kërkesave paralele dhe kërkesave nga një adresë IP.
Që atëherë, ne kemi lëshuar dy versione të vogla të API-së dhe kemi lançuar disa API të specializuara, por qasja e përgjithshme ka mbetur e pandryshuar. Formati i përditësuar i shkëmbimit dhe arkitektura e re bënë të mundur korrigjimin e gabimeve në API shumë më shpejt.
MySklad API sot
Sot, MySklad API zgjidh shumë probleme:
- shkëmbimi i të dhënave me dyqanet online, sistemet e kontabilitetit, bankat;
- marrjen e të dhënave dhe raporteve të llogaritura;
- përdorni si një backend për aplikacionet e klientëve - aplikacionet tona celulare dhe arka në desktop funksionojnë përmes API
- dërgimi i njoftimeve për ndryshimet e të dhënave në MySklad - webhooks;
- telefonia;
- sistemet e besnikërisë.
Bazuar në API, CEO ynë Askar Rakhimberdiev në katër orë shkrova një bot telegram që tërheq mbetjet përmes API-së:
Tani thajini numrat.
Këtu janë statistikat tona për API-në e vjetër REST:
- 400 kompani;
- 600 përdorues;
- 2 milionë kërkesa në ditë;
- 200 GB/ditë trafik në dalje.
Dhe ja çfarë kemi arritur për të gjitha API-të e MySklad:
- më shumë se 70 integrime (disa prej tyre mund të shihen këtu );
- 8500 kompani;
- 12 përdorues;
- 46 milionë kërkesa në ditë;
- 2 TB/ditë trafik në dalje.
Ç'pritet më tej
Planet e zhvillimit të API janë në diskutim aktiv. Ne përpiqemi të marrim parasysh përvojën e funksionimit që na ofrojnë përdoruesit. Nuk është gjithmonë e mundur të bësh gjithçka menjëherë, por një version i ri i API-së është gati afër me meta të dhëna më të përshtatshme dhe një strukturë më pak të butë, OAuth për vërtetimin dhe një API për aplikacionet e integruara në ndërfaqe.
Ju mund të ndiqni lajmet në një faqe interneti të veçantë për zhvilluesit e integrimeve me MySklad: .
Burimi: www.habr.com