API v roce 2021 aneb světa stav

Pozadí článku

Nejprve bych rád vymezil pro tento článek určité mantinely. Jsem nezávislý konzultant a mé služby poskytuji výhradně českým a slovenským klientům, kteří programují (mimo jiné) na platformě .NET. Klienti vytváří zejména webové a mobilní aplikace, desktop aplikace ve WinForms a různá API. Proti tomu vycházím z různých anket z let 2019 až 2021, které publikoval Google, Postman, Smartbear a další. Roky si vybírám záměrně za účelem porovnání trendů. Anket se zúčastnili zhruba ze tří čtvrtin vývojáři, zbytek je pak mix manažerů, architektů, analytiků a dalších rolí.

REST API ovládla svět

API je velmi obecný pojem, pod který se dá schovat ledacos. Průřez vývojářským světem napoví, že přes 90 % vývojářů má zkušenosti s vývojem REST API. Můžeme se jen dohadovat o tom, zda je to "pure REST" nebo jen HTTP API. Přístupy jako SOAP nebo WebSockets jsou spíše na ústupu a velkým tématem se stává (opět) GraphQL. Roky 2020 a 2021 byly ve znamení pandemie COVID-19, která významně urychlila digitální transformaci a vývojářské dílny se shodují, že do oblasti integrace a inovace API soustředí větší množství finančních prostředků. Největší růst v této oblasti zaznamenalo zejména zdravotnictví a s velkým odstupem finanční služby. Firmy vytváří především nové produkty, což otevírá vývojářským týmům možnost stavit aplikace novým a modernějším způsobem. Domnívám se proto, že s rostoucím počtem nově vznikajících řešení vzrostla i potřeba po efektivním dynamickém dotazování. Dnes už více než tři čtvrtiny profesionálů věří, že GraphQL se stane dominantním jazykem ve scénářích, kdy vývojářský tým potřebuje dynamické dotazování na data. Má to samozřejmě svá úskalí, která si týmy uvědomují. Stále chybí zejména dostatek zkušeností v týmech. To má za následek kromě pomalejší produkce API i určitá rizika, že konzumenti si s připraveným rozhraním nebudou umět poradit.

Specifické místo si ve světě aplikačních rozhraní hledá technologie gRPC. Ta se sice vyšvihla v četnosti použití před exotické AMQP, MQTT a jiné protokoly, stále je však spíše minoritní technologií. To se pravděpodobně změní v dalších letech, kdy též poroste potřeba propojování digitálních produktů, které v tuto chvíli teprve vznikají. Firmy navíc projevují chuť svá API monetizovat a GRPC mají potenciál zpřístupnit data velmi efektivním způsobem. To je něco, co REST API přes svou rozšířenost neumí. S přesunem firem do cloudu a s ohledem na adopci SaaS produktů navíc mnoho firem hasí na poslední chvíli oheň na střeše. Nástroje a rozšíření různých on-premise aplikací totiž najednou musí suplovat různé integrační moduly, které se starají o přelévání dat z místa na místo. I zde hraje velkou roli pandemie COVID-19, která uzavřela zaměstnance doma a donutila tak firmy migrovat do cloudu a SaaS služeb, aby umožnila svým zaměstnancům práci na dálku. Vzhledem k tomu, že většina těchto systémů vznikala v letech "éry RESTu", je logické, že právě REST je výchozí a často jedinou volbou integrace. V závěsu pak můžeme ještě zmínit webhooky, které komunikaci mezi službami usnadňují. Webhooky jsou zároveň jednoznačně nejoblíbenější přístup co se distribuce událostí týče. Používá je dvojnásobek vývojářů oproti websocketům či long-pollingu. České prostředí v zásadě nevybočuje z výše uvedených standardů.

Vládci světa na prvním místě

Pojem API First není v našich končinách vývojářům .NET platformy příliš známý, přestože tuto strategii první pionýři oslavovali před více než 6 lety. Jestliže jsou REST API tolik rozšířená a tolik potřebná, měla by se stát středobodem vývojářského vesmíru. Nejsnazší interpretací API First je záměr o vytvoření API před klientskou částí, tedy například webovou nebo mobilní aplikací. Je-li API středobodem vesmíru, pak by mělo být univerzálně integrovatelné různými klienty. Bohužel se podle výzkumů ukazuje, že toto chápání sdílí jen třetina vývojářů. Druhá třetina vnímá API First spíše jako Design First. Není to nutně špatně, avšak potřeba specifikace je jen důsledek potřeby mít API jako hlavní "první" produkt. Celosvětově více než třetina vývojářů navíc design API buď vůbec neřeší, nebo se o něj začne zajímat až během vývoje, tedy typicky když už začne probíhat integrace a klienti si stěžují. Situace se každým rokem lepší a o směrování k API First přístupu není pochyb.

V Čechách je situace výrazně horší. API z mé zkušenosti vznikají velmi neorganizovaně s cílem uspokojit jednu cílovou potřebu. Vývojáři rychle sestavují API pro jeden specifický účel spíše než jako univerzálně integrovatelnou službu. O vývoji moderních API chybí v naší zemi povědomí. Nemáme specializované konference, meetupy ani jiné druhy akcí a trpíme extrémním nedostatkem odborníků. Platforma .NET byla dlouhé roky zaháčkovaná na MVC a staticky generovaných stránkách, zatímco konkurence již dlouhou dobu žije JS frameworky, RESTful API a GraphQL. Microsoft této situaci navíc příliš nepomáhá a prosazuje svůj vlastní produkt postavený na technologii web assembly, která se zrovna příliš velké oblibě netěší. Nejlepší práci ve finále odvádějí větší vývojářské týmy a instituce jako banky, pojišťovny či technologické startupy. Úplně pozadu není například ani iniciativa Otevřená data v ČR, která poskytuje data v relativně jednotné formě za podpory JSON-LD notace. Horší situace je především se staršími systémy jednotlivých resortů.

Bída ve vzdělávání

Vzdělávání je obecně ve vývojářské profesy velký problém. Více než polovina vývojářských týmů uvádí jako hlavní překážky pro vývoj API nedostatek času, znalostí nebo lidí. Přitom pro tři čtvrtiny vývojářů jsou právě kolegové hlavním zdrojem získávání nových znalostí a zkušeností. Potíž vidím zejména ve full-stackových pozicích, které kladou velké nároky na množství znalostí. Vývojář nemá šanci naučit se dostatečně všechny technologie, jelikož ty se mu pod rukami neustále mění. Ať už na straně serveru nebo klienta se po pěti letech změní trendy i velká část vývojářských technologií. Mnohdy je tak vývojář nucen spravovat vedle moderně vytvářených aplikací i několik generací zastaralých aplikací postavených na starších technologiích. Celému oboru by jednoznačně prospěla užší specializace vývojářů na jednotlivé oblasti vývoje a sdílení specializovaných kapacit formou nezávislého poradenství.

Vzhledem k nízké míře evangelizace v oblasti modernizace API do Česka navíc prosakují jen zvučné zahraniční trendy, které zde nefungují. Dobrým příkladem jsou aplikace stavěné na mikroservisní architektuře, která dobře funguje nadnárodním gigantům a velkým týmům vytvářejícím rozsáhlá a mimořádně vytížená řešení s potřebou škálování nebo technologické diverzifikace. Když tyto trendy přejímají malé české týmy při stavbě relativně jednoduchých green-field projektů, kladou na sebe v podstatě jen další zbytečné výzvy. Typická microservices architektura s sebou vnese do týmu řadu dalších technologií, které už není v silách týmu adoptovat. Problém je, že microservices, kubernetes nebo kontejnerizace jsou pouze lákadla, které vývojáře dle anket spíše jen zajímají a mají chuť si je vyzkoušet. Manažeři nakonec podléhají v honbě za KPI falešným nadějím, že zavlečením podobných trendů pomohou postavit lepší a odolnější řešení. Microservices nejsou nicméně trend, který by dávalo smysl bezmyšlenkovitě aplikovat v každém prostředí.

Jak se staví dobré API

O přístupu API First jsem se již zmínil a hledá-li vývojářský tým cestu k vytvoření univerzálního REST API, jedná se o jedinou možnou cestu k úspěchu. Z logiky věci staví API do středu zájmu a v kombinaci s Design First přístupem v podstatě uspokojuje potřebu všech reálných i potenciálních klientů. Vzhledem k tomu, že od momentu integrace jsou zpětně nekompatibilní změny vždy nákladné a často i nemožné, je nezbytné zvolit si správné nástroje pro návrh API. Absolutně nejrozšířenější specifikací je v současné době Open API Specifikace společně se starší verzí Swagger Specification. Používají ji zhruba tři čtvrtiny projektů. Logicky druhá velmi rozšířená varianta je jazyk GraphQL, který je zároveň i specifikací. GraphQL zde však není proto, aby REST API nahradil, ale zasuploval je ve specifických případech. Async API vznikající vedle Open API Specifikace pro návrh asynchronních API se dlouhodobě netěší oblibě a využívají ji jen zhruba 4 % vývojářů.

Jednoznačně nejrozšířenější nástroj pomáhající s vývojem REST API je Postman. Používá ho více než 9 z 10 vývojářů. Čtvrtina vývojářů včetně mě jej obvykle kombinuje se SwaggerHubem. Z mé zkušenosti je situace v naší zemi velmi podobná. Potíž vnímám v tom, že potenciál Postmanu většina vývojářů využívá jen z malé části. O jeho rozsáhlých možnostech přitom vypovídá fakt, že má svou vlastní specializovanou konferenci Postman Galaxy.

Situace se výrazně lepší v oblasti nasazování aplikací. Výrazně ubývá projektů nasazovaných manuálně a automatizace proniká do většiny vývojářských týmů. Číslem jedna v oblasti CI/CD je díky akvizici GitHubu jednoznačně Microsoft s AzureDevops a GitHub Actions. Z pohledu samostatně stojících produktů však stále vede Jenkins, který používá více než 40 % vývojářů a AWS Devops, který se těší oblibě u každého třetího vývojáře. V českém prostředí oblíbený TeamCity se celosvětově téměř nepoužívá. Technologie Microsoftu mají velmi výhodnou pozici, jelikož dnes pokrývají prakticky kompletní proces vývoje aplikací na .NET platformě. Přesto mají vývojáři v českém prostředí zbytečný strach z vendor locku a vydávají se cestou slepenice různých open-source řešení. Jednotlivé produkty Microsoftu do sebe dobře a snadno pasují, což je velká výhoda, které se vývojáři občas zbytečně vzdávají.

Vývojář vs. konzument

Nejen nástroje tvoří dobré API. Zde se zásadně rozchází představy managementu, vývojářů a konzumentů. Co naplat, že ve dvou posledních případech může být v jedné roli tatáž osoba. Management se snaží najít jednoduše měřitelná čísla. Klade si otázku, jaká je dostupnost, kolik volání jde proti API, kolik se odbavilo issues, kolik má API integrovaných klientů a jaký je počet nových účtů nebo jaký plyne z integrací příjem. V lepším případě může sledovat i výkonnost, je-li za ní nějaký ten graf. Vnímání vývojářů se soustředí na kód. Vývojář chce mít API pěkně napsané, chce si na něm vyzkoušet nové technologie a vlastně se spíše při práci potřebuje pobavit. Když se vývojář přepne do role konzumenta, najednou je jeho preferencí zejména výkonnost, použitelnost a kvalitní dokumentace. Najít zde rovnováhu není snadné, jelikož každá role má zcela jiné představy o dobrém API.

Dokumentace

Dokumentace má obecně zvláštní postavení. Vývojáři ji obvykle nechtějí vytvářet a když už ji vytvořit musí, hledají co nejrychlejší řešení, které za ně udělá všechnu tu "špinavou práci". Z pohledu konzumenta se každý druhý vývojář přitom shoduje, že nedostatečná dokumentace je největší překážkou konzumace API. Podle průzkumů je dokumentace jiných REST API druhým nejčastějším zdrojem vzdělávání a inspirace. Při konzumaci dokumentace vývojáři vyžadují smysluplné ukázky, doplňující informace k použití endpointů, popis workflow a pokrytí vhodným standardem. Překvapivé je, že jen pětina vývojářů uvítá k API použitelné SDK nebo jiné nástroje pro usnadnění práce. Strategie "napíšu si sám" zde hraje stále prim a koresponduje se zmíněným prvkem vývojářské zábavy i za cenu znovuvynalézání kola.

Testování API

V českém prostředí .NETu se testování REST API moc velké oblibě netěší. Ze své zkušenosti v různých týmech i z hlediska poptávky po školení testování REST API zde vnímám rozkol se světovými průzkumy. Podle nich tráví téměř polovina vývojářů pracovní čas psaním automatizovaných testů a třetina si se svými kolegy pravidelně vyměňuje code-review. A není se čemu divit. Většinu času přeci vývojáři tráví psaním business logiky a implementací workflow, ve kterých se skrývá nejvíce chyb. Jednoznačně nejrozšířenější jsou na projektech jednotkové a integrační testy. Právě integrační testy se v novém .NETu píšou velmi snadno a zůstává mi záhadou, proč v řešeních českých vývojářů tak často chybí. Z pohledu API dále téměř každý druhý vývojář provádí i určitou formu performance testů. Představy o měření výkonnosti se nicméně u vývojářů poněkud rozchází.

V návaznosti na testování se sluší zmínit i otázku zabezpečení. To nebylo doposud totiž prioritou vývojářů ani manažerů. Formu bezpečnostních testů provádí sotva pětina vývojářských týmů. Nutno poznamenat, že otázka zabezpečení často netrápí ani konečné konzumenty či spotřebitele. Neviditelné hrozby jednoduše nejsou hrozbou a otázka zabezpečení tak přijde na pořad dne, až když se něco skutečně začne dít. Útěchou nám může být alespoň snaha vývojářů opouštět vlastní obskurní implementace zabezpečení, posílání všemožných API klíčů a rostoucí adopce mechanismů jako OAuth 2.

Závěr na(d) závěr

Z vyjádření firem lze očekávat, že firmy budou i nadále otevírat svá interní API a pokračovat v adopci SaaS řešení, hybridních cloudů a samozřejmě expandovat do nových regionů. Mezi priority pro rok 2022 se podle průzkumů dostává i opomíjená oblast zabezpečení. Mnoho společností bude své investice do vývoje REST API chtít zúročit, což se odrazí na rostoucí chuti API monetizovat. Lze očekávat, že API se stanou v budoucnu snadněji integrovatelná pomocí no-code nástrojů a standardizaci. V dalších letech lze též očekávat pronikání AI a ML do procesu integrace.

Vývojáři ve světě jsou sebevědomí, pokud jde o hodnocení svých vlastních kvalit. Pokud bychom jim věřili, byla by to špatná zpráva pro naše české prostředí. Typický český vývojář je zahlcený příliš velkým množstvím úkolů a nemá dostatek času na vzdělávání. Když už čas na vzdělávání vznikne, často je vývojář sveden na špatnou cestu a věnuje energii prosakujícím buzzwordům, které v zásadě nemají pro něj ani pro tým přínos. API stále vznikají spíše chaoticky než na základě navržené specifikace. Vývojáři si též často neuvědomují, že API jsou produkt. Zaslouží si řádně otestovat a opatřit kvalitním manuálem tak, jako jakýkoliv jiný produkt, který si nosíme z balíkoven domů.

Zdroje: 2020 State of the API Report (Postman), The state of API Integration Report 2021 (Cloud Elements), State of API Economy 2021 Report (Google), The State of API 2019 (Smartbear)