Den första API:n för MojeLager lanserades för 10 Är sedan. Under hela denna tid har vi arbetat med befintliga versioner av API:t och utvecklat nya. Flera versioner av API:t har redan blivit förÄldrade.
I den hÀr artikeln finns det mycket att ta upp: hur vi skapade API:t, varför det behövs för molntjÀnsten, vad det ger anvÀndarna, vilka fallgropar vi har stött pÄ och vad vi vill göra framöver.
Jag heter Oleg Alekseev , jag Àr teknisk chef och medgrundare av MojeLager.
Varför göra ett API för tjÀnsten
VÄra kunder, som bestÄr av tiotusentals entreprenörer, anvÀnder aktivt molnlösningar: banktjÀnster, nÀtbutiker, lagerhantering, CRM. NÀr man ansluter till en tjÀnst Àr det svÄrt att stoppa dÀr. Och nu gör den femte, Ättonde, tionde tjÀnsten arbetet enklare för entreprenören, men data mellan dessa molntjÀnster överförs manuellt av anvÀndarna. Arbetet blir en mardröm.
Den uppenbara lösningen Àr att ge anvÀndarna möjlighet att överföra data mellan molntjÀnster. Till exempel att importera och exportera data som filer, som sedan kan laddas upp till den önskade tjÀnsten. Filerna anpassas vanligtvis till formatet för varje tjÀnst. Detta Àr mer eller mindre enkelt manuellt arbete, men med antalet tjÀnster som vÀxer blir det allt mer komplicerat att utföra.
SÄ nÀsta steg Àr API:t. Med det vinner molntjÀnsten pÄ att koppla ihop flera tjÀnster pÄ en och samma plats. FramvÀxten av ett sÄdant ekosystem attraherar nya kunder tack vare ytterligare möjligheter. En produkt med nya funktioner blir mer lönsam och anvÀndbar.
Om man skapar egna API:er, drar det till sig externa försÀljare som programmerare som kÀnner till din produkt tack vare API:t. De börjar bygga lösningar baserade pÄ API:t och tjÀnar pengar pÄ att automatisera sina kunders uppgifter.
Redovisningssystemet för MojeLager bygger pÄ enkla processer. Det centrala Àr att arbeta med primÀra dokument, möjligheten att hantera mottagning och avskickning av varor, och att fÄ rapporter för verksamheten baserat pÄ dessa dokument. Det finns Àven dataöverföring, till exempel till molnbaserad bokföring, och att fÄ data frÄn banksystem eller detaljhandelspunkter. Dessutom arbetar vi med nÀtbutiker: vi fÄr information om produkter och skickar data om lagret.
Första API:et för MojeSkalad
Under de 10 Är som MojeSkalad har arbetat med API:er har vi byggt upp olika integrationer som lÄter oss utbyta data, arbeta med banker, genomföra betalningar och anvÀnda extern telefoni.
Under det första Äret gjorde vi det möjligt att exportera alla data i XML-format. DÄ var det mycket mer förstÄeligt och bekvÀmt för anvÀndarna att ha data offline istÀllet för i nÄgon typ av moln, och vi gav dem den möjligheten. Exporten initierades genom manuell export frÄn grÀnssnittet. SÄ det gick Ànnu inte att kalla det för ett API.
Samma Ă„r började vi samarbeta med företaget Rusagro â de anvĂ€nde redan en "vuxen" ERP för produktions- och försĂ€ljningsplanering, medan de automatiserade lastningen av vagnar pĂ„ fabrikerna i MojeSkalad. SĂ„ vi fick vĂ„ra första embryo av ett riktigt API: utbytet mellan vĂ„r tjĂ€nst och ERP:n skedde genom att skicka en stor fil med data för alla typer av dokument.
Detta var en bra lösning för batchdatautbyte, men tillsammans med dokumenten var vi tvungna att överföra deras beroenden: information om varor, motparter och lager. En sÄdan samling Àr inte svÄr att generera vid export, men ganska svÄr att bearbeta vid import, eftersom all information kommer i ett paket: bÄde om nya dokument och redan existerande.
Det första XML API:et levde inte lĂ€nge â efter tvĂ„ Ă„r började vi bygga om det. Redan i början av dess drift gjorde vi flera misstag vid utformningen av det programmeringsgrĂ€nssnittet.
SÄ hÀr gjordes XML API:et: en illustration av en av vÄra arkitekter. Förresten, se fram emot hans artiklar.
HÀr Àr vÄra huvudmisstag:
- JAXB-mÀrkningen gjordes direkt pÄ entity beans. För att kommunicera med databasen anvÀnder vi Hibernate, och denna JAXB-mÀrkning gjordes ocksÄ pÄ dessa bönor. Detta misstag uppenbarade sig nÀstan omedelbart: varje uppdatering av databasstrukturen krÀvde ett akut meddelande till alla som anvÀnder API:et, eller att bygga temporÀra lösningar för att sÀkerstÀlla kompatibilitet med den tidigare databasstrukturen.
- API utvecklades som ett slags tillĂ€gg, och vi definierade ursprungligen inte vilken del av produkten det utgjorde. Vi tĂ€nkte inte heller pĂ„ huruvida API:t var nĂ„got viktigt, eller om vi behövde stödja bakĂ„tkompatibilitet för de första kunderna. Under en tid utgjorde antalet API-anvĂ€ndare cirka 5 % av det totala lilla antalet, och vi uppmĂ€rksammade dem inte. Den universella filtrering som gjordes vid den tiden ledde till att vi började anvĂ€ndas som backend. Denna filtrering var inte riktigt GraphQL, men nĂ„got liknande â den fungerade genom en mĂ€ngd parametrar i frĂ„gestrĂ€ngen. Med ett sĂ„ kraftfullt verktyg var det svĂ„rt för anvĂ€ndare att hĂ„lla sig borta, och förfrĂ„gningar började skickas direkt frĂ„n UI:n i deras e-handelsbutiker. Situationen blev en obehaglig överraskning, eftersom tillhandahĂ„llandet av en sĂ„dan tjĂ€nst skulle krĂ€va en annan prissĂ€ttning och överhuvudtaget en annan förstĂ„else av API:t som produkt.
- Eftersom API:t inte utvecklades som en huvudprodukt, producerades och publicerades dokumentationen om API:t som en biprodukt â genom reverse engineering. Denna vĂ€g verkar ganska enkel och bekvĂ€m, men den strider mot kontraktsarbetet. Det handlar om att ha en komponent med en förutbestĂ€md arbetsmodell. Utvecklaren implementerar den enligt denna modell och uppgift, komponenten genomgĂ„r tester, och kunden fĂ„r en produkt som överensstĂ€mmer med analytikerns avsikt. Ă andra sidan slĂ€pper reverse engineering en produkt pĂ„ marknaden som helt enkelt finns: med provisoriska lösningar, konstiga tillvĂ€gagĂ„ngssĂ€tt och hemgjorda lösningar istĂ€llet för den önskade funktionaliteten.
- Hela flödet av förfrÄgningar som kom genom API:t kunde bara analyseras som en logg frÄn Nginx eller applikationsservern. Detta gjorde det omöjligt att sÀrskilja ÀmnesomrÄden, förutom att bryta ner efter anvÀndare och prenumeranter. Om det inte finns möjlighet att reglera registrering av applikationer eller kunder blir det omöjligt att analysera situationen. Detta problem pÄverkade utvecklingen av API:t i minsta mÄn; det handlar mer om att förstÄ dess efterfrÄgan och funktionalitet.
Försök nummer tvÄ: REST API
Ă r 2010 försökte vi bygga ett utbytesystem med online-bokföringen â BukhSoft. Det gick inte vĂ€gen. Men under integrationsprocessen uppstod en fullfjĂ€drad API: en REST-tjĂ€nst för utbyte som inte hade nĂ„gra avvikelser som RPC-anrop. All kommunikation med API:et var förenad med det standardiserade REST-lĂ€get: i förfrĂ„gningsstrĂ€ngen finns entitetens namn och operationen som görs med den anges med hjĂ€lp av HTTP-metoden. Vi la till filtrering baserat pĂ„ senaste uppdatering av entiteter, sĂ„ att anvĂ€ndarna fick möjlighet att bygga replikering med sina system.
Samma Ă„r lanserades API:t för att exportera lager och produktbeholdningar. För anvĂ€ndarna blev de mest vĂ€rdefulla delarna av systemet tillgĂ€ngliga via API:et â utbyte av primĂ€ra dokument och berĂ€kningsdata om lagernivĂ„er och varukostnader.
I december 2015 publicerade RetailCRM det första tredjepartsbiblioteket för Ätkomst till vÄrt API. Det började anvÀndas ganska aktivt, och samtidigt vÀxte tjÀnstens popularitet som helhet, belastningen pÄ API:et ökade snabbare Àn belastningen pÄ webbgrÀnssnittet. En dag förvandlades tillvÀxten till en belastningsspik.
Och denna spik, som visar den vĂ€nstra indikatoren, lĂ€mnade servern som hanterade vĂ„rt API i fullstĂ€ndig förundran. Vi kĂ€mpade i en vecka för att ta reda pĂ„ vilken belastning som egentligen genererade detta. Det visade sig vara de begĂ€rningar som vidarebefordrades till vĂ„rt API frĂ„n kundernas front-end. UngefĂ€r 50 kunder orsakade hela lasten. HĂ€r insĂ„g vi ett av vĂ„ra misstag â den fullstĂ€ndiga avsaknaden av grĂ€nser.
Som ett resultat införde vi en grÀns för antalet samtidiga förfrÄgningar. FrÄn ett konto gick det nu att öppna högst tvÄ förfrÄgningar samtidigt. Detta Àr tillrÀckligt för att arbeta i replikationslÀge för datautbyte i batchlÀge. De som ville anvÀnda oss som backend var nu tvungna att mer anpassa sig till prissÀttningarna, eftersom de började implementera arbete med flera konton i sina programverktyg.
Vi sÀtter i ordning
Redan frÄn 2014 blev efterfrÄgan pÄ det befintliga API:t en viktig del av verksamheten, och sjÀlva API:t genererade den största mÀngden data i datautbytet med kunder. à r 2015 startade vi projektet med att sÀtta API:t i ordning. Vi valde JSON som format istÀllet för XML och började bygga det baserat pÄ de insikter vi fick vid implementeringen av den tidigare versionen:
- Möjlighet att hantera versioner. Versionshantering gör det möjligt att utveckla en ny version utan att pÄverka den befintliga applikationen och utan att störa anvÀndarna.
- Möjlighet för anvÀndaren att se metadata i sjÀlva svaret som han fÄr.
- Möjlighet att byta stora dokument. Om vi hanterar ett dokument med fler Àn 4-5 tusen poster blir det ett problem för servern: lÄng transaktion, lÄng http-förfrÄgan. Vi har byggt en speciell mekanism som gör det möjligt att uppdatera dokumentet i delar och hantera individuella poster i detta dokument genom att skicka dem till servern.
- Verktyg för replikering â fanns Ă€ven i tidigare version.
- BelastningsgrĂ€nser â som ett arv av problemen vi stötte pĂ„ i den tidigare versionen. Vi införde grĂ€nser för antalet förfrĂ„gningar under en viss tidsperiod, antalet parallella förfrĂ„gningar och förfrĂ„gningar frĂ„n en och samma ip-adress.
Sedan dess har vi slÀppt tvÄ mindre versioner av API:et och lanserat flera specialiserade API:er, men övergripande angreppssÀtt har förblivit oförÀndrat. Den uppdaterade utbytesformatet och den nya arkitekturen har möjliggjort att ÄtgÀrda brister i API:et mycket snabbare.
API för MinLager idag
Idag löser API för MinLager mÄnga uppgifter:
- databyten med nÀtbutiker, redovisningssystem, banker;
- hÀmtning av berÀkningsdata, rapporter;
- anvĂ€ndning som backend för klientapplikationer â vĂ„ra mobilapplikationer och skrivbordsregister fungerar via API
- skickande av meddelanden om dataĂ€ndringar i MinLager â webhooks;
- telefoni;
- lojalitetssystem.
Baserat pÄ API:et skrev vÄr VD Askar Rakhimberdiev pÄ fyra timmar en telegram-bot som hÀmtar lager via API:
Nu torra siffror.
HÀr Àr vÄr statistik för det gamla REST API:et:
- 400 företag;
- 600 anvÀndare;
- 2 miljoner förfrÄgningar per dag;
- 200 GB/dag i utgÄende trafik.
Och hÀr Àr vad vi har kommit fram till för alla API:er för MinLager:
- mer Àn 70 integrationer (en del av dem kan du se hÀr );
- 8500 företag;
- 12 000 anvÀndare;
- 46 miljoner förfrÄgningar per dag;
- 2 TB/dag i utgÄende trafik.
Vad hÀnder hÀrnÀst
API-utvecklingsplaner Àr under aktiv diskussion. Vi försöker ta hÀnsyn till den anvÀndarerfarenhet som vÄra anvÀndare delar med oss. Det Àr inte alltid möjligt att Ästadkomma allt pÄ en gÄng, men en ny version av API:et med mer anvÀndarvÀnlig metadata och en mindre komplicerad struktur, samt OAuth för autentisering och API för inbÀddade applikationsgrÀnssnitt, Àr inte lÄngt borta.
HÄll dig uppdaterad om nyheter pÄ den speciella webbplatsen för utvecklare av integrationer med MoimSklad: .
KĂ€lla: habr.com
