Det första MySklad API dök upp för 10 år sedan. Hela den här tiden har vi arbetat med befintliga versioner av API:t och utvecklat nya. Och flera versioner av API har redan begravts.
Den här artikeln kommer att innehålla en massa saker: hur API skapades, varför molntjänsten behöver det, vad det ger till användarna, vilka misstag vi lyckades kliva på och vad vi vill göra härnäst.
Mitt namn är Oleg Alekseev , Jag är teknisk chef och medgrundare av MySklad.
Varför skapa ett API för en tjänst
Våra kunder, som är tiotusentals entreprenörer, använder aktivt molnlösningar: bank, nätbutiker, råvaruredovisning, CRM. När du väl har anslutit till en är det svårt att sluta. Och nu gör den femte, åttonde, tionde tjänsten entreprenörens arbete enklare, men användare överför data mellan dessa molntjänster manuellt. Arbete förvandlas till en mardröm.
Den självklara lösningen ä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 till önskad tjänst. Filer ändras vanligtvis för att passa formatet för varje tjänst. Detta är mer eller mindre enkelt manuellt arbete, men i takt med att antalet tjänster ökar blir det svårare och svårare att utföra.
Därför är nästa steg API. Med den tjänar molntjänsten på att den kopplar ihop flera tjänster på en gång. Framväxten av ett sådant ekosystem lockar nya kunder på grund av ytterligare möjligheter. En produkt med ny funktionalitet blir mer lönsam och användbar.
Om du skapar dina egna programmeringsgränssnitt lockar detta tredjepartssäljare i form av programmerare som känner till din produkt tack vare API:n. De börjar bygga lösningar baserade på det föreslagna API:et och tjänar pengar genom att automatisera sina kunders uppgifter.
Bokföringssystemet MySklad bygger på enkla processer. Huvudsaken är att arbeta med primära dokument, förmågan att ta emot och skicka varor och ta emot affärsrapporter baserade på primära dokument. Det finns också överföring av data, till exempel till molnbokföring, och dess mottagande från banksystem eller butiker. Vi samarbetar även med nätbutiker: vi får information om produkter och skickar information om saldon.
MySklads första API
Under de 10 år som MySklad arbetat med API har vi skaffat alla möjliga integrationer som gör att vi kan utbyta data, arbeta med banker, göra betalningar och använda extern telefoni.
Under det första året gjorde vi det möjligt att ladda ner valfri data i XML-format. Då var det mycket tydligare och vanligare för användare att hålla data offline, och inte i något moln, och vi gav dem det. Uppladdningen startade genom manuell export från gränssnittet. Det vill säga, det kunde ännu inte kallas ett API.
Samtidigt började vi samarbeta med Rusagro-företaget - de använde redan ett "vuxet" ERP för produktions- och försäljningsplanering, men de automatiserade lastningen av bilar på fabriker i MySklad. Så här fick vi de första rudimenten av 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 dokument var vi tvungna att överföra deras beroenden: information om varor, entreprenörer och lager. En sådan dumpning är inte så svår att generera vid export, men det är ganska svårt att analysera vid import, eftersom all information kommer i ett paket: både om nya dokument och om befintliga.
Det första XML API:et levde inte länge - två år senare började vi bygga om det. Redan i början av arbetet gjorde vi flera misstag när vi byggde mjukvarugränssnittet.
Hur XML API gjordes: illustration från en av våra arkitekter. Förresten, håll utkik efter hans artiklar.
Här är våra huvudsakliga misstag:
- JAXB-uppmärkning gjordes direkt på entitetsbönor. Vi använder Hibernate för att kommunicera med databasen, och JAXB-uppmärkning gjordes för samma bönor. Det här felet dök upp nästan omedelbart: varje uppdatering av datastrukturen ledde till behovet av att omedelbart meddela alla som använder API:t, eller att bygga kryckor som skulle säkerställa kompatibilitet med den tidigare datastrukturen.
- API:et växte som ett tillägg, och vi definierade från början inte vilken del av produkten det var. De tänkte inte ens på om API var något viktigt, om det var nödvändigt att upprätthålla bakåtkompatibilitet för sina första klienter. Vid ett tillfälle var antalet API-användare cirka 5 % av det lilla antalet, och ingen uppmärksamhet ägnades åt dem. Den universella filtreringen som gjordes en gång ledde till att vi användes som en backend. Den här filtreringen var inte alls GraphQL, men något liknande - den fungerade genom många frågesträngsparametrar. Med ett så kraftfullt verktyg var det svårt för användare att motstå, och förfrågningar överfördes till oss så att de skickades direkt från användargränssnittet i deras onlinebutiker. Situationen var en obehaglig överraskning, eftersom tillhandahållandet av en sådan tjänst borde kräva olika prissättning och en generellt annorlunda förståelse av själva API:et som en produkt.
- På grund av att API:et inte utvecklades som en huvudprodukt, togs API-dokumentation fram och publicerades på restbasis - genom reverse engineering. Denna väg verkar ganska enkel och bekväm, men den motsäger att arbeta under ett kontrakt. Detta är när det finns en viss komponent med ett förinställt driftschema. Utvecklaren implementerar det i enlighet med detta schema och uppgift, komponenten testas och kunden får en produkt som matchar analytikerns idé. Reverse engineering släpper ut på marknaden en produkt som helt enkelt existerar: med kryckor, konstiga lösningar och cyklar istället för den nödvändiga funktionaliteten.
- Hela strömmen av förfrågningar som kom genom API:t kunde analyseras som inget annat än en Nginx- eller applikationsserverlogg. Detta tillät oss inte att identifiera ämnesområden, förutom kanske av användare och prenumeranter. Om det inte finns något sätt att reglera ansökan eller kundregistrering blir det omöjligt att analysera situationen. Detta problem hade minst inverkan på utvecklingen av API, det handlar mer om att förstå dess relevans och funktionalitet.
Försök nummer två: REST API
Under 2010 försökte vi bygga ett växelsystem med onlinebokföring – BukhSoft. Tog inte fart. Men under integrationsprocessen dök ett fullfjädrat API upp: en REST-växlingstjänst, där det inte fanns några friheter som att komma åt operationer i form av RPC-anrop. All kommunikation med API:et fördes till standardläget för vila: frågeraden innehåller namnet på enheten, och operationen som utförs med den specificeras med http-metoden. Vi lade till filtrering baserat på när entiteter uppdaterades, och användare har nu möjlighet att bygga replikering med sina system.
Samma år dök ett API för lossning av lager- och lagersaldon upp. De mest värdefulla delarna av systemet har blivit tillgängliga för användarna via API - utbyte av primära dokument och beräknade data om saldon och varukostnad.
I december 2015 publicerade RetailCRM det första tredjepartsbiblioteket som fick åtkomst till vårt API. Den började användas ganska aktivt, medan populariteten för tjänsten som helhet växte, växte belastningen på API:et snabbare än belastningen på webbgränssnittet. En dag förvandlades tillväxten till belastningsökning.
Och detta hopp, indikerat av pilen till vänster, förvånade helt servern som serverade vårt API. Vi tillbringade en vecka med att ta reda på exakt vad som genererade denna belastning. Det visade sig att det är samma förfrågningar som skickats till vårt API från kundfronterna. Ett 50-tal kunder åt allt. Det var då vi insåg ett av våra misstag – en fullständig brist på gränser.
Som ett resultat av detta införde vi en gräns för antalet samtidiga förfrågningar. Det är nu möjligt att inte öppna mer än två förfrågningar samtidigt från ett konto. Detta räcker för att fungera i replikeringsläge för datautbyte i batchläge. Och de som ville använda oss som backend, från det ögonblicket, tvingades att bättre följa tarifferna, eftersom de införde arbete på flera konton i sin mjukvara.
Låt oss göra det i ordning
Redan sedan 2014 har efterfrågan på det befintliga API:et blivit en viktig del av verksamheten, och själva API:et genererar den största datamängden vid datautbyte med kunder. Under 2015 lanserade vi ett projekt för att rensa upp API:t. Vi valde JSON istället för XML som format och började bygga det baserat på de funktioner som identifierades under implementeringen av den tidigare versionen:
- Möjlighet att hantera versioner. Versionering låter dig utveckla en ny version utan att påverka den befintliga applikationen eller störa användarupplevelsen.
- Möjligheten för användaren att se metadata i själva svaret som han får.
- Förmåga att utbyta stora dokument. Om vi behandlar ett dokument med fler än 4-5 tusen positioner blir detta ett problem för servern: en lång transaktion, en lång http-förfrågan. Vi byggde en speciell mekanism som gör att du kan uppdatera ett dokument i delar och hantera enskilda positioner av detta dokument genom att skicka dem till servern.
- Verktyg för replikering fanns också i den tidigare versionen.
- Belastningsgränser är som ett arv från raken som trampades på i den tidigare versionen. Vi införde begränsningar för antalet förfrågningar under en tidsperiod, antalet parallella förfrågningar och förfrågningar från en IP-adress.
Sedan dess har vi släppt två mindre versioner av API:er och lanserat flera specialiserade API:er, men det övergripande tillvägagångssättet har förblivit oförändrat. Det uppdaterade utbytesformatet och den nya arkitekturen gjorde det möjligt att korrigera brister i API:t mycket snabbare.
MySklad API idag
Idag löser MySklad API många problem:
- datautbyte med onlinebutiker, redovisningssystem, banker;
- erhållande av beräknade data och rapporter;
- använd som backend för klientapplikationer - våra mobilapplikationer och stationära kassaapparater fungerar via API
- skicka meddelanden om dataändringar i MySklad - webhooks;
- telefoni;
- lojalitetssystem.
Baserat på API, vår VD Askar Rakhimberdiev på fyra timmar skrev jag en telegrambot som hämtar rester genom API:n:
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 av utgående trafik.
Och här är vad vi kom fram till för alla MySklad API:er:
- mer än 70 integrationer (några av dem kan ses här );
- 8500 företag;
- 12 000 användare;
- 46 miljoner förfrågningar per dag;
- 2 TB/dag av utgående trafik.
Vad är nästa
API-utvecklingsplaner diskuteras aktivt. Vi försöker ta hänsyn till den driftsupplevelse som användarna ger oss. Det är inte alltid möjligt att göra allt på en gång, men en ny version av API:et är precis runt hörnet med bekvämare metadata och en mindre fluffig struktur, OAuth för autentisering och ett API för applikationer inbyggt i gränssnittet.
Du kan följa nyheterna på en speciell webbplats för utvecklare av integrationer med MySklad: .
Källa: will.com