Mezi časté chyby patří testování reducí přes celý store, což zbytečně zapojuje middleware a komplikuje ladění. Dále se stává, že testeři zapomenou na asynchronní povahu thunků a test skončí dřív, než se dispatch dokončí – vždy počkejte na promise. Také se vyplatí testovat akce, které používají getState, protože můžete snadno přehlédnout závislost na konkrétním stavu. Vždy si připravte mock getState s přesně tím stavem, který akce očekává, a ověřte, že z něj správně čte.<br>
<br>
<br>
<br>
Nejdříve si vyberte nástroj, kterým budete API testovat. Můžete použít přímo příkazovou řádku a nástroj pro odesílání HTTP požadavků, ale pro začátek je pohodlnější grafický program, který vám ukáže odpověď v přehledné podobě. Stačí zadat adresu (endpoint) a zvolit metodu, obvykle GET pro čtení dat. Zkuste najít veřejné API, které vrací aktuální čas, počasí nebo seznam zemí. Cílem je vidět první odpověď ve formátu JSON – to je textová struktura, kterou snadno přečte nejen člověk, ale i program.<br>
<br>
<br>
<br>
<span style="font-weight: 800;">Při výběru se tedy řiďte</span> třemi kritérii: složitost dat, potřeba flexibility a zkušenosti týmu. Pokud je váš tým zvyklý na SQL a má rád strukturu, GraphQL mu sedne. Pokud preferujete jednoduchost a jistotu, zvolte REST. Můžete také kombinovat obojí – použít REST pro veřejné API a GraphQL pro interní aplikace. Důležité je vyhnout se tomu, abyste GraphQL použili jen proto, že je moderní, bez jasného důvodu. Vždy měřte výkon a zátěž, ať se rozhodnete jakkoli.<br>
<br>
<br>
<br>
Reducery testujte jako čisté funkce Reducer je čistá funkce, která na základě aktuálního stavu a akce vrací nový stav. To je ideální pro unit testy – nepotřebujete žádný store ani middleware. Stačí volat reducer s konkrétním stavem a akcí a porovnat výsledek. Důležité je připravit si výchozí stav (initial state) a otestovat nejen úspěšné scénáře, ale i okrajové případy, jako je neznámá akce, prázdný stav nebo immutable update. Typickou chybou je spoléhat na to, že reducer nesmí mutovat původní stav – pokud to porušíte, test to odhalí. Proto vždy používejte spread operátor nebo jiný neměnný způsob aktualizace.<br>
<br>
<br>
<br>
<img src="https://www.freepixels.com/class=" style="max-width:450px;float:left;padding:10px 10px 10px 0px;border:0px;">REST funguje na principu zdrojů a HTTP metod. Každý zdroj má svou URL a klient si načte data pomocí GET, POST, PUT nebo DELETE. Typický problém nastává, když potřebujete data z více zdrojů najednou – musíte volat několik endpointů a výsledky skládat na klientovi. To vede k přenosu zbytečných dat a pomalejší odezvě. Řešením je buď zavést specifické endpointy pro agregaci, nebo použít GraphQL, který dotaz umožňuje sestavit tak, aby server vrátil přesně to, co klient potřebuje.<br>
<br>
<br>
<br>
Při výběru se zaměřte také na to, jak snadno lze prostředí rozšířit. Potřebujete-li podporu pro jiné jazyky nebo nástroje, zkontrolujte, zda existují oficiální pluginy. Vyhněte se ale instalování desítek rozšíření hned na začátku, protože každé z nich zpomaluje start a může způsobovat konflikty. Začněte s minimem a přidávejte jen to, co skutečně využíváte. Ušetříte si starosti s nekompatibilitou a přehlednost si udržíte i ve složitějších projektech.<br>
<br>
<br>
<br>
JWT tokeny se staly standardem pro autentizaci API, ale jejich nasazení skýtá mnoho úskalí. Nejde jen o podepsání tokenu a jeho odeslání klientovi. Pokud chcete, aby vaše API bylo skutečně bezpečné, musíte důkladně zvážit, kde tokeny ukládat, jak dlouho je nechat platné a co všechno do nich vložit. Tento článek vás provede praktickými kroky i častými chybami, kterým se vyhnout.<br>
<br>
<br>
<br>
REST je ideální, když máte jednoduchou hierarchii zdrojů a klienti potřebují standardizovaný přístup. Například veřejné API pro třetí strany – zde je důležité, aby bylo snadno pochopitelné a stabilní. S GraphQL byste museli dokumentovat schéma a řešit složité dotazy, což může být pro externí vývojáře nepřehledné. Také pokud používáte HTTP metody pro akce, jako je mazání nebo aktualizace, REST poskytuje jasnou sémantiku, která se snadno testuje a monitoruje.<br>
<br>
<br>
<br>
Při tvorbě payloadu vkládejte pouze nezbytné údaje, jako je identifikátor uživatele, role a případně čas vydání. Nikdy do tokenu neukládejte citlivá data, jako jsou hesla nebo platební údaje. Pamatujte, že JWT je podepsaný a zakódovaný, ale ne šifrovaný – kdokoli s tokenem si může jeho obsah přečíst. Pokud potřebujete přenášet citlivé informace, zvažte šifrování celého tokenu, ale to komplikuje validaci a není to běžný postup.<br>
<br>
<br>
<br>
Nasazení JWT není složité, ale vyžaduje pečlivost. Začněte s krátkou dobou platnosti, použijte bezpečný algoritmus, striktně validujte všechny náležitosti tokenu a věnujte pozornost úložišti na straně klienta. Testujte své API proti běžným útokům, jako je pozměnění tokenu nebo opětovné použití odcizeného tokenu. Jen tak zajistíte, že vaše autentizace bude skutečně spolehlivá a vaše data zůstanou v bezpečí.
