{"id":34354,"date":"2019-10-31T21:57:51","date_gmt":"2019-10-31T18:57:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pisali-api-porvali-xml-dva\/"},"modified":"2019-10-31T21:57:51","modified_gmt":"2019-10-31T18:57:51","slug":"pisali-api-porvali-xml-dva","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"Pisalno API \u2014 raztrgali XML (dva)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prvi API MojeSkladiste pojavio se prije 10 godina. Cijelo to vrijeme radimo na postoje\u0107im verzijama API-ja i razvijamo nove. Neke verzije API-ja su ve\u0107 zaboravljene. <\/p>\n

U ovom \u010dlanku bit \u0107e puno svega: kako smo stvorili API, za\u0161to je potreban obla\u010dnom servisu, \u0161to donosi korisnicima, na koje smo zamke ve\u0107 nai\u0161li i \u0161to planiramo raditi dalje.
\n<\/a><\/noindex>
\nZovem se Oleg Alekseev oalexeev<\/a><\/noindex>, ja sam tehni\u010dki direktor i suosniva\u010d MojeSkladiste. <\/p>\n

Za\u0161to praviti API za servis<\/h2>\n

\nNa\u0161i klijenti, a to su deseci tisu\u0107a poduzetnika, aktivno koriste obla\u010dna rje\u0161enja: bankarstvo, internetske trgovine, upravljanje robom, CRM. Spojite se s jednim \u2014 i ve\u0107 je te\u0161ko stati. I evo ve\u0107 peti, osmi, deseti servis olak\u0161ava posao poduzetnika, ali korisnici ru\u010dno prenose podatke izme\u0111u tih obla\u010dnih servisa. Rad postaje no\u0107na mora.<\/p>\n

O\u010dito rje\u0161enje \u2014 omogu\u0107iti korisnicima prijenos podataka izme\u0111u obla\u010dnih servisa. Na primjer, uvoziti i izvoziti podatke kao datoteke koje se zatim mogu u\u010ditati u potrebni servis. Datoteke se obi\u010dno prilago\u0111avaju formatu svakog servisa. To je manje-vi\u0161e jednostavan ru\u010dni rad, ali s rastom broja ovih servisa, obavljanje toga postaje sve slo\u017eenije.<\/p>\n

Stoga je sljede\u0107i korak \u2014 API. S njim obla\u010dni servis pobje\u0111uje jer povezuje nekoliko servisa na jednoj ta\u010dki. Pojava takve ekosustava privla\u010di nove klijente zahvaljuju\u0107i dodatnim mogu\u0107nostima. Proizvod s novim funkcionalnostima postaje profitabilniji i korisniji.<\/p>\n

Ako se kreiraju vlastiti programski su\u010delja, to privla\u010di vanjske prodava\u010de u obliku programera koji saznaju za va\u0161 proizvod zahvaljuju\u0107i API-ju. Oni po\u010dinju izgra\u0111ivati rje\u0161enja na temelju ponu\u0111enog API-ja i zara\u0111uju novac na automatizaciji zadataka svojih klijenata.<\/p>\n

Sistem vo\u0111enja MojeSkladiste temelji se na jednostavnim procesima. Glavno \u2014 rad s primarnim dokumentima, mogu\u0107nost prihvata i otpreme robe, dobivanje poslovnih izvje\u0161taja na temelju primarnih dokumenata. Tako\u0111er postoji prijenos podataka, na primjer u obla\u010dno ra\u010dunovodstvo, i njihovo dobavljanje iz bankovnih sistema ili maloprodajnih mjesta. Tako\u0111er radimo s internetskim trgovinama: dobivamo informacije o robama i \u0161aljemo podatke o zalihama.<\/p>\n

\"Pisalno
\n<\/p>\n

Prvi API MojeSkladi\u0161te<\/h2>\n

\nTijekom 10 godina rada MojeSkladi\u0161te s API-jem stvorili smo razne integracije koje omogu\u0107uju razmjenu podataka, rad s bankama, obavljanje pla\u0107anja i kori\u0161tenje vanjske telefonije.<\/p>\n

U prvoj godini omogu\u0107ili smo izvo\u0111enje bilo kakvih podataka u XML formatu. Tada je korisnicima bilo puno jasnije i uobi\u010dajenije \u010duvati podatke offline, a ne u nekoj obla\u010dnoj usluzi, i to smo im omogu\u0107ili. Izvoz je pokrenut ru\u010dnim izvo\u0111enjem iz su\u010delja. Dakle, u tom trenutku to se nije moglo nazvati API-jem. <\/p>\n

Tada smo po\u010deli suradnju s kompanijom Rusagro \u2014 oni su ve\u0107 koristili 'zrelu' ERP za planiranje proizvodnje i prodaje, a u\u010ditavanje vagona u tvornicama automatizirali su u MojeSkladi\u0161te. Tako smo dobili prve naznake pravog API-ja: razmjena izme\u0111u na\u0161e usluge i ERP-a odvijala se slanjem velikog datoteka s podacima o svim vrstama dokumenata. <\/p>\n

To je bio dobar izbor za paketnu razmjenu podataka, ali zajedno s dokumentima trebalo je prenositi njihove zavisnosti: informacije o proizvodima, partnerima i skladi\u0161tima. Takvu hrpu nije tako te\u0161ko generirati prilikom izvoza, ali je prili\u010dno te\u0161ko razdvojiti prilikom uvoza, jer u jednom paketu dolaze sve informacije: i o novim dokumentima, i o ve\u0107 postoje\u0107ima.<\/p>\n

Prvi XML API nije trajao dugo \u2014 nakon dvije godine po\u010deli smo s njegovom rekonstrukcijom. \u010cak i na po\u010detku rada napravili smo nekoliko pogre\u0161aka prilikom izrade programskog su\u010delja.<\/p>\n

\"Pisalno
\nKako je izra\u0111en XML API: ilustracija jednog od na\u0161ih arhitekata. Ina\u010de, o\u010dekujte njegove \u010dlanke.<\/i><\/p>\n

Evo na\u0161ih glavnih gre\u0161aka:<\/p>\n

    \n
  1. JAXB ozna\u010davanje je napravljeno izravno na entitet bini. Za komunikaciju s bazom koristimo Hibernate, a na te iste bine je napravljeno JAXB ozna\u010davanje. Ova pogre\u0161ka se brzo pojavila: svaka promjena strukture podataka zahtijevala je hitno obavje\u0161tavanje svih koji koriste API, ili izgradnju 'kosti' koja bi osigurala kompatibilnost s prethodnom strukturom podataka.<\/li>\n
  2. API se je razvijal kot dodatek, in sprva nismo opredelili, kak\u0161en del izdelka je. Nismo razmi\u0161ljali niti o tem, ali je API kaj pomembnega, ali je treba ohranjati nazaj kompatibilnost za prve stranke. V nekem trenutku je \u0161tevilo uporabnikov API zna\u0161alo pribli\u017eno 5 % od skupnega majhnega \u0161tevila, in na njih nismo dajali pozornosti. Splo\u0161na filtracija, ki smo jo neko\u010d uvedli, je povzro\u010dila, da smo postali uporabljen kot backend. Ta filtracija ni bila prav GraphQL, ampak nekaj takega \u2014 delovala je preko mno\u017eice parametrov v poizvedovanju. S tako mo\u010dnim orodjem je bilo uporabnikom te\u017eko ostati stran, in na\u0161a zahteva je bila preusmerjena tako, da so jih po\u0161iljali neposredno iz UI njihovih spletnih trgovin. Situacija je bila neprijetno presene\u010denje, saj bi morala taka storitev zahtevati druga\u010dno tarifacijo in sploh druga\u010dno razumevanje samega API kot izdelka.<\/li>\n
  3. Ker se API ni razvijal kot glavni izdelek, je bila dokumentacija za API izdelana in objavljena kot stranski produkt \u2014 skozi in\u017eenirstvo povratnih informacij. Ta pot se zdi dokaj preprosta in priro\u010dna, 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\u017eenirstvo povratnih informacij pa na trg vr\u017ee izdelek, ki preprosto obstaja: z obratovanji, \u010dudnimi re\u0161itvami in biciklisti namesto potrebne funkcionalnosti. <\/li>\n
  4. Vse zahteve, ki so prihajale preko API, je bilo mogo\u010de analizirati le kot dnevnik Nginx-a ali aplikacijskega stre\u017enika. To ni omogo\u010dilo razlikovanja predmetnih podro\u010dij, razen \u010de bi jih razdelili po uporabnikih in naro\u010dnikih. \u010ce ni mo\u017enosti regulirati registracije aplikacij ali strank, postane analiza situacije nemogo\u010da. Ta problem je najmanj vplival na razvoj API, bolj gre za razumevanje njegove povpra\u0161evanja in polnosti funkcionalnosti.<\/li>\n<\/ol>\n

    <\/p>\n

    Poskus \u0161tevilka dva: REST API<\/h2>\n

    \nV letu 2010 smo posku\u0161ali zgraditi sistem izmenjave z online ra\u010dunovodstvom \u2014 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\u010dina delovanja za REST: v nizu poizvedbe se nahaja ime entitete, medtem ko se operacija, ki se izvaja na njej, dolo\u010di s pomo\u010djo http-metode. Dodali smo filtriranje po trenutku posodabljanja entitet, kar je uporabnikom omogo\u010dilo gradnjo replikacije s svojimi sistemi.<\/p>\n

    V istem letu se je pojavil API za izvoz skladi\u0161\u010dnih in blagovnih zalog. Uporabnikom so postale dostopne prek API-ja najbolj dragocene komponente sistema \u2014 izmenjava prvotnih dokumentov in ra\u010dunovodska podatkov o zalogah in stro\u0161kih blaga.<\/p>\n

    Decembra 2015 je RetailCRM objavil prvo zunanje knji\u017enico za dostop do na\u0161ega API-ja. Uporabljali so jo precej aktivno, pri \u010demer je rasla priljubljenost storitve kot celote, obremenitev na API-ju pa je rastla hitreje kot obremenitev na spletni vmesnik. Enkrat je rast pre\u0161la v skok obremenitve. <\/p>\n

    \"Pisalno
    \n
    \n\"Pisalno
    \n
    \nIn ta skok, na katerega ka\u017ee pu\u0161\u010dica levo, je popolnoma osupnil stre\u017enik, ki poganja na\u0161 API. Teden dni smo se ukvarjali s tem, kaj pravzaprav povzro\u010da to obremenitev. Izkazalo se je, da so to tisti zahtevki, ki so se prena\u0161ali na na\u0161 API iz frontov pri strankah. Vse je pojedlo okoli 50 strank. Takrat smo spoznali eno od svojih napak \u2014 popolno pomanjkanje omejitev. <\/p>\n

    Na koncu smo uvedli omejitev za \u0161tevilo hkratnih poizvedb. Z enega ra\u010duna je bilo mo\u017eno hkrati odpreti najve\u010d dve poizvedbi. To je dovolj za delovanje v na\u010dinu replikacije za izmenjavo podatkov v paketnem na\u010dinu. Tisti, ki so \u017eeleli uporabljati nas kot backend, so bili od takrat naprej prisiljeni bolj ustrezati tarifam, saj so uvedli delo preko ve\u010d ra\u010dunov v svojih programskih sredstvih.<\/p>\n

    Urejamo zadeve<\/h2>\n

    \n\u017de od leta 2014 je povpra\u0161evanje po obstoje\u010dem API-ju postalo pomemben del poslovanja, sam API pa je generiral najve\u010dje koli\u010dine podatkov pri izmenjavi z klienti. Leta 2015 smo zagnali projekt urejanja API-ja. Izbrali smo format JSON namesto XML in za\u010deli graditi na osnovi zna\u010dilnosti, ki smo jih odkrili pri izvajanju prej\u0161nje razli\u010dice:<\/p>\n

      \n
    1. Mo\u017enost upravljanja razli\u010dicami. Razli\u010dkovanje omogo\u010da razvoj nove razli\u010dice brez vpliva na obstoje\u010do aplikacijo in brez motenj za uporabnike. <\/li>\n
    2. Mo\u017enost, da uporabnik vidi metapodatke v sami odgovoru, ki ga prejme.<\/li>\n
    3. Mo\u017enost izmenjave velikih dokumentov. \u010ce obdelujemo dokument s \u0161tevilom postavk ve\u010djim od 4-5 tiso\u010d, to postane te\u017eava za stre\u017enik: dolga transakcija, dolg http-zahtjev. Razvili smo poseben mehanizem, ki omogo\u010da posodabljanje dokumenta v delih in upravljanje posameznih postavk tega dokumenta ter njihovo po\u0161iljanje na stre\u017enik.<\/li>\n
    4. Orodja za replikacijo \u2014 bila so \u017ee v prej\u0161nji razli\u010dici.<\/li>\n
    5. Omejitve glede obremenitve \u2014 kot dedi\u0161\u010dina te\u017eav, na katere smo naleteli v prej\u0161nji razli\u010dici. Uvedli smo omejitve glede \u0161tevila zahtevkov v dolo\u010denem \u010dasu, \u0161tevila hkratnih zahtevkov in zahtevkov z enega ip-naslova.<\/li>\n<\/ol>\n

      \nOd takrat smo izdali dve manj\u0161i razli\u010dici API in zagnali ve\u010d specializiranih API-jev, vendar je osnovni pristop ostal nespremenjen. Posodobljen format izmenjave in nova arhitektura sta omogo\u010dila hitrej\u0161e odpravljanje pomanjkljivosti v API-ju.<\/p>\n

      API MojeSklade danes<\/h2>\n

      \nDanes API MojeSklade re\u0161uje \u0161tevilne naloge:<\/p>\n