Moderní API již není jen pro startupy

01. 06. 2017

Jak tvořit moderní rozhraní pro online sběr dat? To se dozvíte se v článku Vítězslava Košiny, IT Consultanta ve společnosti IBA CZ.

Moderní API již není jen pro startupy

Existuje stále větší množství služeb více či méně sbírajících různé druhy dat, které následně otevřeně nebo i skrytě monetizují. Prakticky je spíše nelehký úkol najít aplikaci, která o nás něco nesbírá. Znamená to tedy, že technologie, jež relativně neinvazivně sesbírají data i v rámci různých zařízení, existují a jsou plošně rozší- řené i běžně používané. A pak tu máme jeden velmi zajímavý paradox.Pokud se pro sběr dat rozhodne jaká- koliv instituce, je takové rozhodnutí provázeno mediální kanonádou a výsledný „produkt“ ve většině případů bývá poměrně obskurní. Rozebírat u takového řešení něco, jako je uživatelská přívětivost, je již většinou mimo jakýkoliv rámec. 

 

Jak je tedy možné, že existují dva extrémy? Na jedné straně jsou tu komerční subjekty, které dokážou v řádu jednotek týdnů připravit a nasadit funkční řešení pro sběr dat. A na druhé straně pak mediální humbuk v řádu měsíců okolo každého sběru dat v nějaké instituci, jehož výsledkem bývá různě funkční řešení. Ale vždy ho předchází nelichotivé PR a téměř výhradně negativní reakce uživatelů. Důvod je nasnadě. V myšlení mnoha lidí stále přetrvává rigidní uvažování. S jakoukoliv institucí se přece komunikuje přes formulář a zároveň formulář musí být dostatečně složitý na to, aby v uživateli nebudil dojem, že se jedná jen o nějakou drobnost. Současně se sbírají informace, o kterých se uživatel může oprávněně domnívat, že se sbírají opakovaně nebo mohou být případně zneužity.

 

Můžete namítat, že někdy je potřeba více informací, nicméně toto je pohled z praxe. Kolik údajů, které jsou v rámci formuláře sebrány, představuje skutečnou datovou podstatu formuláře? Pokud si na tuto otázku odpovíte, zjistíte, že v mnoha případech to není většina. A to jsem stále na straně uživatelů. Větší zábava nastane, když se do toho vloží IT specialisté, protože pak se kromě „formulářového“ rozměru, který vnímá běžný uživatel, dostaneme do rozměru technologií. A zde se kreativitě meze nekladou. Typické rozhraní pro sběr dat má v zásadě umět především čtyři základní operace s daty, a to založení, změnu, načtení a zrušení.

Velmi často se setkáváme s tím, že jsou publikovány další zajímavé funkcionality, ale výše zmíněné základní funkce jsou implementovány jen částečně nebo některé vůbec. Ale pryč z abstraktní roviny. Vezměme jednoduchý a velmi rozšířený příklad, kdy zákon ukládá povinnost sbírat vybraná data pro provádění dozorové činnosti. Pro začátek si vystačíme s tím, že si položky, které nás opravdu zajímají, tzn. jsou podstatné pro výkon zmiňované povinnosti, sepíšeme do oblíbeného nástroje, jako je například Excel nebo podobný tabulkový procesor. Velmi důležité je rozlišit (např. barvou), které položky jsou ty zásadní, tzn. nejde je vzít z již existujícího zdroje, a ty, které jsou pomocné. Uveďme příklad. Mám identifikovat firmu a opravdu mi bude stačit IČO nebo jiný podobný identifikátor a jistě není potřeba si pro jistotu ještě nechat poslat adresu a další údaje. Budete překvapeni, kolik skutečně relevantních údajů nakonec budete sbírat. Vzápětí je potřeba si určit formát dat.

 

Přijde mi až úsměvné, že specifikace různých rozhraní např. u čísel vyžaduje povinně dvě desetinná místa, přestože většina údajů v této položce přijde téměř jistě vždy jako celé číslo. Stejně tak o kvalitě návrhu nesvědčí časté opakování datového pole, kam lze napsat libovolný text, který více specifikuje detail. Nevěřím tomu, že to snad někdo v budoucnu bude dále zpracovávat. A dalo by se pokračovat. Pokud máme návrh, co tedy chceme sebrat, je potřeba se vždy oprostit od uvažování ve stylu „a ještě přidáme nepovinnou položku“. Nepovinná položka je to samé jako žádná položka a pouze to ukazuje na další lidovou tvořivost. A teď už přichází na řadu technologie.

 

Již několik let jsou zde predikce od renomovaných agentur, jako je Gartner, o tom, že mobilní zařízení v použití předeženou desktopy. Ačkoliv se tyto předpovědi naplňují, v implementaci mnoha rozšíření se to příliš neodráží. Máme zde dvě roviny. Jednak rovinu uživatelskou a zde se stačí podívat, kolik existuje uživatelských rozhraní, která jsou udělána dle filozofie „Mobile first“ nebo ještě lépe „Offline first“ nebo jsou alespoň použitelná na mobilních zařízeních. To je klíčové pro formuláře, které jsou interaktivní. A pak tu máme automatizovaná rozhraní pro sběr dat, tedy API.

 

Zde je situace malinko odlišná. Podstatné je, zda se jedná o rozhraní pro sběr dat, nebo spíše interní integrační rozhraní, protože každé je něco jiného a jistě bude vhodné i podle toho volit technologie. Tento příspěvek se týká API, tedy rozhraní určených primárně pro sběr dat. Obsah každé takové zprávy má v zásadě dvě části, z nichž povinná je část týkající se vlastních dat a nepovinná pak část, která data zabezpečuje např. pomocí elektronického podpisu. Je maximálně výhodné, pokud máte data v takovém tvaru, že vám je dokáže vytvářet i interpretovat jak mobilní nebo webová aplikace, tak i program ve většině programovacích jazyků bez přidání významné pracnosti. A současně se nejedná o proprietární technologii, která vás sváže s konkrétním výrobcem a jeho postupy. Zmínil jsem mobilní zařízení, ale platí to obecně. Méně je více, tzn. nepřenášíme, co není nezbytně nutné, a to, co přenášíme, pak v základním tvaru (tzn. bez formátování apod.).

 

U rozhraní většinou potřebujeme výše uvedené čtyři základní operace a můžeme směle přejít k technologii. Technologii zvolíme tak, aby jedna byla samodokumentující se, tzn. už z definice je i ne-IT specialistovi jasné, jaká data se budou sbírat, a současně vznikne něco jako referenční klient. Situace, kdy se publikuje PDF dokument a k tomu definiční soubor, kterému rozumí pouze IT specialisté, je stále velmi oblíbený vzor specifikace rozhraní. Nicméně krom toho, že nahrává softwarovým firmám, konečnému uživateli nic nepřináší. V roce 2017 bych spíše očekával rozhraní, které má implementovaného referenčního klienta s otevřeným zdrojovým kódem nebo ještě lépe je celé implementováno jako otevřená technologie. Nicméně to by znamenalo, že technologie se vybírá podle požadavků rozhraní a uživatelů, a nikoliv že rozhraní a uživatelé se ohýbají do konkrétní, již dříve vysoutěžené technologie, kterou je potřeba z různých důvodů použít. A tak se dostáváme k praktické realizaci.

 

Ukázkové rozhraní je typicky REST API, které přenáší data zabezpečeným tunelem, přičemž je možné současně u dat ověřit autenticitu a integritu např. pomocí elektronického podpisu. Zároveň je možno použít již lepší metody zabezpečení než zadávat jméno a heslo. Takové rozhraní je schopno data konzumovat jak z webové formulářové aplikace, tak i programově ze služeb běžících na serveru. A samozřejmě bude škálovatelné třeba i na desítky tisíc požadavků za vteřinu bez „enterprise“ licencí a věci jako vysoká dostupnost a opensource implementace jsou samozřejmost bez dalších dodatečných ná- kladů. Přijďte se tedy podívat na naši ukázku…

 

 

Přečtěte si více
Zpět na seznam aktualit