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

Aplikace nad stávajícím produktem potřebuje tři věci:

• API, které pokrývá úkoly první verze. Aplikace musí získat potřebná data a odeslat změny, které uživatel provede.
• Přihlášení použitelné v telefonu. Uživatel potřebuje bezpečně zahájit, obnovit a ukončit relaci.
• Správce backendu na vaší straně. Někdo musí systém znát a umět změny API provést nebo schválit.

Pokud API nestačí, je potřeba s mezerami počítat v rozsahu projektu. Pro konkrétní projekt lze probrat serverovou vrstvu, která podpoří aplikaci a ponechá váš stávající produkt v provozu.

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í.

Sepište úkoly první verze

Připravenost API se posuzuje podle úkolů, které má aplikace zvládnout. Sepište tři až pět věcí, které musí uživatel v první verzi udělat, a každou porovnejte s tím, co API umí.

Například: zkontrolovat zůstatek na účtu, schválit požadavek nebo zapsat servisní návštěvu. U každého úkolu potřebujete ověřit data, oprávnění i zpracování odpovědi.

U každého úkolu se zeptejte:

• Čtení: Získá aplikace data pro obrazovku několika požadavky, bez zbytečně velkého stahování?
• Zápis: Může odeslat změnu uživatele a dostane jasnou odpověď o úspěchu nebo chybě?
• Oprávnění: Ověří server, zda smí daný uživatel tuto změnu provést?

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í

Oprávnění musí kontrolovat server. Telefon je pod kontrolou uživatele. Upravená aplikace může prohlížet odpovědi API a obejít kontroly, které běží jen v ní. Doporučení OWASP k oprávněním nad jednotlivými záznamy, anglicky vysvětluje, proč musí každá operace API ověřit přístup k požadovanému záznamu.

Ověřte, kdo smí každý záznam vidět a kdo ho smí změnit. API musí tato pravidla uplatňovat pro každého uživatele, i když webové rozhraní omezené záznamy už skrývá.

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?

Určete člověka, který může backend upravit. Aplikace může potřebovat chybějící pole, nový filtr nebo endpoint přizpůsobený obrazovce telefonu. Na vaší straně musí být někdo, kdo systém vysvětlí a 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.

Zapište otázky k připravenosti na jedno místo

Užitečným výstupem kontroly API je stručný seznam odpovědných osob a dalších kroků, ne verdikt, že API je prostě „připravené“ nebo „nepřipravené“. Tento ilustrační přehled odděluje produktová rozhodnutí od změn backendu:

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ě.

Existují dvě základní možnosti:

• Rozšířit stávající API. Správce backendu doplní funkce, které aplikace potřebuje.
• Dohodnout serverovou vrstvu pro aplikaci. Pokud rozšíření API není praktické, může aplikaci obsluhovat samostatná vrstva, která volá váš stávající systém.

Druhá možnost se vymezuje pro konkrétní projekt. Nabídka musí určit, co vrstva dělá, k jakým datům má přístup a kdo za ni odpovídá. Váš stávající produkt zůstává v provozu.

Ú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.

Ilustrační požadavek a odpověď

Tým aplikace potřebuje příklady, které ukazují kontrakt včetně stránkování a chybového chování. Následující ukázka používá syntetické identifikátory a slouží jen jako ilustrace, není návrhem konkrétního API:

GET /mobile/v1/work-orders?after=cursor_42&limit=2
Authorization: Bearer <test-token>

{
  "items": [
    {
      "id": "wo_demo_104",
      "status": "scheduled",
      "startsAt": "2026-10-05T08:00:00Z"
    }
  ],
  "nextCursor": "cursor_44"
}

Užitečný kontrakt popisuje také odpověď pro vypršelý token, chybějící záznam a zakázku, ke které uživatel nemá přístup. Aplikace musí tyto případy rozeznat podle stavových kódů a stabilních identifikátorů chyb, ne rozborem textu pro člověka. Stejné příklady patří do testovacího prostředí, aby je oba týmy dokázaly zopakovat před vydáním.

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. Jak se stránkují seznamy a které chybové kódy umí aplikace výslovně zpracovat?
5. Které úkoly fungují offline, co smí zůstat v zařízení a jak se řeší konflikty?
6. Které události na serveru mají vyvolat push notifikaci nebo aktualizaci aplikace?
7. Kdo umí backend vysvětlit a upravit a jak se změny aplikace a API vydávají společně?
8. Existuje testovací prostředí s testovacími účty, syntetickými daty a stejnou verzí API, kterou použije aplikace?

Rozhovor můžete začít i s nezodpovězenými otázkami. Zapište je jako neznámé, aby se ověřily před dohodou o rozsahu a odhadu.

Širší zadání popisuje článek jaké podklady poslat před poptávkou mobilní aplikace. Volbě technologie se věnuje React Native pro firemní aplikace.

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.