Proč verzovat API, když se datový model ještě třikrát změní?

U dlouho běžících procesů testujte i posun času dopředu. Aplikace, která každou minutu obnovuje data, se po hodině chová jinak než po první iteraci. Simulujte zrychlený čas nebo volejte obnovovací funkci v cyklu s ručně posouvaným časem. Sledujte přitom, proměna bytu zda se někde nehromadí stará data nebo zda se časovače nezdvojují. Typická chyba je naplánování nového časovače při každé aktualizaci bez zrušení předchozího, For more information on rady pro rekonstrukci take a look at the webpage. což po čase zatíží aplikaci i test.

Než sáhnete po debuggeru, otevřete konzoli prohlížeče. Většina chyb se projeví jako červený výpis s číslem řádku a názvem souboru. Kliknutím na něj se přesunete přímo do zdrojového kódu. Pokud výpis chybí a přesto něco nefunguje, hledejte stav, kdy se kód vůbec nespustil — typicky chybějící selektor, překlep v názvu funkce nebo načtení skriptu později, než ho potřebujete.
Pro změny, které breaking jsou, použijte rozšíření místo přepisu. Místo status: "active" přidejte status_detail s bohatší hodnotou a původní pole ponechte. Místo přejmenování customer_id na buyer_id podporujte obě po určitou dobu. Tento souběh je nutné dokumentovat a mít jasný plán odstranění, jinak se z dočasného kompatibility mostu stane věčná zátěž.

Denní stand-up má trvat patnáct minut a nesmí se změnit v report pro manažera. Pravidlo je jednoduché: mluví ten, kdo má co říct k cíli sprintu. Otázky „co jsem dělal včera" a „co budu dělat dnes" stačí. Pokud někdo řeší technický detail, ať si ho vezme po schůzce. Typická chyba je, že se stand-up protáhne na půl hodiny a lidé přestanou poslouchat. Druhá chyba je, že ho vede Scrum Master jako šéf. Scrum Master odstraňuje překážky, ne rozděluje práci.

Další častá chyba je testovat příliš mnoho najednou. Test, který ověřuje deset věcí, po prvním selhání neřekne, co je skutečně špatně. Rozdělte ho na menší celky. Zároveň se vyhněte testování implementačních detailů – pokud test kontroluje, že se zavolala konkrétní interní funkce, rozbije se při každém refaktoringu, i když se chování navenek nezmění. Testujte výsledek, ne cestu k němu.

Datový model se mění vždy. Nová pole, zrušené entity, změněné vztahy. Rest API, které kopíruje aktuální databázové schéma do URL a odpovědí, se s první migrací rozsype. Řešení není předpovídat budoucnost, ale navrhnout rozhraní tak, aby změny byly lokalizované a zpětně kompatibilní.

Praktický postup: definujte si vlastní reprezentace (DTR) pro vstup i výstup, oddělte je od entit, zaveďte verzování na úrovni kontraktu a mějte testy, které ověřují zpětnou kompatibilitu. Při návrhu se ptejte, co se stane, když zítra přibude nový stav objednávky nebo se změní číselník. Pokud odpověď zní „upravíme pět endpointů a všechny klienty", návrh je špatný. Cílem není dokonalá předpověď, ale levná změna.

Druhá typická chyba je síť. Kontejner má vlastní síťový prostor, takže aplikace naslouchající na portu 8080 uvnitř kontejneru není dostupná zvenčí, dokud port výslovně nezveřejníte. Stejně tak spojení mezi dvěma kontejnery nefunguje přes adresu localhost, protože každý kontejner má vlastní localhost. Řešením je uživatelská síť, do které oba kontejnery připojíte, a adresování názvem služby, ne IP adresou. IP adresy se totiž při restartu mění.
Verzujte chování, ne strukturu Verze v URL (/v1/orders) je nejviditelnější, ale sama nic neřeší. Rozhodující je, co považujete za breaking change. Přidání nového pole barvy stěn do obýváku odpovědi obvykle breaking není, pokud klient nevaliduje striktně. Odebrání pole, změna typu nebo významu hodnoty breaking je. Zaveďte pravidlo: klient musí ignorovat neznámá pole a server nikdy nesmí měnit význam existujícího pole. Tím získáte prostor přidávat vlastnosti bez nové verze.

Základ je oddělit kontrakt API od interní reprezentace. Databázová tabulka user nemá automaticky znamenat endpoint /user se všemi sloupci. Vytvořte si vlastní doménové zdroje a mapujte je explicitně. Když později přidáte do tabulky deleted_at nebo rozdělíte adresu na ulici a město, API se nezmění, dokud se tak nerozhodnete. Mapovací vrstva navíc odhalí, které sloupce jsou skutečně součástí veřejného kontraktu.

Typické chyby: vracení celého databázového řádku včetně interních ID a příznaků; používání cizích klíčů jako veřejných identifikátorů; spoléhání na to, že klient pošle všechna pole při aktualizaci; a ignorování chybových stavů, které se po změně modelu změní. Další častá chyba je vnořování příliš mnoha úrovní, protože každá úroveň ztěžuje pozdější plošnou změnu.