Prvi API MojeSkladiste pojavio se prije 10 godina. Cijelo to vrijeme radimo na postojećim verzijama API-ja i razvijamo nove. Neke verzije API-ja su već zaboravljene.
U ovom članku bit će puno svega: kako smo stvorili API, zašto je potreban oblačnom servisu, što donosi korisnicima, na koje smo zamke već naišli i što planiramo raditi dalje.
Zovem se Oleg Alekseev , ja sam tehnički direktor i suosnivač MojeSkladiste.
Zašto praviti API za servis
Naši klijenti, a to su deseci tisuća poduzetnika, aktivno koriste oblačna rješenja: bankarstvo, internetske trgovine, upravljanje robom, CRM. Spojite se s jednim — i već je teško stati. I evo već peti, osmi, deseti servis olakšava posao poduzetnika, ali korisnici ručno prenose podatke između tih oblačnih servisa. Rad postaje noćna mora.
Očito rješenje — omogućiti korisnicima prijenos podataka između oblačnih servisa. Na primjer, uvoziti i izvoziti podatke kao datoteke koje se zatim mogu učitati u potrebni servis. Datoteke se obično prilagođavaju formatu svakog servisa. To je manje-više jednostavan ručni rad, ali s rastom broja ovih servisa, obavljanje toga postaje sve složenije.
Stoga je sljedeći korak — API. S njim oblačni servis pobjeđuje jer povezuje nekoliko servisa na jednoj tački. Pojava takve ekosustava privlači nove klijente zahvaljujući dodatnim mogućnostima. Proizvod s novim funkcionalnostima postaje profitabilniji i korisniji.
Ako se kreiraju vlastiti programski sučelja, to privlači vanjske prodavače u obliku programera koji saznaju za vaš proizvod zahvaljujući API-ju. Oni počinju izgrađivati rješenja na temelju ponuđenog API-ja i zarađuju novac na automatizaciji zadataka svojih klijenata.
Sistem vođenja MojeSkladiste temelji se na jednostavnim procesima. Glavno — rad s primarnim dokumentima, mogućnost prihvata i otpreme robe, dobivanje poslovnih izvještaja na temelju primarnih dokumenata. Također postoji prijenos podataka, na primjer u oblačno računovodstvo, i njihovo dobavljanje iz bankovnih sistema ili maloprodajnih mjesta. Također radimo s internetskim trgovinama: dobivamo informacije o robama i šaljemo podatke o zalihama.
Prvi API MojeSkladište
Tijekom 10 godina rada MojeSkladište s API-jem stvorili smo razne integracije koje omogućuju razmjenu podataka, rad s bankama, obavljanje plaćanja i korištenje vanjske telefonije.
U prvoj godini omogućili smo izvođenje bilo kakvih podataka u XML formatu. Tada je korisnicima bilo puno jasnije i uobičajenije čuvati podatke offline, a ne u nekoj oblačnoj usluzi, i to smo im omogućili. Izvoz je pokrenut ručnim izvođenjem iz sučelja. Dakle, u tom trenutku to se nije moglo nazvati API-jem.
Tada smo počeli suradnju s kompanijom Rusagro — oni su već koristili 'zrelu' ERP za planiranje proizvodnje i prodaje, a učitavanje vagona u tvornicama automatizirali su u MojeSkladište. Tako smo dobili prve naznake pravog API-ja: razmjena između naše usluge i ERP-a odvijala se slanjem velikog datoteka s podacima o svim vrstama dokumenata.
To je bio dobar izbor za paketnu razmjenu podataka, ali zajedno s dokumentima trebalo je prenositi njihove zavisnosti: informacije o proizvodima, partnerima i skladištima. Takvu hrpu nije tako teško generirati prilikom izvoza, ali je prilično teško razdvojiti prilikom uvoza, jer u jednom paketu dolaze sve informacije: i o novim dokumentima, i o već postojećima.
Prvi XML API nije trajao dugo — nakon dvije godine počeli smo s njegovom rekonstrukcijom. Čak i na početku rada napravili smo nekoliko pogrešaka prilikom izrade programskog sučelja.
Kako je izrađen XML API: ilustracija jednog od naših arhitekata. Inače, očekujte njegove članke.
Evo naših glavnih grešaka:
- JAXB označavanje je napravljeno izravno na entitet bini. Za komunikaciju s bazom koristimo Hibernate, a na te iste bine je napravljeno JAXB označavanje. Ova pogreška se brzo pojavila: svaka promjena strukture podataka zahtijevala je hitno obavještavanje svih koji koriste API, ili izgradnju 'kosti' koja bi osigurala kompatibilnost s prethodnom strukturom podataka.
- API se je razvijal kot dodatek, in sprva nismo opredelili, kakšen del izdelka je. Nismo razmišljali niti o tem, ali je API kaj pomembnega, ali je treba ohranjati nazaj kompatibilnost za prve stranke. V nekem trenutku je število uporabnikov API znašalo približno 5 % od skupnega majhnega števila, in na njih nismo dajali pozornosti. Splošna filtracija, ki smo jo nekoč uvedli, je povzročila, da smo postali uporabljen kot backend. Ta filtracija ni bila prav GraphQL, ampak nekaj takega — delovala je preko množice parametrov v poizvedovanju. S tako močnim orodjem je bilo uporabnikom težko ostati stran, in naša zahteva je bila preusmerjena tako, da so jih pošiljali neposredno iz UI njihovih spletnih trgovin. Situacija je bila neprijetno presenečenje, saj bi morala taka storitev zahtevati drugačno tarifacijo in sploh drugačno razumevanje samega API kot izdelka.
- Ker se API ni razvijal kot glavni izdelek, je bila dokumentacija za API izdelana in objavljena kot stranski produkt — skozi inženirstvo povratnih informacij. Ta pot se zdi dokaj preprosta in priročna, a je v nasprotju z delom po pogodbi. To pomeni, da obstaja neki komponent s prednastavljeno shemo delovanja. Razvijalec ga implementira v skladu s to shemo in nalogo, komponenta prestane testiranje, stranka dobi izdelek, ki ustreza zamisli analitika. Inženirstvo povratnih informacij pa na trg vrže izdelek, ki preprosto obstaja: z obratovanji, čudnimi rešitvami in biciklisti namesto potrebne funkcionalnosti.
- Vse zahteve, ki so prihajale preko API, je bilo mogoče analizirati le kot dnevnik Nginx-a ali aplikacijskega strežnika. To ni omogočilo razlikovanja predmetnih področij, razen če bi jih razdelili po uporabnikih in naročnikih. Če ni možnosti regulirati registracije aplikacij ali strank, postane analiza situacije nemogoča. Ta problem je najmanj vplival na razvoj API, bolj gre za razumevanje njegove povpraševanja in polnosti funkcionalnosti.
Poskus številka dva: REST API
V letu 2010 smo poskušali zgraditi sistem izmenjave z online računovodstvom — BukhSoftom. Ni obrodilo sadov. A v procesu integracije je nastal popoln API: REST storitev izmenjave, kjer niso bile prisotne prostovoljne izjave, kot na primer klici operacij v obliki RPC. Vsa komunikacija z API-jem je bila pripeljana do standardnega načina delovanja za REST: v nizu poizvedbe se nahaja ime entitete, medtem ko se operacija, ki se izvaja na njej, določi s pomočjo http-metode. Dodali smo filtriranje po trenutku posodabljanja entitet, kar je uporabnikom omogočilo gradnjo replikacije s svojimi sistemi.
V istem letu se je pojavil API za izvoz skladiščnih in blagovnih zalog. Uporabnikom so postale dostopne prek API-ja najbolj dragocene komponente sistema — izmenjava prvotnih dokumentov in računovodska podatkov o zalogah in stroških blaga.
Decembra 2015 je RetailCRM objavil prvo zunanje knjižnico za dostop do našega API-ja. Uporabljali so jo precej aktivno, pri čemer je rasla priljubljenost storitve kot celote, obremenitev na API-ju pa je rastla hitreje kot obremenitev na spletni vmesnik. Enkrat je rast prešla v skok obremenitve.
In ta skok, na katerega kaže puščica levo, je popolnoma osupnil strežnik, ki poganja naš API. Teden dni smo se ukvarjali s tem, kaj pravzaprav povzroča to obremenitev. Izkazalo se je, da so to tisti zahtevki, ki so se prenašali na naš API iz frontov pri strankah. Vse je pojedlo okoli 50 strank. Takrat smo spoznali eno od svojih napak — popolno pomanjkanje omejitev.
Na koncu smo uvedli omejitev za število hkratnih poizvedb. Z enega računa je bilo možno hkrati odpreti največ dve poizvedbi. To je dovolj za delovanje v načinu replikacije za izmenjavo podatkov v paketnem načinu. Tisti, ki so želeli uporabljati nas kot backend, so bili od takrat naprej prisiljeni bolj ustrezati tarifam, saj so uvedli delo preko več računov v svojih programskih sredstvih.
Urejamo zadeve
Že od leta 2014 je povpraševanje po obstoječem API-ju postalo pomemben del poslovanja, sam API pa je generiral največje količine podatkov pri izmenjavi z klienti. Leta 2015 smo zagnali projekt urejanja API-ja. Izbrali smo format JSON namesto XML in začeli graditi na osnovi značilnosti, ki smo jih odkrili pri izvajanju prejšnje različice:
- Možnost upravljanja različicami. Različkovanje omogoča razvoj nove različice brez vpliva na obstoječo aplikacijo in brez motenj za uporabnike.
- Možnost, da uporabnik vidi metapodatke v sami odgovoru, ki ga prejme.
- Možnost izmenjave velikih dokumentov. Če obdelujemo dokument s številom postavk večjim od 4-5 tisoč, to postane težava za strežnik: dolga transakcija, dolg http-zahtjev. Razvili smo poseben mehanizem, ki omogoča posodabljanje dokumenta v delih in upravljanje posameznih postavk tega dokumenta ter njihovo pošiljanje na strežnik.
- Orodja za replikacijo — bila so že v prejšnji različici.
- Omejitve glede obremenitve — kot dediščina težav, na katere smo naleteli v prejšnji različici. Uvedli smo omejitve glede števila zahtevkov v določenem času, števila hkratnih zahtevkov in zahtevkov z enega ip-naslova.
Od takrat smo izdali dve manjši različici API in zagnali več specializiranih API-jev, vendar je osnovni pristop ostal nespremenjen. Posodobljen format izmenjave in nova arhitektura sta omogočila hitrejše odpravljanje pomanjkljivosti v API-ju.
API MojeSklade danes
Danes API MojeSklade rešuje številne naloge:
- izmenjava podatkov z spletno trgovino, računovodskimi sistemi, bankami;
- prejemanje izračunskih podatkov, poročil;
- uporaba kot backend za klientske aplikacije — naše mobilne aplikacije in desktoppna blagajna delujejo skozi API
- pošiljanje obvestil o spremembah podatkov v MojeSklade — webhooks;
- telefonija;
- lojalnostni sistemi.
Na osnovi API je naš direktor Askar Rakhimberdiev v štirih urah napisal telegram-bota, ki prenaša preko API ostanke:
Zdaj suhe številke.
Tukaj je naša statistika za staro REST API:
- 400 podjetij;
- 600 uporabnikov;
- 2 milijona zahtevkov na dan;
- 200 GB/dan odhodnega prometa.
In tukaj je, kam smo prišli glede vseh API-jev MojeSklade:
- več kot 70 integracij (del jih lahko vidite tukaj );
- 8500 podjetij;
- 12 000 uporabnikov;
- 46 milijonov zahtevkov na dan;
- 2 TB/dan odhodnega prometa.
Kaj naprej
Načrti za razvoj API-ja so v aktivni razpravi. Trudimo se upoštevati izkušnje z obratovanjem, ki nam jih zagotavljajo uporabniki. Ni vedno mogoče vsega uresničiti takoj, vendar je nova različica API-ja, ki bo imela bolj uporabne metapodatke in manj zapleteno strukturo, že blizu, ter OAuth za avtentikacijo in API za vgrajevanje v uporabniške vmesnike aplikacij.
Novice lahko spremljate na posebni spletni strani za razvijalce integracij z MojimSkladi: .
Izvor: habr.com
