Dela via

Skapa, utveckla och versionshantera MIKROTJÄNST-API:er och kontrakt

  • Artikel

Dricks

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Ett API för mikrotjänster är ett kontrakt mellan tjänsten och dess klienter. Du kommer bara att kunna utveckla en mikrotjänst oberoende av varandra om du inte bryter dess API-kontrakt, vilket är anledningen till att kontraktet är så viktigt. Om du ändrar kontraktet påverkar det dina klientprogram eller din API Gateway.

API-definitionens karaktär beror på vilket protokoll du använder. Om du till exempel använder meddelanden, till exempel AMQP, består API:et av meddelandetyperna. Om du använder HTTP- och RESTful-tjänster består API:et av URL:erna och JSON-formaten för begäran och svar.

Men även om du funderar på ditt ursprungliga kontrakt måste ett tjänst-API ändras över tid. När det händer – och särskilt om ditt API är ett offentligt API som används av flera klientprogram – kan du vanligtvis inte tvinga alla klienter att uppgradera till ditt nya API-kontrakt. Du behöver vanligtvis stegvis distribuera nya versioner av en tjänst på ett sätt som både gamla och nya versioner av ett tjänstkontrakt körs samtidigt. Därför är det viktigt att ha en strategi för versionshantering av tjänsten.

När API-ändringarna är små, till exempel om du lägger till attribut eller parametrar i ditt API, bör klienter som använder ett äldre API växla och arbeta med den nya versionen av tjänsten. Du kanske kan ange standardvärden för eventuella attribut som saknas och klienterna kanske kan ignorera eventuella extra svarsattribut.

Ibland måste du dock göra större och inkompatibla ändringar i ett tjänst-API. Eftersom du kanske inte kan tvinga klientprogram eller tjänster att uppgradera omedelbart till den nya versionen måste en tjänst ha stöd för äldre versioner av API:et under en viss period. Om du använder en HTTP-baserad mekanism, till exempel REST, är en metod att bädda in API-versionsnumret i URL:en eller i ett HTTP-huvud. Sedan kan du välja mellan att implementera båda versionerna av tjänsten samtidigt i samma tjänstinstans eller att distribuera olika instanser som var och en hanterar en version av API:et. En bra metod för den här funktionen är Mediator-mönstret (till exempel MediatR-biblioteket) för att frikoppla de olika implementeringsversionerna till oberoende hanterare.

Om du använder en REST-arkitektur är Hypermedia den bästa lösningen för att versionshantera dina tjänster och tillåta föränderliga API:er.

Ytterligare resurser

FöregåendeNästa