Co musí umět vaše API, než začneme stavět aplikaci

Přihlášení, přístup k datům, oprávnění a správce backendu: co potřebuje stávající produkt, než na něm vznikne mobilní aplikace, a co když API nestačí.

Než se na existujícím produktu začne stavět mobilní aplikace, musí platit tři věci: API pokrývá úkoly, které bude aplikace dělat, uživatelé se mohou přihlásit způsobem, který v telefonu funguje, a na vaší straně je člověk, který backend zná a může ho upravit. Pokud API nestačí, nejde o slepou uličku, ale o otázku rozsahu. Pro konkrétní projekt lze probrat backend pro aplikaci, který slouží aplikaci, ale váš produkt nenahrazuje ani nepřestavuje.

V článku projdeme, na co se ptáme, než začneme stavět na systému klienta, a proč na každé otázce záleží. Stručnější verzi stejných otázek najdete na stránce vývoj mobilních aplikací.

Začněte úkoly, ne endpointy

Jestli je API „připravené“, se dá posoudit jen podle toho, co má aplikace dělat. Seznam endpointů sám o sobě mnoho neřekne, seznam úkolů ano. Sepište tři až pět věcí, které musí uživatel v první verzi zvládnout, například zkontrolovat zůstatek na účtu, schválit požadavek nebo zapsat servisní návštěvu. Potom každou z nich porovnejte s tím, co API umí.

U každého úkolu se zeptejte:

• Získá aplikace data pro danou obrazovku jedním nebo několika požadavky, aniž by stahovala mnohem víc, než zobrazí?
• Může aplikace provést změnu, kterou dělá uživatel, a dostane jasnou odpověď o úspěchu nebo chybě?
• Kontroluje pravidla, zda je změna povolená, server?

Nejčastější mezerou jsou úkoly, které dnešní webová aplikace řeší přes stránky vykreslované na serveru nebo přes interní volání. Data existují, jen chybí endpoint, který by mobilní aplikace mohla zavolat.

Přihlášení, které funguje v telefonu

Přihlášení do mobilní aplikace funguje jinak než relace v prohlížeči. Před začátkem vývoje je dobré vědět:

• Jak se uživatelé přihlašují dnes: e-mailem a heslem, přes firemního poskytovatele identity, jednotným přihlášením (SSO), nebo jinak.
• Zda backend vydává tokeny, které si aplikace může bezpečně uložit a obnovit, aniž by se uživatel musel pokaždé znovu přihlašovat.
• Jak se relace ukončuje a zda lze odebrat přístup jednomu zařízení, třeba při ztrátě telefonu.
• Zda některý krok přihlášení nezávisí na funkci prohlížeče, kterou je v mobilu potřeba vyřešit jinak.

Pokud vaše organizace poskytovatele identity už používá, aplikace by ho měla zpravidla využít, místo aby zaváděla další sadu přihlašovacích údajů.

Přístup k datům a oprávnění

Mobilní aplikace běží na zařízení, které nemáte pod kontrolou. Cokoli API vrátí, si může přečíst každý, kdo prozkoumá síťový provoz, a kontrolu, která běží jen v aplikaci, lze obejít. Oprávnění proto patří na server.

Užitečné otázky zní: kdo smí vidět které záznamy, kdo je smí měnit a zda API tato pravidla uplatňuje pro každého uživatele, nebo spoléhá na to, že webová aplikace skryje, co uživatel vidět nemá. Ve druhém případě musí tuto odpovědnost převzít API dřív, než ho začne používat mobilní klient.

Vyplatí se také včas dohodnout, která data si aplikace smí uložit do zařízení, na jak dlouho a co se s nimi stane po odhlášení.

Kdo může upravit backend?

Tahle otázka rozhoduje o většině projektů postavených na existujícím produktu. Aplikace bude potřebovat drobné úpravy API: chybějící pole, nový filtr, endpoint přizpůsobený obrazovce telefonu. Na vaší straně musí být někdo, kdo umí vysvětlit, jak backend funguje, a kdo tyto změny provede nebo schválí.

V praxi to znamená:

• Konkrétního člověka nebo tým odpovědný za backend, který má na projekt vyhrazený čas.
• Dokumentaci nebo popis API, který odpovídá tomu, co skutečně běží.
• Testovací prostředí, které může aplikace používat, s testovacími účty a daty, která jsou realistická, ale nejsou produkčními daty zákazníků.
• Dohodnutý postup, jak změny backendu požadovat a vydávat, aby se aplikace a API vyvíjely společně.

Bez toho může i dobře navržená aplikace čekat na odpovědi, které nikdo nedokáže dát.

Co když API nestačí?

Někdy jsou mezery větší než pár úprav. API může být určené pro interní použití, vracet data v podobě, která se do telefonu nehodí, nebo se může měnit jen obtížně.

Pak existují dvě základní možnosti. Správce backendu API rozšíří a vše zůstane na jednom místě. Nebo, pokud to není praktické, může vedle vašeho systému vzniknout samostatný backend pro aplikaci: slouží aplikaci, volá váš stávající systém a váš produkt nechá, jak je. Tato vrstva není cestou, jak váš produkt nahradit nebo přestavět. Zda je potřeba, se rozhoduje u konkrétního projektu, a pokud ano, nabídka přesně vymezí, co vrstva dělá, k jakým datům má přístup a kdo za ni odpovídá.

Úplně nový produkt bez existujícího systému je jiná situace. Tam se v rámci rozsahu projektu dohodne, co aplikace potřebuje na straně serveru.

Krátký kontrolní seznam

Než požádáte o nabídku na aplikaci ke stávajícímu produktu, zkuste odpovědět:

1. Které úkoly musí první verze zvládnout a pokrývá je API?
2. Jak se uživatelé přihlašují a umí backend vydat a odebrat tokeny pro jednotlivá zařízení?
3. Uplatňuje API oprávnění pro každého uživatele?
4. Kdo umí backend vysvětlit a upravit a jak se změny vydávají?
5. Existuje testovací prostředí s testovacími účty a neprodukčními daty?

K zahájení rozhovoru nemusíte znát všechny odpovědi. Neznámé věci nevadí, pokud jsou zapsané jako neznámé, aby s nimi rozsah mohl počítat. Širší pohled na to, co do poptávky patří, najdete v článku jaké podklady poslat před poptávkou mobilní aplikace. Pokud zároveň řešíte, jak postavit samotnou aplikaci, článek React Native pro firemní aplikace popisuje, co jeden kód pro iOS a Android vyřeší a co ne.

Další krok

Pokud plánujete aplikaci nad stávajícím systémem, pro začátek stačí stručné shrnutí: co má aplikace dělat, co vaše API dnes umí a kdo se stará o backend. Poslat ho můžete přes kontaktní stránku. Do první zprávy prosím nevkládejte přístupové údaje ani zákaznická data, k posouzení spolupráce nejsou potřeba.