Prvi MySklad API pojavio se prije 10 godina. Sve ovo vrijeme radili smo na postojećim verzijama API-ja i razvijali nove. A nekoliko verzija API-ja već je pokopano.
Ovaj članak će sadržavati puno stvari: kako je nastao API, zašto ga usluga u oblaku treba, što daje korisnicima, na koje smo pogreške uspjeli uskočiti i što želimo učiniti sljedeće.
Moje ime je Oleg Alekseev , tehnički sam direktor i suosnivač MySklada.
Zašto napraviti API za uslugu
Naši klijenti, a to su deseci tisuća poduzetnika, aktivno koriste rješenja u oblaku: bankarstvo, internetske trgovine, robno računovodstvo, CRM. Jednom kada se povežete s jednim, teško je prestati. I sada peta, osma, deseta usluga olakšava posao poduzetniku, ali korisnici ručno prenose podatke između tih cloud usluga. Posao se pretvara u noćnu moru.
Očito rješenje je dati korisnicima mogućnost prijenosa podataka između usluga u oblaku. Na primjer, uvozite i izvozite podatke kao datoteke, koje se zatim mogu učitati na željenu uslugu. Datoteke se obično mijenjaju kako bi odgovarale formatu svake usluge. To je više-manje jednostavan ručni rad, ali s porastom broja ovih usluga postaje sve teže izvediv.
Stoga je sljedeći korak API. Njime usluga u oblaku profitira jer povezuje više usluga u jednom trenutku. Pojava takvog ekosustava privlači nove kupce zbog dodatnih mogućnosti. Proizvod s novom funkcionalnošću postaje isplativiji i korisniji.
Ako kreirate vlastita programska sučelja, to privlači prodajne ljude trećih strana u obliku programera koji znaju za vaš proizvod zahvaljujući API-ju. Počinju graditi rješenja temeljena na predloženom API-ju i zarađuju automatizirajući zadatke svojih kupaca.
Računovodstveni sustav MySklad temelji se na jednostavnim procesima. Osnovno je rad s primarnim dokumentima, mogućnost preuzimanja i otpreme robe, te primanje poslovnih izvješća na temelju primarnih dokumenata. Tu je i prijenos podataka, primjerice u računovodstvo u oblaku, te njihovo primanje iz bankovnih sustava ili maloprodajnih mjesta. Također radimo s internetskim trgovinama: primamo informacije o proizvodima i šaljemo informacije o stanju.
Prvi API MySklada
Tijekom 10 godina rada MySklada s API-jem, stekli smo sve vrste integracija koje nam omogućuju razmjenu podataka, rad s bankama, plaćanje i korištenje vanjske telefonije.
U prvoj godini omogućili smo preuzimanje bilo kakvih podataka u XML formatu. Tada je bilo puno jasnije i uobičajenije da korisnici drže podatke offline, a ne u nekom oblaku, a mi smo im to dali. Prijenos je započeo ručnim izvozom iz sučelja. Odnosno, još se ne bi mogao nazvati API-jem.
Istodobno smo počeli surađivati s tvrtkom Rusagro - oni su već koristili “odrasli” ERP za planiranje proizvodnje i prodaje, ali su automatizirali utovar vagona u tvornicama u MySkladu. Tako smo dobili prve začetke pravog API-ja: razmjena između našeg servisa i ERP-a odvijala se slanjem velike datoteke s podacima o svim vrstama dokumenata.
Ovo je dobra opcija za batch razmjenu podataka, ali smo uz dokumente morali prenijeti i njihove ovisnosti: podatke o robi, izvođačima i skladištima. Takav dump nije tako teško generirati prilikom izvoza, ali ga je prilično teško analizirati prilikom uvoza, jer sve informacije dolaze u jednom paketu: i o novim dokumentima i o postojećim.
Prvi XML API nije dugo poživio - dvije godine kasnije počeli smo ga obnavljati. Već na početku rada napravili smo nekoliko grešaka prilikom izrade softverskog sučelja.
Kako je napravljen XML API: ilustracija jednog od naših arhitekata. Usput, pratite njegove članke.
Evo naših glavnih pogrešaka:
- JAXB označavanje učinjeno je izravno na beanovima entiteta. Koristimo Hibernate za komunikaciju s bazom podataka, a JAXB markup napravljen je za iste grahove. Ova se pogreška pojavila gotovo odmah: svako ažuriranje strukture podataka dovelo je do potrebe da se hitno obavijeste svi koji koriste API ili da se izgrade štake koje bi osigurale kompatibilnost s prethodnom strukturom podataka.
- API je rastao kao dodatak, a mi u početku nismo definirali koji je to dio proizvoda. Nisu ni razmišljali o tome je li API nešto važno, je li potrebno održavati kompatibilnost unatrag za svoje prve klijente. U jednom trenutku broj API korisnika bio je oko 5% od malog broja i nije im se obraćala pažnja. Univerzalno filtriranje provedeno u jednom trenutku dovelo je do toga da smo korišteni kao backend. Ovo filtriranje uopće nije GraphQL, već nešto slično - radilo je kroz mnogo parametara niza upita. Uz ovako moćan alat, korisnici su teško odoljeli, a zahtjevi su proslijeđeni nama tako da su slani direktno sa korisničkog sučelja njihovih online trgovina. Situacija je bila neugodno iznenađenje jer bi pružanje takve usluge zahtijevalo drugačije cijene i općenito drugačije razumijevanje samog API-ja kao proizvoda.
- Zbog činjenice da API nije razvijen kao glavni proizvod, API dokumentacija je proizvedena i objavljena na rezidualnoj osnovi - obrnutim inženjeringom. Ovaj put se čini prilično jednostavan i prikladan, ali je u suprotnosti s radom po ugovoru. To je kada postoji određena komponenta s unaprijed postavljenom shemom rada. Programer ga implementira u skladu s ovom shemom i zadatkom, komponenta se testira, a klijent dobiva proizvod koji odgovara ideji analitičara. Obrnuti inženjering na tržište izbacuje proizvod koji jednostavno postoji: sa štakama, čudnim rješenjima i biciklima umjesto potrebne funkcionalnosti.
- Cijeli tok zahtjeva koji je došao kroz API mogao se analizirati kao ništa više od Nginx ili dnevnika poslužitelja aplikacija. To nam nije omogućilo da identificiramo tematska područja, osim možda prema korisnicima i pretplatnicima. Ako ne postoji način reguliranja prijave ili registracije klijenta, postaje nemoguće analizirati situaciju. Ovaj problem je najmanje utjecao na razvoj API-ja, više se radi o razumijevanju njegove relevantnosti i funkcionalnosti.
Pokušaj broj dva: REST API
2010. pokušali smo izgraditi sustav razmjene s online računovodstvom - BukhSoft. Nije poletio. Ali tijekom procesa integracije pojavio se punopravni API: usluga REST razmjene, gdje nije bilo sloboda poput pristupa operacijama u obliku RPC poziva. Sva komunikacija s API-jem dovedena je u standardni način rada za odmor: linija upita sadrži naziv entiteta, a operacija koja se s njim izvodi određena je pomoću http metode. Dodali smo filtriranje na temelju vremena ažuriranja entiteta, a korisnici sada imaju priliku graditi replikaciju sa svojim sustavima.
Iste godine pojavio se API za istovar stanja skladišta i zaliha. Putem API-ja korisnicima su dostupni najvrjedniji dijelovi sustava - razmjena primarnih dokumenata i obračunatih podataka o stanjima i troškovima robe.
U prosincu 2015. RetailCRM je objavio prvu biblioteku treće strane koja je pristupila našem API-ju. Počeo se koristiti prilično aktivno, dok je popularnost usluge u cjelini rasla, opterećenje API-ja raslo je brže od opterećenja web sučelja. Jednog dana rast se pretvorio u porast opterećenja.
I ovaj skok, označen strelicom lijevo, potpuno je zadivio poslužitelj koji poslužuje naš API. Proveli smo tjedan dana otkrivajući što točno stvara ovo opterećenje. Ispostavilo se da su to isti zahtjevi koji su našem API-ju proslijeđeni s klijentskih frontova. Sve je pojelo oko 50 kupaca. Tada smo shvatili jednu od naših grešaka - potpuni nedostatak granica.
Kao rezultat toga, uveli smo ograničenje broja istodobnih zahtjeva. Sada je moguće otvoriti najviše dva zahtjeva istovremeno s jednog računa. To je dovoljno za rad u načinu replikacije za razmjenu podataka u batch načinu rada. A oni koji su nas htjeli koristiti kao backend, od tog trenutka su bili prisiljeni bolje se pridržavati tarifa, jer su u svoj softver uveli rad na više računa.
Idemo to posložiti
Već od 2014. godine potražnja za postojećim API-jem postala je važan dio poslovanja, a sam API generira najveću količinu podataka u razmjeni podataka s klijentima. U 2015. pokrenuli smo projekt čišćenja API-ja. Izabrali smo JSON umjesto XML-a kao format i počeli ga graditi na temelju značajki koje su identificirane tijekom implementacije prethodne verzije:
- Sposobnost upravljanja verzijama. Određivanje verzija vam omogućuje da razvijete novu verziju bez utjecaja na postojeću aplikaciju ili ometanja korisničkog iskustva.
- Mogućnost da korisnik vidi metapodatke u samom odgovoru koji dobije.
- Mogućnost razmjene velikih dokumenata. Ako obradimo dokument s više od 4-5 tisuća pozicija, to postaje problem za poslužitelj: duga transakcija, dugačak http zahtjev. Izgradili smo poseban mehanizam koji vam omogućuje ažuriranje dokumenta u dijelovima i upravljanje pojedinačnim pozicijama ovog dokumenta slanjem na poslužitelj.
- Alati za replikaciju također su bili prisutni u prethodnoj verziji.
- Ograničenja opterećenja su kao nasljeđe grablji na koje se nagazilo u prethodnoj verziji. Uveli smo ograničenja broja zahtjeva u vremenskom razdoblju, broja paralelnih zahtjeva i zahtjeva s jedne IP adrese.
Od tada smo izdali dvije manje verzije API-ja i pokrenuli nekoliko specijaliziranih API-ja, ali cjelokupni pristup je ostao nepromijenjen. Ažurirani format razmjene i nova arhitektura omogućili su mnogo brže ispravljanje nedostataka u API-ju.
MySklad API danas
Danas MySklad API rješava mnoge probleme:
- razmjena podataka s online trgovinama, računovodstvenim sustavima, bankama;
- dobivanje izračunatih podataka i izvješća;
- koristiti kao backend za klijentske aplikacije - naše mobilne aplikacije i stolna blagajna rade preko API-ja
- slanje obavijesti o promjenama podataka u MySkladu - webhooks;
- telefonija;
- sustavi lojalnosti.
Na temelju API-ja, naš izvršni direktor Askar Rakhimberdiev u četiri sata napisao sam telegram bot koji izvlači ostatke kroz API:
Sada suhe brojke.
Evo naše statistike za stari REST API:
- 400 tvrtki;
- 600 korisnika;
- 2 milijuna zahtjeva dnevno;
- 200 GB/dan odlaznog prometa.
A evo što smo smislili za sve MySklad API-je:
- više od 70 integracija (neke od njih možete pogledati ovdje );
- 8500 tvrtki;
- 12 000 korisnika;
- 46 milijuna zahtjeva dnevno;
- 2 TB/dan odlaznog prometa.
što dalje
O planovima za razvoj API-ja aktivno se raspravlja. Trudimo se uzeti u obzir radna iskustva koja nam pružaju korisnici. Nije uvijek moguće učiniti sve odjednom, ali nova verzija API-ja je pred vratima s praktičnijim metapodacima i manje pahuljastom strukturom, OAuth za autentifikaciju i API-jem za aplikacije ugrađenim u sučelje.
Novosti možete pratiti na posebnoj web stranici za programere integracija s MySkladom: .
Izvor: www.habr.com