Vytváření, vývoj a správa verzí rozhraní API a kontraktů mikroslužeb
Tip
Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.
Rozhraní API mikroslužeb je kontrakt mezi službou a jejími klienty. Mikroslužbu budete moct vyvíjet nezávisle jenom v případě, že neprolomíte její kontrakt rozhraní API, a proto je kontrakt tak důležitý. Pokud kontrakt změníte, ovlivní to vaše klientské aplikace nebo bránu rozhraní API.
Povaha definice rozhraní API závisí na tom, jaký protokol používáte. Pokud například používáte zasílání zpráv, jako je AMQP, rozhraní API se skládá z typů zpráv. Pokud používáte služby HTTP a RESTful, rozhraní API se skládá z adres URL a formátů JSON požadavků a odpovědí.
I když si ale myslíte o počátečním kontraktu, rozhraní API služby se bude muset v průběhu času změnit. Když k tomu dojde , a to zejména v případě, že vaše rozhraní API je veřejné rozhraní API využívané více klientskými aplikacemi, obvykle nemůžete vynutit, aby všichni klienti upgradovali na nový kontrakt rozhraní API. Obvykle je potřeba postupně nasazovat nové verze služby způsobem, který současně běží staré i nové verze kontraktu služby. Proto je důležité mít strategii pro správu verzí služby.
Když jsou změny rozhraní API malé, například když do rozhraní API přidáte atributy nebo parametry, klienti, kteří používají starší rozhraní API, by se měli přepnout a pracovat s novou verzí služby. Možná budete moct zadat výchozí hodnoty pro všechny požadované atributy, které chybí, a klienti můžou ignorovat všechny další atributy odpovědi.
Někdy ale potřebujete provést významné a nekompatibilní změny rozhraní API služby. Protože možná nebudete moct vynutit okamžité upgrade klientských aplikací nebo služeb na novou verzi, musí služba po určitou dobu podporovat starší verze rozhraní API. Pokud používáte mechanismus založený na protokolu HTTP, jako je REST, jedním z přístupů je vložení čísla verze rozhraní API do adresy URL nebo do hlavičky HTTP. Pak se můžete rozhodnout mezi implementací obou verzí služby současně ve stejné instanci služby nebo nasazením různých instancí, které každý z nich zpracovává verzi rozhraní API. Dobrým přístupem pro tuto funkci je model zprostředkovatel (například knihovna MediatR) k oddělení různých verzí implementace do nezávislých obslužných rutin.
A konečně, pokud používáte architekturu REST, je nejlepším řešením pro správu verzí služeb Hypermedia a povolení nepovolitelných rozhraní API.
Další materiály
Scott Hanselman. ASP.NET snadné vytváření verzí webového rozhraní RESTful
https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspxSpráva verzí webového rozhraní API RESTful
https://video2.skills-academy.com/azure/architecture/best-practices/api-design#versioning-a-restful-web-apiRoy Fielding. Správa verzí, Hypermedia a REST
https://www.infoq.com/articles/roy-fielding-on-versioning