Esimene MySklad API ilmus 10 aastat tagasi. Kogu selle aja oleme töötanud API olemasolevate versioonide kallal ja arendanud uusi. Ja API mitu versiooni on juba maha maetud.
See artikkel sisaldab palju asju: kuidas API loodi, miks pilveteenus seda vajab, mida see kasutajatele annab, millistele vigadele õnnestus astuda ja mida edasi teha.
Minu nimi on Oleg Aleksejev , olen MySkladi tehniline direktor ja kaasasutaja.
Miks teha teenusele API
Meie kliendid, kellest on kümneid tuhandeid ettevõtjaid, kasutavad aktiivselt pilvelahendusi: pangandus, veebipoed, kaubaarvestus, CRM. Kui olete ühega ühenduse loonud, on seda raske peatada. Ja nüüd teeb ettevõtja töö lihtsamaks viies, kaheksas, kümnes teenus, kuid kasutajad edastavad andmeid nende pilveteenuste vahel käsitsi. Töö muutub õudusunenäoks.
Ilmselge lahendus on anda kasutajatele võimalus pilveteenuste vahel andmeid edastada. Näiteks importige ja eksportige andmeid failidena, mida saab seejärel soovitud teenusesse üles laadida. Faile muudetakse tavaliselt vastavalt iga teenuse vormingule. See on enam-vähem lihtne käsitsitöö, kuid nende teenuste arvu suurenedes muutub selle teostamine üha keerulisemaks.
Seetõttu on järgmine samm API. Sellega saab pilveteenus kasu sellest, et see ühendab mitu teenust ühel hetkel. Sellise ökosüsteemi tekkimine meelitab uusi kliente tänu lisavõimalustele. Uue funktsionaalsusega toode muutub tulusamaks ja kasulikumaks.
Kui loote oma programmeerimisliidesed, meelitab see ligi kolmandate osapoolte müügiinimesi programmeerijate näol, kes teavad teie tootest tänu API-le. Nad hakkavad kavandatud API-l põhinevaid lahendusi looma ja teenivad raha, automatiseerides oma klientide ülesandeid.
Raamatupidamissüsteem MySklad põhineb lihtsatel protsessidel. Peamine on töö esmaste dokumentidega, kaupade vastuvõtmise ja saatmise võimalus ning äriaruannete vastuvõtmine esmaste dokumentide alusel. Samuti on andmete edastamine, näiteks pilvearvestusse, ja nende vastuvõtmine pangasüsteemidest või jaemüügipunktidest. Teeme koostööd ka veebipoodidega: saame infot toodete kohta ja saadame infot saldode kohta.
MySkladi esimene API
MySklad API-ga töötamise 10 aasta jooksul oleme omandanud kõikvõimalikke integratsioone, mis võimaldavad meil vahetada andmeid, töötada pankadega, teha makseid ja kasutada välist telefonikõnet.
Esimesel aastal võimaldasime mis tahes andmeid alla laadida XML-vormingus. Siis oli kasutajatel palju selgem ja tavalisem hoida andmeid võrguühenduseta, mitte mõnes pilves, ja me andsime selle neile. Üleslaadimist alustati liidesest käsitsi eksportimisega. See tähendab, et seda ei saanud veel API-ks nimetada.
Samal ajal hakkasime tegema koostööd ettevõttega Rusagro - nad kasutasid tootmise ja müügi planeerimiseks juba “täiskasvanute” ERP-d, kuid nad automatiseerisid MySkladi tehastes autode laadimise. Nii saime esimesed tõelise API alged: vahetus meie teenuse ja ERP vahel toimus, saates suure faili igat tüüpi dokumentide andmetega.
See on hea võimalus partiiandmete vahetamiseks, kuid koos dokumentidega tuli üle kanda ka nende sõltuvused: teave kaupade, töövõtjate ja ladude kohta. Sellist prügimäge pole eksportimisel nii keeruline luua, kuid importimisel on seda üsna keeruline sõeluda, kuna kogu teave on ühes paketis: nii uute kui ka olemasolevate dokumentide kohta.
Esimene XML API ei elanud kaua – kaks aastat hiljem hakkasime seda uuesti üles ehitama. Isegi selle töö alguses tegime tarkvaraliidese loomisel mitmeid vigu.
Kuidas XML API tehti: illustratsioon ühelt meie arhitektilt. Muide, jääge tema artiklitega kursis.
Siin on meie peamised vead:
- JAXB märgistus tehti otse olemi ubadel. Kasutame andmebaasiga suhtlemiseks Hibernate'i ja samade ubade jaoks tehti JAXB märgistus. See viga ilmnes peaaegu kohe: igasugune andmestruktuuri värskendus tõi kaasa vajaduse kiiremas korras teavitada kõiki, kes API-d kasutavad, või ehitada kargud, mis tagaksid ühilduvuse eelmise andmestruktuuriga.
- API kasvas lisandmoodulina ja me ei määratlenud esialgu, mis toote osa see on. Nad isegi ei mõelnud sellele, kas API on midagi olulist, kas on vaja säilitada selle esimeste klientide tagasiühilduvus. Ühel hetkel oli API kasutajate arv umbes 5% väikesest arvust ja neile ei pööratud tähelepanu. Korraga tehtud universaalne filtreerimine viis selleni, et meid kasutati taustaprogrammina. See filtreerimine ei olnud üldse GraphQL, vaid midagi taolist - see töötas läbi palju päringustringi parameetreid. Sellise võimsa tööriistaga oli kasutajatel raske vastu seista ning päringud edastati meile nii, et need saadeti otse nende veebipoodide kasutajaliidestest. Olukord oli ebameeldiv üllatus, sest sellise teenuse osutamine peaks eeldama teistsugust hinnakujundust ja üldiselt erinevat arusaama API-st endast kui tootest.
- Kuna API-d ei arendatud põhitootena, koostati ja avaldati API dokumentatsioon jääkpõhiselt – pöördprojekteerimise teel. See tee tundub üsna lihtne ja mugav, kuid see on vastuolus lepingu alusel töötamisega. See on siis, kui on olemas teatud komponent, millel on eelseadistatud tööskeem. Arendaja rakendab seda vastavalt sellele skeemile ja ülesandele, komponenti testitakse ja klient saab toote, mis vastab analüütiku ideele. Pöördprojekteerimine paiskab turule toote, mis lihtsalt eksisteerib: vajaliku funktsionaalsuse asemel karkude, kummaliste lahenduste ja jalgratastega.
- Kogu API kaudu saabunud päringute voogu saab analüüsida vaid Nginxi või rakendusserveri logina. See ei võimaldanud meil teemavaldkondi tuvastada, välja arvatud võib-olla kasutajate ja tellijate poolt. Kui avaldust või kliendi registreerimist ei ole võimalik reguleerida, muutub olukorra analüüsimine võimatuks. See probleem mõjutas API arendamist kõige vähem; see on rohkem seotud selle asjakohasuse ja funktsionaalsuse mõistmisega.
Katse number kaks: REST API
2010. aastal proovisime üles ehitada veebipõhise raamatupidamisega vahetussüsteemi – BukhSoft. Ei tõusnud õhku. Kuid integreerimisprotsessi käigus ilmus täisväärtuslik API: REST-vahetusteenus, kus puudusid sellised vabadused nagu juurdepääs toimingutele RPC-kõnede kujul. Kogu suhtlus API-ga viidi puhkamiseks standardrežiimi: päringureal on olemi nimi ja sellega tehtav toiming määratakse http-meetodi abil. Lisasime olemite värskendamise aja järgi filtreerimise ja kasutajatel on nüüd võimalus luua oma süsteemidega replikatsioon.
Samal aastal ilmus lao- ja laojääkide mahalaadimise API. Kasutajatele on API kaudu kättesaadavaks saanud süsteemi väärtuslikumad osad – esmaste dokumentide ning arvestuslike andmete vahetamine saldode ja kauba maksumuse kohta.
2015. aasta detsembris avaldas RetailCRM esimese kolmanda osapoole teegi, mis võimaldab juurdepääsu meie API-le. Seda hakati üsna aktiivselt kasutama, samal ajal kui teenuse populaarsus tervikuna kasvas, kasvas API koormus kiiremini kui veebiliidese koormus. Ühel päeval muutus kasv koormuse tõusuks.
Ja see vasakpoolse noolega näidatud hüpe hämmastas meie API-d teenindavat serverit täielikult. Veetsime nädala, et välja mõelda, mis täpselt selle koormuse tekitas. Selgus, et need on samad päringud, mis edastati meie API-le kliendirindelt. Umbes 50 klienti sõid kõike. Just siis saime aru ühest oma veast – täielikust piiride puudumisest.
Selle tulemusena kehtestasime samaaegsete päringute arvu piirangu. Nüüd on võimalik ühelt kontolt korraga avada mitte rohkem kui kaks päringut. Sellest piisab replikatsioonirežiimis töötamiseks pakettrežiimis andmevahetuseks. Ja need, kes soovisid meid taustaprogrammina kasutada, olid sellest hetkest sunnitud tariife paremini järgima, kuna nad lisasid oma tarkvarasse töö mitmel kontol.
Paneme selle korda
Juba 2014. aastast on nõudlus olemasoleva API järele muutunud äri oluliseks osaks ning API ise genereerib klientidega andmevahetuses kõige suurema andmemahu. 2015. aastal käivitasime API puhastamise projekti. Valisime vorminguks XML-i asemel JSON-i ja hakkasime seda ehitama funktsioonide põhjal, mis tuvastati eelmise versiooni juurutamisel:
- Võimalus hallata versioone. Versioonide loomine võimaldab teil töötada välja uue versiooni, ilma et see mõjutaks olemasolevat rakendust või häiriks kasutajakogemust.
- Kasutaja võimalus näha saadud vastuses endas metaandmeid.
- Võimalus vahetada suuri dokumente. Kui töötleme dokumenti, millel on rohkem kui 4-5 tuhat positsiooni, muutub see serveri jaoks probleemiks: pikk tehing, pikk http-päring. Ehitasime spetsiaalse mehhanismi, mis võimaldab värskendada dokumenti osade kaupa ja hallata selle dokumendi üksikuid positsioone, saates need serverisse.
- Replikatsiooni tööriistad olid olemas ka eelmises versioonis.
- Koormuspiirangud on nagu reha pärand, millele astus eelmises versioonis. Võtsime kasutusele piirangud päringute arvule ajavahemikul, paralleelsete päringute arvule ja ühelt IP-aadressilt pärinevatele päringutele.
Sellest ajast alates oleme välja andnud API kaks väiksemat versiooni ja käivitanud mitu spetsiaalset API-d, kuid üldine lähenemisviis on jäänud muutumatuks. Värskendatud vahetusvorming ja uus arhitektuur võimaldasid API vigu palju kiiremini parandada.
MySklad API täna
Tänapäeval lahendab MySklad API palju probleeme:
- andmevahetus veebipoodide, raamatupidamissüsteemide, pankadega;
- arvestuslike andmete ja aruannete saamine;
- kasutada kliendirakenduste taustaprogrammina – meie mobiilirakendused ja lauakassa töötavad API kaudu
- teadete saatmine andmete muutumise kohta MySkladis - veebihaagid;
- telefoniside;
- lojaalsussüsteemid.
API-l põhinev meie tegevjuht Askar Rakhimberdiev nelja tunniga kirjutasin telegrammi roboti, mis tõmbab ülejäägid API kaudu:
Nüüd kuivad numbrid.
Siin on meie statistika vana REST API kohta:
- 400 ettevõtet;
- 600 kasutajat;
- 2 miljonit taotlust päevas;
- 200 GB päevas väljuvat liiklust.
Ja siin on see, mida me kõigi MySkladi API-de jaoks välja mõtlesime:
- rohkem kui 70 integratsiooni (mõnda neist saab vaadata siit );
- 8500 ettevõtet;
- 12 000 kasutajat;
- 46 miljonit taotlust päevas;
- 2 TB/päevas väljuvat liiklust.
mis edasi
API arendusplaanid on aktiivse arutelu all. Püüame arvestada kasutuskogemusega, mida kasutajad meile pakuvad. Alati ei ole võimalik kõike korraga teha, kuid API uus versioon on kohe käes, mugavamate metaandmete ja vähem koheva struktuuriga, autentimiseks mõeldud OAuth ja liidesesse sisseehitatud rakenduste API.
Uudiseid saate jälgida spetsiaalsel veebisaidil, mis on mõeldud MySkladiga integreerimise arendajatele: .
Allikas: www.habr.com