Běžné chyby API a jak je opravit

Při vytváření jakéhokoli softwaru, ať už jde o webovou stránku nebo aplikaci, je nutné zahrnout zajištění kvality do vašeho cyklu vývoje softwaru. Pokud je zmeškáte, existuje vysoká šance na vydání chybných instancí, které jistě zkazí zážitek koncového uživatele.

Žádná zúčastněná strana by si nikdy nepřála, aby se to stalo. To je důvod, proč testování zůstává ve střehu pro úspěšná vydání a zajišťuje pozitivní odezvu na funkce, které přidáte. To zahrnuje nejběžnější scénáře případu použití k ověření, že toky fungují podle očekávání, než bude mít kdokoli z vašich skutečných zákazníků příležitost to zkontrolovat.

Při zvažování, jaké testy zahrnout do sady pokrytí, věnujte pozornost testování API, protože je to jeden z nejdůležitějších a nejpoužívanějších typů. API (Application Programming Interfaces) jsou přítomna v každé aplikaci a jsou zodpovědná za správnou komunikaci mezi několika softwarovými systémy. Mezi hlavní funkce API patří specifikování požadavků na data, které lze přenášet, a podmínek pro zpracování těchto požadavků. 

Například uživatel chce přidat nějakou položku do košíku, stiskne odpovídající tlačítko, které spustí požadavek API, obdrží odpověď a košík se aktualizuje. Pokud tento požadavek selže, funkce „přidat do košíku“ se přeruší.

Takto mohou problémy s API ovlivnit podnikání a přidat ještě jeden důležitý faktor, proč by jej měl každý řádně otestovat. Chcete-li začlenit toto testování, měli byste začít se správnými testovacími nástroji pro automatizační rozhraní API , abyste se ujistili, že neproklouzne žádná chyba.

Mohou existovat různé chyby API a zde vám řekneme více o 5 nejoblíbenějších: 

Nesprávná metoda HTTP

Nejjednodušší, ale široce rozšířenou chybou API je nesprávná metoda HTTP. Problém je často způsoben mezerami v dokumentaci. Jedním z příkladů může být odeslání požadavku GET specifikující možnost data, ale přeskočte zmínku o parametru -X GET. V důsledku toho se automaticky převede na požadavek POST. Problémy s metodami HTTP mohou také nastat při přepínání nástrojů API, protože některé z nich mohou používat jednu metodu pro vytváření testovacích prostředí a jejich úpravy, zatímco jiné pro tyto akce používají odlišné způsoby. Proto je důležité pečlivě zkontrolovat tyto nuance a také přijmout konzistentní přístup k psaní vlastní dokumentace. 

Používáte nesprávný protokol

Další častou chybou jsou nesrovnalosti mezi protokoly https:// a http://. Některá API mohou podporovat pouze jeden z protokolů, řekněme http, takže zadání https:// v takovém případě povede k nesprávnému zpracování požadavku. I když jsou podporovány oba, mohou nastat problémy s přesměrováním na https://, když zadáte http://. Tento případ může také nastat, když poskytovatelé API třetích stran, které plánujete použít, provedou nějaké změny a nepodaří se jim o tom odeslat upozornění. Je tedy lepší tyto aspekty čas od času znovu zkontrolovat. Pro vytvoření vlastního API je lepší použít protokol https://. Aby to bylo možné, je nutné nainstalovat SSL certifikátk hostiteli. Před časem byly certifikáty SSL trochu drahé, takže o tom mohly být pochybnosti, ale s bezplatnými poskytovateli, jako jsou Letsencrypt nebo Cloudflare, je to jednodušší než kdy jindy.

Absence smysluplných chybových zpráv

Pokud jste někdy čelili neočekávané chybě API“, víte, jak nepříjemné to může být. Obvykle mají chybové zprávy usnadnit vývojářům řešení problémů a upozornit na přesný důvod chyby nebo alespoň kde ji hledat. Bohužel takové neinformativní chyby mohou mít za následek hodiny promarněného času, prodloužit čas potřebný k vyřešení chyby a následně způsobit větší nárůst negativní zpětné vazby, kterou dostáváte, a proto je lepší věnovat trochu více času popisu potenciálu chyby a učinit zprávy informativní pro ty, kteří je budou muset odstraňovat. Přestože existuje několik desítek chybových kódů HTTP, není nutné je používat všechny, ale ponechte si standardní chybové kódy (200 400 a 500) a zvažte zahrnutí nápověd do zpráv, aby i v případech, kdy něco nefunguje,

Problém s autorizací

Může se zdát, že zde je vše jasné, protože chybná autorizace obvykle předpokládá nesprávné uživatelské jméno nebo heslo, ale ve skutečnosti i záměna „autorizace“ s „autentizací“ v hlavičkách způsobuje chybu. Platí to zejména při použití protokolu OAuth 2. Na syntaxi také záleží, protože některé jednoduché, ale méně zřejmé věci mohou způsobit zmatek. Ve většině případů se jedná o token nositele, mezeru v předponě „Základní “, která chybí k úplnému přidání této předpony, a ztrátu dvojtečky v páru „uživatelské jméno: heslo“. I když se uživatelské jméno používá samostatně v některých rozhraních API, která nevyžadují heslo, budete stále muset použít tuto dvojtečku.

Selhání určení záhlaví Content-Type a Accept

Některá rozhraní API jsou tolerantní k požadavkům, kde hlavičky neobsahují Content-Type nebo Accept hlavičku, ale odpovídají povolenému formátu dat. Jiní jsou svědomitější a nenechají požadavek projít rozdáním chybového kódu 403 Povolení odepřeno. V této fázi je navázána interakce mezi klientem a serverem ohledně očekávaného datového typu v požadavku a odpovědi. Tato kontrola hlaviček je implementována pro snížení rizika narušení bezpečnosti a celkových pokusů o hackování, proto je lepší tyto hlavičky specifikovat, aby se předešlo problémům při používání.

Zabalit

Provádění testování API spolu s dalšími typy testování včetně regrese, kouřového testu a samozřejmě testování jednotek během vývojových sprintů pomůže k rychlejšímu vydání vašeho softwaru. Logika za tím je jednoduchá: čím dříve je chyba, defekt nebo nesoulad s obchodními požadavky zaznamenán, tím snazší je opravit ji. A ve výsledku dopřejte svým koncovým uživatelům prvotřídní zážitek, kteří si budou moci užít interakci s vaším softwarem bez neočekávaných chyb v procesu, což vaší firmě přinese větší zisk.