API

Prohlížeč pošle na URL HTTP požadavek — třeba POST /api/orders/1284/status — backend ho zvaliduje, zavolá databázi a odpoví JSONem. Víc frontend nevidí. Tabulka objednávek, webhook na sklad i generátor faktur za tím se dají přepsat od nuly a frontend to nepozná, dokud zůstane stejná podoba odpovědi.

Dominují dva styly. REST popisuje svět jako zdroje (GET /orders/1284, PATCH /orders/1284) a pro většinu webových produktů je to správný základ. RPC — gRPC, JSON-RPC nebo jedno POST /api s názvem metody uvnitř — je dobře pojmenované volání funkce přes síť, které sedí interním službám, velkým objemům dat a generovaným klientům. Jednou větou: REST se ptá na věci, RPC volá funkce.

Každé pole v odpovědi je slib. Když jedno zmizí, něco upadne ve dvě ráno v integraci, na které stojí váš e-shop. Pole, které jednou znamenalo „vás vídeňský zákazník“, se změní na prostý řetězec a tři partneři tiše selžou.

Pravidla, která ušetří týdny: pole přidávejte kdykoliv, nikdy nepřejmenovávejte a nemažte bez oznámeného období, vracejte explicitní verzi odpovědi a každý endpoint, který používá partner, berte jako veřejné API s vlastní dokumentací. Když ho nikdo mimo váš tým nevolá, nechte ho interní — pak sliby nemusíte držet věčně.

Integrační práce není efektní, ale právě na ní se produkty zastaví. CRM, dopravce, platební brána, účetní systém: každý je API, které nekontrolujete, se svými okrajovými případy, limity a výpadky. Když své API navrhujete se stejnou disciplínou — jasné chyby, bezpečné opakování, jeden identifikátor, na kterém se všichni shodnou — trvají ty spoje dny místo měsíců.

Hlídejte i banality. Ceny musí nést měnu, data musí být explicitně časová zóna a každý zápisový endpoint má být idempotentní, aby opakování po timeoutu nevytvořilo druhou fakturu. Když přes spojení teče osobní údaje, šifrujte ho a jednoduše zadejte scope — API klíč v balíčku prohlížeče jsou otevřené dveře.