Preskoči na glavno vsebino

Ako používať API?

Odporúčané postupy, čomu sa vyhnúť a ako rozumieť chybovým kódom.

Avtor: Petr Pech

Používanie REST API ABRA Flexi otvára široké možnosti, ako systém integrovať s ďalšími aplikáciami a automatizovať bežné procesy. Aby však integrácia fungovala spoľahlivo a efektívne, je potrebné riadiť sa určitými pravidlami a osvedčenými postupmi. Správny prístup ušetrí čas vývojárom, zníži záťaž systému a zabráni zbytočným chybám pri práci s dátami.

V tomto článku sa zameriame na odporúčané best practices, ktoré vám pomôžu API využívať naplno – od optimalizácie dotazov, správneho stránkovania alebo strategie opakovania požiadaviek, až po prácu s chybovými kódmi a ich pochopenie. Dozviete sa tiež, ako predísť duplicitám, ako pracovať s limitmi a prečo je dôležité myslieť na bezpečnosť a konzistenciu dát už pri návrhu integrácie.

Cieľom je nielen „získať dáta“, ale urobiť to efektívne - s ohľadom na výkon systému, bezpečnosť a spoľahlivosť celej integrácie.

Autentizácia a bezpečnosť

Bezpečná autentizácia

Autentizácia je základným prvkom bezpečnosti pri práci s REST API. Ak nie je nastavená správne, môže dôjsť k úniku citlivých dát alebo k neoprávnenému prístupu do systému. Preto je nutné používať bezpečné metódy prihlásenia a prenosu dát a vyhnúť sa zastaraným či rizikovým postupom, ktoré môžu bezpečnosť celej integrácie ohroziť.

  • Všetku komunikáciu vykonávajte vždy cez HTTPS, aby boli dáta pri prenose šifrované.

  • Nikdy neposielajte heslá v URL (sú viditeľné v logoch a histórii prehliadača).

  • Používajte iba API používateľov so správnym nastavením práv. Overte si, že prístupové údaje majú len takú oprávnenia, ktoré sú skutočne potrebné (princíp minimálnych oprávnení).

Bezpečné zaobchádzanie s prihlasovacími údajmi

Prístupové údaje (užívateľské mená, heslá, API tokeny) sú kľúčom k vašim dátam. Ak sa dostanú do nepovolaných rúk, môže dôjsť k vážnemu bezpečnostnému incidentu. Preto je nutné s nimi zaobchádzať maximálne opatrne a riadiť sa osvedčenými postupmi, ktoré riziko úniku minimalizujú.

  • Nikdy neukladajte prihlasovacie údaje priamo v kóde (hard-coding). Používajte konfiguračné súbory alebo systém na správu tajomstiev (Secrets Manager, Vault).

  • Nezdieľajte tokeny ani heslá v e-mailoch alebo chatoch, kde by mohli byť zachytené.

  • Rotujte tokeny a heslá pravidelne a obmedzte ich dobu platnosti, ak to systém umožňuje.

  • Ukladajte citlivé údaje bezpečne – napríklad šifrovane v databáze alebo v zabezpečenom úložisku.

  • Používajte oddelené účty pre testovacie a produkčné prostredie, aby nedošlo k zámene.

Optimalizácia dotazov a efektívna práca s dátami

Cieľom nie je „stiahnuť všetko“, ale rýchlo získať presne to, čo potrebujete, s minimálnou záťažou pre sieť aj server. Premýšľajte o tom, ako dáta používate: čo skutočne zobrazíte, ako často sa menia, či ich musíte načítať hneď, alebo možno časť predpočítať či uložiť do cache. Dobre navrhnuté dotazy a tok dát skracujú odozvu, šetria limity API a zvyšujú stabilitu celej integrácie.

  • Dotazujte sa len na nutné polia – obmedzte výber na konkrétne stĺpce (úroveň detailu); menší payload = nižšia latencia.

  • Používajte filtre a stránkovanie – prenášajte len relevantné záznamy (filtrácia).

  • Stránkovanie - dotazujte sa na záznamy v dávkach (stránkovanie).

  • Batch operácie - je efektívnejšie poslať jednu hromadnú dávku než stovky samostatných požiadaviek

  • Caching odpovedí – ukladajte si výsledky často používaných dotazov (číselníky a málo sa meniace zoznamy)

Changes API a Webhooks

Nie všetky dáta musíte stahovať znova – efektívnejšie je odoberať len zmeny. Na to slúžia zmenové feedy (Changes API) a push notifikácie (webhooky). Changes API je ideálne na spoľahlivú delta synchronizáciu riadenú klientom (polling + kurzor), webhooky zase na rýchlu reakciu na udalosti bez zbytočného dotazovania. V praxi je často najlepšie oba prístupy kombinovať.

Práca s delta exportom

Namiesto stahovania celej agendy pri každej synchronizácii je lepšie získať len to, čo sa skutočne zmenilo. Delta export výrazne šetrí prenosy dát, znižuje záťaž API aj databázy a urýchľuje integráciu – obzvlášť pri väčších agendách alebo pri pravidelnom reportingu.

  • Používajte pole lastUpdate na načítanie len nových či zmenených záznamov.

    • V BI napojeniach, často pri účtovných reportoch, stahujte dáta inkrementálne, nie celú históriu.

    • Ukladajte si posledný čas synchronizácie a od neho načítavajte len delta zmeny.

Limity a záťaž

Paralelné dotazy

Pri práci s REST API nespúšťajte viac rovnakých dotazov naraz. Ak to „preženiete“, systém je zahltený a výsledkom bývá skôr spomalenie alebo chybové odpovede. Príliš veľké zahltenie v poslednej fáze blokujeme a odblokovanie je prípadne potrebné riešiť s naším supportom.

Preto je dobré s paralelnými dotazmi zaobchádzať opatrne a volania rozkladať šikovne v čase.

Zhrnuté bodovo:

  • Nevytvárajte lavínu paralelných dotazov – môže dôjsť k preťaženiu systému a k blokácii z našej strany.

  • Rozkladajte záťaž a zoskupujte dotazy do logických sekvencií.

  • Pri náročnejších endpointoch (napr. párovanie platieb alebo prepočet dokladov) vyčkajte na odpoveď pred odoslaním ďalšej požiadavky.

Throttling & Retry

Pri komunikácii s API môže dôjsť k situácii, keď server odmietne ďalšie požiadavky, pretože je práve preťažený. Typicky sa to prejaví chybovým kódom 429 – Too Many Requests.

V takej chvíli nie je vhodné okamžite skúšať požiadavku znova, pretože by to záťaž ešte zvýšilo. Správnou praxou je použiť tzv. exponenciálny backoff – teda postupne predlžovať čakaciu dobu medzi ďalšími pokusmi.

  • Ak dostanete chybu 429 alebo server hlási preťaženie, nevykonávajte okamžitý opakovaný pokus.

  • Použite exponenciálny backoff – po každom neúspešnom pokuse predĺžte čakaciu dobu (napr. 1s → 2s → 4s → 8s).

  • Tým dáte systému čas na spracovanie predchádzajúcich požiadaviek a zvýšite šancu, že ďalší pokus uspeje.

Rate limiting

Rešpektujte denný limit počtu dotazov. Východiskový stav sa môže u vašej licencie líšiť podľa zakúpeného objemu.

Počet API požiadaviek

V cene

do 50 000 / deň

do 100 000 / deň

do 200 000 / deň

ABRA Flexi Basic

5000 / deň

nedá sa priplatiť

nedá sa priplatiť

nedá sa priplatiť

ABRA Flexi Business

10000 / deň

1 000 Kč / mesiac

2 500 Kč / mesiac

5 000 Kč / mesiac

ABRA Flexi Premium

20000 / deň

1 000 Kč / mesiac

2 500 Kč / mesiac

5 000 Kč / mesiac

Spoľahlivosť

Práca s chybovými HTTP kódmi

Správne vyhodnocovanie chybových HTTP kódov je kľúčové pre spoľahlivú integráciu. Každý kód má svoj význam a pomáha rozlíšiť, či je problém na strane klienta (nesprávna požiadavka, neplatné dáta, chýbajúce oprávnenie), alebo na strane servera (dočasná nedostupnosť, interná chyba). Vďaka tomu môže aplikácia reagovať správne – buď opraviť dáta a poslať požiadavku znova, alebo počkať a skúsiť akciu neskôr.

  • Rozlišujte chyby 4xx (klientská chyba) – obvykle nesprávna požiadavka, ktorú musíte opraviť (napr. chýbajúci parameter, neplatná hodnota, prístup bez oprávnenia).

  • Rozlišujte chyby 5xx (serverová chyba) – dočasný problém na strane API, je vhodné akciu zopakovať neskôr (napr. výpadok služby).

  • Nastavte alerty na chyby – ak API začne vracať väčšie množstvo 4xx alebo 5xx odpovedí, je nutné o tom vedieť. Na strane klienta sa oplatí takéto situácie logovať a sledovať.

Tabuľka chybových hlásení

Kód

Mapper

Hlásenie

Vysvetlenie

400

NamedUsersLimitExceededExceptionMapper

Vaša licencia neumožňuje vytvoriť užívateľa typu '%p'. Pre úpravu licencie, prosím, kontaktujte obchodné oddelenie ABRA Flexi.

Nemáte voľný prístup pre ďalšieho užívateľa, je nutné dokúpiť licenciu.

400

WSUserEmailDuplicatedExceptionMapper

Tento e-mail už používa iný užívateľ.

E-mailová adresa je už v systéme zaregistrovaná.

400

OldAppServerExceptionMapper

Verzia databázy firmy %p je novšia než verzia servera ABRA Flexi.

Databáza bola vytvorená v novšej verzii systému než váš server.

400

PgRestoreRTExceptionMapper

(obecná správa z výjimky)

Obnova databázy sa nezdarila, systém vracia technickú chybu.

400

QueryExceptionMapper

(obecná správa z výjimky)

Dotaz do databázy je chybný alebo neplatný.

400

UnsupportedOperationExceptionMapper

(obecná správa z výjimky)

Požadovaná operácia nie je v systéme podporovaná.

400

WSAccessDeniedExceptionMapper

K tejto akcii nemáte prístup.

Nemáte oprávnenie na vykonanie akcie.

400

WSApplicationExceptionMapper

(zložené správy z výjimky a ich príčin)

Došlo k aplikačnej chybe, podrobnosti sú uvedené v hlásení.

400

WebApplicationExceptionMapper

Neplatný formát JSON: %p

Dáta majú nesprávny formát a systém ich nedokáže načítať.

400

InternalErrorMapper

(pre WSUserErrorException – obecná správa)

Došlo k užívateľskej chybe v aplikácii.

400

LocalizedBusinessException

Obecná lokalizovaná výjimka

Vyskytla sa obchodná chyba (napr. v nastavení alebo dátach).

400

MissingParameterException

Parameter '%p' is required for requested operation

V požiadavke chýba povinný údaj.

400

IncompatibleParameterValuesException

Parameters %p have incompatible values!

Kombinácia parametrov je neplatná.

400

IllegalParameterFormatException

Parameter '%p' je očakávaný vo formáte '%p'.

Hodnota parametra nie je v správnom formáte.

400

ErrorParsingFileException

Súbor sa nepodarilo prečítať, pretože: '%p'.

Systém nedokázal načítať súbor (chybný obsah alebo formát).

400

UnsupportedParameterValueException

Parameter '%p' has unsupported value! Choose one from following options: %p

Zadaná hodnota nie je podporovaná, vyberte niektorú z povolených.

402

PaymentRequiredExceptionMapper

Funkcia nie je povolená v licencii.

Nemáte licenciu na využitie tejto funkcie.

403

ActionNotSupportedExceptionMapper

Táto akcia tu nie je podporovaná.

Funkcia nie je dostupná v tomto kontexte.

403

LicenseExpiredExceptionMapper

(obecná správa z výjimky)

Platnosť licencie vypršala.

403

NotAuthorizedExceptionMapper

(obecná správa z výjimky)

Nemáte oprávnenie na prístup.

403

UnauthorizedExceptionMapper

(obecná správa z výjimky)

Pokus o prístup bol zamietnutý, chýba oprávnenie.

403

WarrantyExpiredException

Na datovom zdroji sa pokúšate aktualizovať na novšiu verziu systému ABRA Flexi, než vás oprávňuje zaplatená služba Ročná podpora…

Nemáte aktívnu ročnú podporu, ktorá je nutná pre instaláciu novej verzie.

403

CompanyAccessForbiddenException

Do účtovníctva firmy máte zablokovaný vstup.

Nemáte povolený prístup k tejto firme.

404

CompanyNotFoundExceptionMapper

Firma %p neexistuje.

Požadovaná firma nebola nájdená.

404

NotFoundExceptionMapper

Adresa nie je platná. / Adresa %p nie je platná.

URL adresa nie je správna alebo neexistuje.

404

UserNotFoundExceptionMapper

Užívateľ '%p' neexistuje.

Užívateľ nebol nájdený.

404

WSApplicationExceptionMapper

(pre WSObjectNotFoundException)

Požadovaný objekt nebol nájdený.

406

UnsupportedOutputFormatExceptionMapper

(obecná správa z výjimky)

Požadovaný výstupný formát nie je podporovaný.

409

ConcurrentAccessExceptionMapper

(obecná správa z výjimky)

Operáciu nie je možné vykonať, pretože s dátami pracuje niekto iný.

429

TooManyRequestsException

V tejto firme momentálne dochádza k spracovaniu väčšieho počtu skorších požiadaviek, prosím vyčkajte.

Je príliš mnoho požiadaviek naraz, skúste to znova neskôr.

500

InternalErrorMapper

(pre obecné výjimky – obecná správa)

Nastala neočakávaná chyba servera.

500

ResourceNotFoundException

Requested resource '%p' was not found

Požadovaný zdroj nebol nájdený.

503

ServiceUnavailableException

Služba momentálne nie je dostupná, skúste to prosím neskôr.

Služba je dočasne nedostupná, skúste to neskôr.

503

ServerStartingException

Server startuje, prosím vyčkajte.

Server sa spúšťa, je potrebné chvíľu počkať.

503

CompanyStateException

Company '%s' is in '%s' state.

Firma je v inom stave (napr. zamknutá, v údržbe) a nie je možné s ňou pracovať.

Idempotencia

Pri práci so zápismi do API je dôležité zaistiť, aby sa opakovaná požiadavka nespracovala viackrát a nevytvárala duplicity. Typická situácia nastáva pri výpadku spojenia alebo použití strategie retry – klient si nie je istý, či požiadavka prebehla, a odošle ju znova. Bez idempotencie by tak mohlo vzniknúť viac faktúr, objednávok alebo iných dokladov, a to je problém najmä v účtovníctve.

  • Pri zápisoch vždy myslite na to, aby opakovaný request nezaložil duplicitný záznam.

  • Používajte externé ID – pri vytváraní nového záznamu mu priraďte identifikátor zo zdrojovej databázy alebo systému, odkiaľ dáta pochádzajú.

    • Ak sa rovnaká požiadavka odošle znova s rovnakým externým ID, API vráti pôvodný výsledok namiesto vytvorenia duplicity.

Príklad

{
"winstrom":{
"@version":"1.0",
"faktura-vydana":[
{
"id":[
"ext:123",
"code:VF1-0035/21"
],
"popis":"popis"
}
]
}
}

Logovanie requestov a odpovedí

Pri integrácii s REST API je veľmi užitočné uchovávať záznamy o odoslaných požiadavkách a prijatých odpovediach. Vďaka logom môžete rýchlo zistiť, prečo niečo nefunguje, čo API skutočne vrátilo, alebo aká požiadavka bola na server odoslaná. Logovanie je zároveň neoceniteľnou pomôckou pri komunikácii so zákaznickou podporou – namiesto vágneho popisu „niečo sa pokazilo“ máte k dispozícii konkrétne dáta.

Uchovávajte logy všetkých dôležitých requestov a odpovedí

  • Aspoň po obmedzenú dobu, kedy môže byť potrebné zisťovať príčinu problému.

  • Logy vám uľahčia debugovanie chýb a pomôžu zistiť, či problém vznikol na strane klienta alebo servera.

  • Pri riešení so supportom je možné poskytnúť presnú požiadavku a odpoveď, čo značne urýchli hľadanie príčiny.

Konzistencia a verzovanie

API sa v čase vyvíja – pribúdajú nové polia, niekedy sa zmení formát alebo logika odpovede. Ak na to aplikácia nie je pripravená, môže pri zmene prestať fungovať. Preto je dôležité písať integrácie tak, aby boli odolné voči zmenám, a zároveň mať prehľad o vývoji API.

  • Forward compatibility – navrhujte integráciu tak, aby ignorovala neznáme polia a zvládla aj drobné zmeny formátu.

  • Sledujte change-log – pravidelne kontrolujte zmeny API a overujte, či sa nedotýkajú vašej integrácie.

Užívateľská skúsenosť & integrácia

Kvalitná integrácia nie je len o správnom volaní API, ale aj o tom, ako ľahko sa nasadzuje, testuje a udržiava. Oddelenie testovacieho a produkčného prostredia znižuje riziko chýb, rovnako ako správny prístup k zálohám dát – tie je lepšie riešiť cez webové rozhranie než cez API.

  • Testujte na sandboxe – oddeľte testovacie a produkčné prostredie (pomocou zálohy firmy vytvorte kópiu ostrých dát), aby ste neohrozili reálne dáta.

  • Nepoužívajte API na zálohy v cloude – automatické zálohy stahujte z webovej aplikácie, API na to nie je primárne určené.

Monitoring a správa

Bez priebežného prehľadu o tom, koľko a ako často API volajte, sa problémy odhaľujú neskoro. Základný monitoring vám pomôže sledovať limity, ladiť výkon a predchádzať výpadkom integrácie.

Záver

Dodržiavanie osvedčených postupov pri práci s REST API ABRA Flexi vám pomôže stavať stabilné, bezpečné a dlhodobo udržateľné integrácie. Či už ide o optimalizáciu dotazov, správu chybových stavov alebo bezpečné zaobchádzanie s prístupovými údajmi, vždy sa oplatí investovať do správneho návrhu už od začiatku.

Ak si nie ste istí, ako API využiť vo vašom konkrétnom scenári, alebo potrebujete detailnejšie odporúčanie, je možné dohodnúť individuálnu konzultáciu, kde vám s implementáciou rady pomôžeme.

Ste s tem dobili odgovor na svoje vprašanje?