Den första API:n av MojeSkklad lanserades för 10 Är sedan. Under hela denna tid har vi arbetat med befintliga versioner av API:t och utvecklat nya. Och flera versioner av API:t har redan hunnit begravas.
I den hÀr artikeln kommer det att finnas mycket: hur API:t skapades, varför det behövs för molntjÀnster, vad det ger anvÀndarna, vilka misstag vi har gjort och vad vi vill göra hÀrnÀst.
Jag heter Oleg Alekseev , jag Àr teknisk direktör och medgrundare av MojeSkklad.
Varför göra API för en tjÀnst
VÄra kunder, som Àr tiotusentals företagare, anvÀnder aktivt molnbaserade lösningar: banktjÀnster, webbshoppar, lagerhantering, CRM. Man kopplar upp sig mot en, och det blir svÄrt att stoppa. Och nu har den femte, Ättonde, tionde tjÀnsten gjort företagarens arbete lÀttare, men anvÀndarna fÄr manuellt flytta data mellan dessa molntjÀnster. Arbetet blir en mardröm.
En uppenbar lösning Àr att ge anvÀndarna möjlighet att överföra data mellan molntjÀnster. Till exempel, importera och exportera data som filer som sedan kan laddas upp i den önskade tjÀnsten. Filer Àndras vanligtvis för att passa varje tjÀnsts format. Det Àr mer eller mindre ett enkelt manuellt arbete, men med ökande antal tjÀnster blir det allt svÄrare att utföra.
DÀrför Àr nÀsta steg API. Med det kan molntjÀnsten dra nytta av att koppla ihop flera tjÀnster pÄ en enda punkt. FramvÀxten av ett sÄdant ekosystem lockar nya kunder genom ytterligare möjligheter. En produkt med ny funktionalitet blir mer fördelaktig och anvÀndbar.
Genom att skapa egna programgrÀnssnitt drar man till sig externa sÀljare i form av programmerare som kÀnner till din produkt tack vare API:t. De börjar bygga lösningar baserat pÄ det erbjudna API:t och tjÀnar pengar pÄ automatisering av sina kunders uppgifter.
Redovisningssystemet MojeSkklad bygger pÄ enkla processer. Huvudfokus Àr arbete med primÀrdokument, möjligheten att ta emot och leverera varor, samt att fÄ rapporter för verksamheten baserat pÄ primÀrdokument. Det finns ocksÄ dataöverföring, till exempel till molnbokföring, och mottagning frÄn banksystem eller detaljhandelsstÀllen. Vi arbetar Àven med webbshoppar: fÄr information om produkter och skickar data om lagersaldon.
Första API:t för MojeSkalf
Under 10 Ärs arbete med API:t för MojeSkalf har vi samlat pÄ oss olika integrationer som möjliggör datadelning, samarbete med banker, betalningar och anvÀndning av extern telefoni.
Under det första Äret gjorde vi det möjligt att exportera vilken data som helst i XML-format. DÄ var det mycket tydligare och mer bekvÀmt för anvÀndare att hantera data offline snarare Àn i nÄgon molnlösning, och vi gav dem den möjligheten. Exporten startades via manuell export frÄn grÀnssnittet. SÄ API kunde man Ànnu inte kalla det.
Samtidigt började vi samarbeta med företaget Rusagro â de hade redan en 'vuxen' ERP för att planera produktion och försĂ€ljning, men de automatiserade lastning av vagnar pĂ„ fabriker i MojeSkalf. SĂ„ vi fick vĂ„ra första grunderar till ett riktigt API: utbytet mellan vĂ„r tjĂ€nst och ERP skedde genom att skicka en stor fil med data om alla typer av dokument.
Detta Àr ett bra alternativ för batchdatautbyte, men tillsammans med dokumenten var man tvungen att överföra deras beroenden: information om varor, motparter och lager. SÄdan en samling Àr inte svÄr att generera vid export, men ganska svÄr att hantera vid import, eftersom all information kommer i ett paket: bÄde om nya dokument och om redan existerande.
Det första XML API:t överlevde inte lĂ€nge â efter tvĂ„ Ă„r började vi bygga om det. Redan vid starten av dess arbete gjorde vi flera misstag i uppbyggnaden av det programmerbara grĂ€nssnittet.
SÄ hÀr gjordes XML API:t: en illustration frÄn en av vÄra arkitekter. Förresten, hÄll utkik efter hans artiklar.
HÀr Àr vÄra största misstag:
- JAXB-mÀrkningen gjordes direkt pÄ entity beans. För kommunikation med databasen anvÀnder vi Hibernate, och JAXB-mÀrkningen byggdes ocksÄ pÄ dessa bönor. Detta misstag visade sig nÀstan omedelbart: varje Àndring av databasstrukturen krÀvde en snabb avisering till alla som anvÀnder API:t eller skapandet av nödlösningar för att sÀkerstÀlla kompatibilitet med den tidigare databasstrukturen.
- API vĂ€xte fram som en sorts tillĂ€gg, och i början definierade vi inte vilken del av produkten det utgjorde. Vi tĂ€nkte inte heller pĂ„ huruvida API:et var nĂ„got viktigt, om vi behövde upprĂ€tthĂ„lla bakĂ„tkompatibilitet för de första anvĂ€ndarna. Under en tid utgjorde API-anvĂ€ndarna cirka 5% av det totala lilla antalet, och de fick ingen uppmĂ€rksamhet. Den universella filtrering som skapades vid den tiden ledde till att vi började anvĂ€ndas som backend. Denna filtrering var inte riktigt GraphQL, men liknande â fungerade via en massa parameterstrĂ€ngar. Med ett sĂ„ kraftfullt verktyg var det svĂ„rt för anvĂ€ndarna att motstĂ„, och förfrĂ„gningar skickades direkt frĂ„n deras webbutikers anvĂ€ndargrĂ€nssnitt. Situationen blev en obehaglig överraskning, eftersom tillhandahĂ„llandet av en sĂ„dan tjĂ€nst borde krĂ€va en annan prissĂ€ttning och en helt annan förstĂ„else för API:et som produkt.
- Eftersom API:et utvecklades inte som en huvudprodukt, producerades och publicerades API-dokumentationen som en biprodukt â genom omvĂ€nd ingenjörskonst. Denna vĂ€g verkar ganska enkel och bekvĂ€m, men strider mot avtalsarbete. Det handlar om att det finns en viss komponent med en förinstĂ€lld arbetsmodell. Utvecklaren implementerar den enligt denna modell och uppgift, komponenten testas, kunden fĂ„r en produkt som överensstĂ€mmer med analytikerns vision. OmvĂ€nd ingenjörskonst slĂ€nger dock ut en produkt pĂ„ marknaden som bara finns dĂ€r: med provisoriska lösningar, konstiga beslut och cyklar istĂ€llet för den nödvĂ€ndiga funktionaliteten.
- Hela strömmen av förfrÄgningar som kom genom API:et kunde analyseras högst som en Nginx-logg eller applikationsserver-logg. Detta gjorde det omöjligt att sÀrskilja ÀmnesomrÄden, annat Àn att dela upp dem efter anvÀndare och prenumeranter. Om det inte finns möjlighet att reglera registreringen av applikationer eller kunder blir det omöjligt att analysera situationen. Detta problem pÄverkade minst av allt API:s utveckling, 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 system för utbyte med online-bokföring â BuchSoft. Det lyfte inte. Men under integrationsprocessen skapades en fullt fungerande API: en REST-tjĂ€nst för utbyte, dĂ€r det inte fanns nĂ„gra skönsmĂ€ssiga tillvĂ€gagĂ„ngssĂ€tt som att anropa operationer i form av RPC-anrop. All kommunikation med API:et var anpassad till standard lĂ€ge för REST: i förfrĂ„gningsstrĂ€ngen finns namnet pĂ„ entiteten, och operationen som utförs pĂ„ den anges med hjĂ€lp av HTTP-metoden. Vi lade till filtrering baserat pĂ„ uppdateringsögonblicket för entiteter, vilket gav anvĂ€ndarna möjlighet att bygga replikering med sina system.
Samma Ă„r kom API:et för export av lager- och produktbeholdningar. Genom API:et blev de mest vĂ€rdefulla delarna av systemet tillgĂ€ngliga för anvĂ€ndarna â utbyte av primĂ€ra dokument och berĂ€kningsdata om lager och kostnader för produkter.
I december 2015 publicerade RetailCRM det första tredjepartsbiblioteket för Ätkomst till vÄrt API. Det började anvÀndas ganska aktivt, samtidigt vÀxte populariteten för tjÀnsten som helhet, och belastningen pÄ API:et ökade snabbare Àn belastningen pÄ webgrÀnssnittet. En dag förvandlades tillvÀxten till en belastningsspik.
Och denna spik, som pekaren till vĂ€nster visar, orsakade fullstĂ€ndig hĂ€pnad hos servern som betjĂ€nade vĂ„rt API. En vecka Ă€gnade vi Ă„t att ta reda pĂ„ vad som egentligen orsakade denna belastning. Det visade sig att det var just de förfrĂ„gningar som förmedlades till vĂ„rt API frĂ„n kunder. Cirka 50 kunder stod för allt. Vid denna punkt insĂ„g vi en 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 blev det möjligt att ha högst tvÄ öppna förfrÄgningar samtidigt. Detta Àr tillrÀckligt för att arbeta i replikationslÀge för utbyte av data i batchlÀge. Och de som ville anvÀnda oss som backend blev frÄn detta ögonblick tvungna att bÀttre anpassa sig till prissÀttningarna, eftersom de införde arbete med flera konton i sina programvaror.
Vi ordnar upp
Redan frÄn 2014 blev efterfrÄgan pÄ det befintliga API:et en viktig del av verksamheten, och API:et genererade den största volymen data vid utbyte av information med kunder. à r 2015 startade vi projektet för att ordna upp API:et. Vi valde JSON istÀllet för XML som format och började bygga det baserat pÄ de egenskaper som vi identifierade vid genomförandet 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Àndarnas arbete.
- Möjlighet för anvÀndaren att se metadata i sjÀlva svaret de fÄr.
- Möjlighet att dela stora dokument. Om vi hanterar 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 möjliggör att uppdatera dokumenten i delar och hantera individuella poster av dokumentet genom att skicka dem till servern.
- Verktyg för replikering â fanns ocksĂ„ i den tidigare versionen.
- BelastningsgrĂ€nser â som ett arv frĂ„n de problem vi stötte pĂ„ i den tidigare versionen. Vi införde grĂ€nser för antal förfrĂ„gningar under en tidsperiod, antal 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 överlag har tillvÀgagÄngssÀttet förblivit oförÀndrat. Den uppdaterade dataformatet och den nya arkitekturen har gjort att vi kan ÄtgÀrda bristerna i API:et betydligt snabbare.
API för MoŃgSklad idag
Idag löser API för MoŃgSklad mĂ„nga uppgifter:
- datautbyte med nÀtbutiker, redovisningssystem, banker;
- hÀmtning av berÀkningsdata, rapporter;
- anvĂ€ndning som backend för klientapplikationer â vĂ„ra mobilapplikationer och skrivbordskassa fungerar via API
- skicka meddelanden om dat förĂ€ndringar i MoŃgSklad â webhooks;
- telefoni;
- lojalitetssystem.
Baserat pÄ API skrev vÄr VD Askar Rakhimberdiev pÄ fyra timmar en telegram-bot som hÀmtar lagersaldon genom API:
Nu till 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 utgÄende trafik.
Och hĂ€r Ă€r vad vi har kommit fram till med alla API:er för MoŃgSklad:
- mer Àn 70 integrationer (en del av dem kan ses hÀr );
- 8500 företag;
- 12 000 anvÀndare;
- 46 miljoner förfrÄgningar per dag;
- 2 TB/dag utgÄende trafik.
Vad hÀnder hÀrnÀst
API-utvecklingsplaner Àr under aktiv diskussion. Vi försöker ta hÀnsyn till anvÀndarens erfarenheter. Det Àr inte alltid möjligt att göra allt pÄ en gÄng, men en ny version av API:et med mer anvÀndarvÀnliga metadata och en mindre rörig struktur, samt OAuth för autentisering, Àr pÄ vÀg, liksom API för inbÀddade applikationsgrÀnssnitt.
Du kan följa nyheterna pÄ en sÀrskild webbplats för utvecklare som integrerar med MittLager: .
KĂ€lla: habr.com
