Sdílet prostřednictvím

Vytvoření jednoduché mikroslužby CRUD řízené daty

  • Článek

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.

Stáhnout PDF

Architektura mikroslužeb .NET pro kontejnerizované eBooky aplikací .NET

Tato část popisuje, jak vytvořit jednoduchou mikroslužbu, která provádí operace vytvoření, čtení, aktualizace a odstranění (CRUD) ve zdroji dat.

Návrh jednoduché mikroslužby CRUD

Z hlediska návrhu je tento typ kontejnerizované mikroslužby velmi jednoduchý. Možná problém, který se má vyřešit, je jednoduchý, nebo možná implementace je pouze důkazem konceptu.

Diagram znázorňující jednoduchý vzor interního návrhu mikroslužby CRUD

Obrázek 6–4 Interní návrh jednoduchých mikroslužeb CRUD

Příkladem tohoto typu jednoduché služby datové jednotky je mikroslužba katalogu z ukázkové aplikace eShopOnContainers. Tento typ služby implementuje všechny funkce v jednom projektu webového rozhraní API ASP.NET Core, který zahrnuje třídy pro datový model, obchodní logiku a kód pro přístup k datům. Ukládá také související data do databáze běžící na SQL Serveru (jako jiný kontejner pro účely vývoje/testování), ale může to být také jakýkoli běžný hostitel SQL Serveru, jak je znázorněno na obrázku 6–5.

Diagram znázorňující kontejner mikroslužeb řízené daty nebo mikroslužby CRUD

Obrázek 6–5 Jednoduchý návrh mikroslužeb řízené daty nebo mikroslužby CRUD

Předchozí diagram znázorňuje logickou mikroslužbu katalogu, která zahrnuje jeho databázi Katalogu, která může být nebo není ve stejném hostiteli Dockeru. Databáze ve stejném hostiteli Dockeru může být vhodná pro vývoj, ale ne pro produkční prostředí. Při vývoji tohoto typu služby potřebujete jenom ASP.NET Core a rozhraní API pro přístup k datům nebo ORM, jako je Entity Framework Core. Metadata Swaggeru můžete také vygenerovat automaticky prostřednictvím Swashbuckle, abyste zadali popis toho, co vaše služba nabízí, jak je vysvětleno v další části.

Mějte na paměti, že spouštění databázového serveru, jako je SQL Server v kontejneru Dockeru, je skvělé pro vývojová prostředí, protože můžete mít všechny závislosti spuštěné, aniž byste museli zřizovat databázi v cloudu nebo v místním prostředí. Tento přístup je vhodný při spouštění integračních testů. Pro produkční prostředí se však nedoporučuje používat databázový server v kontejneru, protože s tímto přístupem obvykle nemáte vysokou dostupnost. Pro produkční prostředí v Azure se doporučuje používat Azure SQL DB nebo jakoukoli jinou databázovou technologii, která může poskytovat vysokou dostupnost a vysokou škálovatelnost. Například pro přístup NoSQL můžete zvolit CosmosDB.

Nakonec můžete úpravou souboru Dockerfile a docker-compose.yml souborů metadat nakonfigurovat způsob vytvoření image tohoto kontejneru – jakou základní image bude používat, a také nastavení návrhu, jako jsou interní a externí názvy a porty TCP.

Implementace jednoduché mikroslužby CRUD s ASP.NET Core

Pokud chcete implementovat jednoduchou mikroslužbu CRUD pomocí .NET a sady Visual Studio, začněte vytvořením jednoduchého projektu webového rozhraní API pro ASP.NET Core (spuštěný v .NET, aby mohl běžet na hostiteli Dockeru pro Linux), jak je znázorněno na obrázku 6 až 6.

Snímek obrazovky visual studios zobrazující nastavení projektu

Obrázek 6–6 Vytvoření projektu webového rozhraní API ASP.NET Core v sadě Visual Studio 2019

Pokud chcete vytvořit projekt webového rozhraní API ASP.NET Core, nejprve vyberte webovou aplikaci ASP.NET Core a pak vyberte typ rozhraní API. Po vytvoření projektu můžete řadiče MVC implementovat stejně jako v jakémkoli jiném projektu webového rozhraní API pomocí rozhraní API Entity Framework nebo jiného rozhraní API. V novém projektu webového rozhraní API uvidíte, že jediná závislost, kterou máte v této mikroslužbě, je na samotném ASP.NET Core. Interně v rámci závislosti Microsoft.AspNetCore.All odkazuje na Entity Framework a mnoho dalších balíčků NuGet .NET, jak je znázorněno na obrázku 6-7.

Snímek obrazovky se službou VS zobrazující závislosti NuGet katalogu.Api

Obrázek 6–7 Závislosti v jednoduché mikroslužbě webového rozhraní API CRUD

Projekt rozhraní API obsahuje odkazy na balíček NuGet Microsoft.AspNetCore.App, který obsahuje odkazy na všechny základní balíčky. Může obsahovat i některé další balíčky.

Implementace služeb webového rozhraní API CRUD pomocí Entity Framework Core

Entity Framework (EF) Core je jednoduchá, rozšiřitelná a multiplatformní verze oblíbené technologie přístupu k datům Entity Framework. EF Core je objektově-relační mapovač (ORM), který vývojářům .NET umožňuje pracovat s databází pomocí objektů .NET.

Mikroslužba katalogu používá EF a poskytovatele SQL Serveru, protože jeho databáze běží v kontejneru s imagí Sql Serveru pro Linux Docker. Databázi je ale možné nasadit do libovolného SQL Serveru, jako je místní Windows nebo Azure SQL DB. Jediná věc, kterou byste museli změnit, je připojovací řetězec v mikroslužbě webového rozhraní API ASP.NET.

Datový model

S EF Core se přístup k datům provádí pomocí modelu. Model se skládá z tříd entit (doménového modelu) a odvozeného kontextu (DbContext), který představuje relaci s databází, což umožňuje dotazování a ukládání dat. Model můžete vygenerovat z existující databáze, ručně zakódovat model tak, aby odpovídal vaší databázi, nebo pomocí techniky migrace EF vytvořit databázi z modelu pomocí přístupu založeného na kódu (což usnadňuje vývoj databáze v průběhu času). U mikroslužby katalogu jsme použili poslední přístup. Příklad třídy entity CatalogItem můžete vidět v následujícím příkladu kódu, což je jednoduchá třída entity POCO (Plain Old Class Object).

public class CatalogItem
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public decimal Price { get; set; }
    public string PictureFileName { get; set; }
    public string PictureUri { get; set; }
    public int CatalogTypeId { get; set; }
    public CatalogType CatalogType { get; set; }
    public int CatalogBrandId { get; set; }
    public CatalogBrand CatalogBrand { get; set; }
    public int AvailableStock { get; set; }
    public int RestockThreshold { get; set; }
    public int MaxStockThreshold { get; set; }

    public bool OnReorder { get; set; }
    public CatalogItem() { }

    // Additional code ...
}

Potřebujete také DbContext, který představuje relaci s databází. Pro mikroslužbu katalogu je třída CatalogContext odvozena ze základní třídy DbContext, jak je znázorněno v následujícím příkladu:

public class CatalogContext : DbContext
{
    public CatalogContext(DbContextOptions<CatalogContext> options) : base(options)
    { }
    public DbSet<CatalogItem> CatalogItems { get; set; }
    public DbSet<CatalogBrand> CatalogBrands { get; set; }
    public DbSet<CatalogType> CatalogTypes { get; set; }

    // Additional code ...
}

Můžete mít další DbContext implementace. Například v ukázkové mikroslužbě Catalog.API existuje druhá DbContext pojmenovaná, CatalogContextSeed ve které se při prvním pokusu o přístup k databázi automaticky naplní ukázková data. Tato metoda je užitečná také pro ukázková data a scénáře automatizovaného testování.

V rámci této DbContextmetody můžete přizpůsobit OnModelCreating mapování entit objektu/databáze a další body rozšiřitelnosti EF.

Dotazování dat z kontrolerů webového rozhraní API

Instance tříd entit se obvykle načítají z databáze pomocí jazyka integrovaného dotazu (LINQ), jak je znázorněno v následujícím příkladu:

[Route("api/v1/[controller]")]
public class CatalogController : ControllerBase
{
    private readonly CatalogContext _catalogContext;
    private readonly CatalogSettings _settings;
    private readonly ICatalogIntegrationEventService _catalogIntegrationEventService;

    public CatalogController(
        CatalogContext context,
        IOptionsSnapshot<CatalogSettings> settings,
        ICatalogIntegrationEventService catalogIntegrationEventService)
    {
        _catalogContext = context ?? throw new ArgumentNullException(nameof(context));
        _catalogIntegrationEventService = catalogIntegrationEventService
            ?? throw new ArgumentNullException(nameof(catalogIntegrationEventService));

        _settings = settings.Value;
        context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
    }

    // GET api/v1/[controller]/items[?pageSize=3&pageIndex=10]
    [HttpGet]
    [Route("items")]
    [ProducesResponseType(typeof(PaginatedItemsViewModel<CatalogItem>), (int)HttpStatusCode.OK)]
    [ProducesResponseType(typeof(IEnumerable<CatalogItem>), (int)HttpStatusCode.OK)]
    [ProducesResponseType((int)HttpStatusCode.BadRequest)]
    public async Task<IActionResult> ItemsAsync(
        [FromQuery]int pageSize = 10,
        [FromQuery]int pageIndex = 0,
        string ids = null)
    {
        if (!string.IsNullOrEmpty(ids))
        {
            var items = await GetItemsByIdsAsync(ids);

            if (!items.Any())
            {
                return BadRequest("ids value invalid. Must be comma-separated list of numbers");
            }

            return Ok(items);
        }

        var totalItems = await _catalogContext.CatalogItems
            .LongCountAsync();

        var itemsOnPage = await _catalogContext.CatalogItems
            .OrderBy(c => c.Name)
            .Skip(pageSize * pageIndex)
            .Take(pageSize)
            .ToListAsync();

        itemsOnPage = ChangeUriPlaceholder(itemsOnPage);

        var model = new PaginatedItemsViewModel<CatalogItem>(
            pageIndex, pageSize, totalItems, itemsOnPage);

        return Ok(model);
    }
    //...
}
Ukládání dat

Data se v databázi vytvářejí, odstraňují a upravují pomocí instancí tříd entit. Do kontrolerů webového rozhraní API můžete přidat kód podobný následujícímu pevně zakódovanému příkladu (v tomto případě napodobení dat).

var catalogItem = new CatalogItem() {CatalogTypeId=2, CatalogBrandId=2,
                                     Name="Roslyn T-Shirt", Price = 12};
_context.Catalog.Add(catalogItem);
_context.SaveChanges();
Injektáž závislostí v řadičích jádra a webového rozhraní API ASP.NET

V ASP.NET Core můžete použít injektáž závislostí (DI) z krabice. Nemusíte nastavovat kontejner Inversion of Control (IoC) jiného výrobce, i když pokud chcete, můžete upřednostňovaný kontejner IoC připojit k infrastruktuře ASP.NET Core. V tomto případě to znamená, že prostřednictvím konstruktoru kontroleru můžete přímo vložit požadované úložiště EF DBContext nebo další úložiště.

CatalogController V dříve uvedené třídě ( CatalogContext který dědí z DbContext) typ se vloží spolu s ostatními požadovanými objekty v konstruktoruCatalogController().

Důležitou konfigurací pro nastavení v projektu webového rozhraní API je registrace třídy DbContext do kontejneru IoC služby. Obvykle to uděláte v souboru Program.cs voláním builder.Services.AddDbContext<CatalogContext>() metody, jak je znázorněno v následujícím zjednodušeném příkladu:

// Additional code...

builder.Services.AddDbContext<CatalogContext>(options =>
{
    options.UseSqlServer(builder.Configuration["ConnectionString"],
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.MigrationsAssembly(
            typeof(Program).GetTypeInfo().Assembly.GetName().Name);

        //Configuring Connection Resiliency:
        sqlOptions.
            EnableRetryOnFailure(maxRetryCount: 5,
            maxRetryDelay: TimeSpan.FromSeconds(30),
            errorNumbersToAdd: null);
    });

    // Changing default behavior when client evaluation occurs to throw.
    // Default in EFCore would be to log warning when client evaluation is done.
    options.ConfigureWarnings(warnings => warnings.Throw(
        RelationalEventId.QueryClientEvaluationWarning));
});

Další materiály

Databázové připojovací řetězec a proměnné prostředí používané kontejnery Dockeru

Můžete použít nastavení ASP.NET Core a přidat Připojení ionString vlastnost do settings.json souboru, jak je znázorněno v následujícím příkladu:

{
    "ConnectionString": "Server=tcp:127.0.0.1,5433;Initial Catalog=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]",
    "ExternalCatalogBaseUrl": "http://host.docker.internal:5101",
    "Logging": {
        "IncludeScopes": false,
        "LogLevel": {
            "Default": "Debug",
            "System": "Information",
            "Microsoft": "Information"
        }
    }
}

Soubor settings.json může mít výchozí hodnoty pro vlastnost Připojení ionString nebo pro jakoukoli jinou vlastnost. Tyto vlastnosti se ale přepíše hodnotami proměnných prostředí, které zadáte v souboru docker-compose.override.yml při použití Dockeru.

Ze svých docker-compose.yml nebo docker-compose.override.yml souborů můžete tyto proměnné prostředí inicializovat tak, aby je Docker nastavil jako proměnné prostředí operačního systému, jak je znázorněno v následujícím docker-compose.override.yml souboru (připojovací řetězec a další řádky zabalí v tomto příkladu, ale nezabalí se do vlastního souboru).

# docker-compose.override.yml

#
catalog-api:
  environment:
    - ConnectionString=Server=sqldata;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]
    # Additional environment variables for this service
  ports:
    - "5101:80"

Soubory docker-compose.yml na úrovni řešení jsou nejen flexibilnější než konfigurační soubory na úrovni projektu nebo mikroslužby, ale také bezpečnější, pokud přepíšete proměnné prostředí deklarované v souborech docker-compose hodnotami nastavenými z vašich nástrojů nasazení, jako jsou úlohy nasazení Azure DevOps Services Docker.

Nakonec můžete tuto hodnotu získat z kódu pomocí kódu builder.Configuration\["ConnectionString"\], jak je znázorněno v předchozím příkladu kódu.

V produkčních prostředích ale můžete chtít prozkoumat další způsoby ukládání tajných kódů, jako jsou připojovací řetězec. Skvělým způsobem, jak spravovat tajné kódy aplikací, je použití služby Azure Key Vault.

Azure Key Vault pomáhá ukládat a chránit kryptografické klíče a tajné kódy používané vašimi cloudovými aplikacemi a službami. Tajný kód je vše, co chcete mít pod přísnou kontrolou, jako jsou klíče rozhraní API, připojovací řetězec, hesla atd. a přísná kontrola zahrnuje protokolování využití, nastavení vypršení platnosti, správu přístupu, mimo jiné.

Azure Key Vault umožňuje podrobnou úroveň řízení využití tajných kódů aplikací, aniž by je museli znát. Tajné kódy je možné dokonce obměňovat kvůli lepšímu zabezpečení, aniž by došlo k narušení vývoje nebo provozu.

Aplikace musí být zaregistrované ve službě Active Directory organizace, aby mohly používat službu Key Vault.

Další podrobnosti najdete v dokumentaci ke konceptům služby Key Vault.

Implementace správy verzí ve webových rozhraních API ASP.NET

S tím, jak se mění obchodní požadavky, můžou se přidávat nové kolekce prostředků, můžou se měnit vztahy mezi prostředky a strukturou dat v prostředcích. Aktualizace webového rozhraní API pro zpracování nových požadavků je relativně jednoduchý proces, ale musíte zvážit účinky, které tyto změny budou mít na klientské aplikace využívající webové rozhraní API. I když vývojář navrhuje a implementuje webové rozhraní API má plnou kontrolu nad tímto rozhraním API, vývojář nemá stejnou kontrolu nad klientskými aplikacemi, které by mohly být vytvořeny organizací třetích stran, které pracují vzdáleně.

Správa verzí umožňuje webovému rozhraní API indikovat funkce a prostředky, které zveřejňuje. Klientská aplikace pak může odesílat požadavky na konkrétní verzi funkce nebo prostředku. Existuje několik přístupů k implementaci správy verzí:

  • Správa verzí pomocí identifikátoru URI

  • Správa verzí pomocí řetězce dotazu

  • Správa verzí pomocí hlavičky

Nejjednodušší je implementovat řetězec dotazu a správu verzí identifikátoru URI. Správa verzí hlaviček je dobrým přístupem. Správa verzí hlaviček ale není tak explicitní a jednoduchá jako správa verzí identifikátoru URI. Vzhledem k tomu, že správa verzí adres URL je nejjednodušší a nejvýraznější, ukázková aplikace eShopOnContainers používá správu verzí URI.

Při správě verzí identifikátoru URI, jako v ukázkové aplikaci eShopOnContainers, při každé úpravě webového rozhraní API nebo změně schématu prostředků přidáte číslo verze do identifikátoru URI pro každý prostředek. Stávající identifikátory URI by měly dál fungovat jako předtím a vracet prostředky, které odpovídají schématu, které odpovídají požadované verzi.

Jak je znázorněno v následujícím příkladu kódu, můžete verzi nastavit pomocí atributu Route v kontroleru webového rozhraní API, který verzi explicitní v identifikátoru URI (v1 v tomto případě).

[Route("api/v1/[controller]")]
public class CatalogController : ControllerBase
{
    // Implementation ...

Tento mechanismus správy verzí je jednoduchý a závisí na směrování požadavku na příslušný koncový bod na server. Pro sofistikovanější správu verzí a nejlepší metodu při použití REST byste ale měli použít hypermedia a implementovat HATEOAS (hypertext jako modul stavu aplikace).

Další materiály

Generování metadat popisu Swaggeru z webového rozhraní API ASP.NET Core

Swagger je běžně používaná opensourcová architektura podporovaná rozsáhlým ekosystémem nástrojů, které pomáhají navrhovat, sestavovat, dokumentovat a využívat rozhraní RESTful API. Stává se standardem pro doménu metadat popisu rozhraní API. Měli byste zahrnout metadata popisu Swaggeru s jakýmkoli druhem mikroslužeb, ať už mikroslužeb řízených daty, nebo pokročilejšími mikroslužbami řízenými doménami (jak je vysvětleno v následující části).

Jádrem Swaggeru je specifikace Swaggeru, což je metadata popisu rozhraní API v souboru JSON nebo YAML. Specifikace vytvoří kontrakt RESTful pro vaše rozhraní API, který podrobně rozepisuje všechny jeho prostředky a operace ve formátu čitelného pro člověka i strojově čitelný pro snadný vývoj, zjišťování a integraci.

Specifikace je základem specifikace OpenAPI (OAS) a je vyvinuta v otevřené, transparentní a spolupráci komunity pro standardizaci způsobu definování rozhraní RESTful.

Specifikace definuje strukturu toho, jak lze službu zjistit a jak její schopnosti chápou. Další informace, včetně webového editoru a příkladů specifikací Swaggeru od společností, jako je Spotify, Uber, Slack a Microsoft, najdete na webu Swagger (https://swagger.io).

Proč používat Swagger?

Hlavní důvody pro generování metadat Swaggeru pro vaše rozhraní API jsou následující.

Schopnost jiných produktů automaticky využívat a integrovat vaše rozhraní API Swagger podporují desítky produktů a komerčních nástrojů a mnoho knihoven a architektur . Microsoft má produkty a nástroje vysoké úrovně, které můžou automaticky využívat rozhraní API založená na Swaggeru, například následující:

Schopnost automaticky generovat dokumentaci k rozhraní API Při vytváření rozsáhlých rozhraní RESTful API, jako jsou složité aplikace založené na mikroslužbách, musíte zpracovat mnoho koncových bodů s různými datovými modely používanými v datových částech požadavků a odpovědí. Správná dokumentace a získání solidního průzkumníka rozhraní API, jak se s Swaggerem dostanete, je klíčem k úspěchu vašeho rozhraní API a přijetí vývojáři.

Metadata Swaggeru jsou to, co Microsoft Flow, PowerApps a Azure Logic Apps používají, abyste pochopili, jak používat rozhraní API a jak se k nim připojit.

Existuje několik možností automatizace generování metadat Swaggeru pro aplikace ASP.NET Core REST API ve formě funkčních stránek nápovědy rozhraní API na základě swagger-ui.

Pravděpodobně nejlepší je Swashbuckle, který se aktuálně používá v eShopOnContainers a v této příručce se podrobněji podíváme, ale existuje také možnost použít NSwag, který může generovat klienty Rozhraní API TypeScript a C# a také kontrolery jazyka C# ze specifikace Swagger nebo OpenAPI a dokonce skenováním .dll, který obsahuje kontrolery, pomocí NSwagStudio.

Automatizace generování metadat API Swaggeru pomocí balíčku NuGet Swashbuckle

Ruční generování metadat Swaggeru (v souboru JSON nebo YAML) může být zdlouhavé. Zjišťování rozhraní API služeb webového rozhraní API ASP.NET však můžete automatizovat pomocí balíčku NuGet Swashbuckle a dynamicky generovat metadata rozhraní API Swaggeru.

Swashbuckle automaticky generuje metadata Swaggeru pro vaše projekty webového rozhraní API ASP.NET. Podporuje ASP.NET projekty základního webového rozhraní API a tradiční webové rozhraní API ASP.NET a jakoukoli jinou variantu, jako jsou aplikace Azure API, mobilní aplikace Azure, mikroslužby Azure Service Fabric založené na ASP.NET. Podporuje také prosté webové rozhraní API nasazené v kontejnerech, stejně jako pro referenční aplikaci.

Swashbuckle kombinuje Průzkumníka rozhraní API a Swagger nebo swagger-ui a poskytuje bohaté prostředí pro zjišťování a dokumentaci pro uživatele rozhraní API. Kromě svého modulu generátoru metadat Swagger obsahuje Swashbuckle také vloženou verzi swagger-ui, která se automaticky obsluhuje po instalaci Swashbuckle.

To znamená, že rozhraní API můžete doplnit pěkným uživatelským rozhraním zjišťování, které vývojářům pomůže používat vaše rozhraní API. Vyžaduje malé množství kódu a údržby, protože se generuje automaticky, takže se můžete soustředit na vytváření rozhraní API. Výsledek průzkumníka rozhraní API vypadá jako obrázek 6–8.

Snímek obrazovky s Průzkumníkem rozhraní API Swagger zobrazující rozhraní API eShopOContainers

Obrázek 6–8 Průzkumník rozhraní API Swashbuckle založený na metadatech Swaggeru – mikroslužba katalogu eShopOnContainers

Dokumentace k rozhraní API Swaggeru vygenerovaná pomocí Swashbucklu zahrnuje všechny publikované akce. Průzkumník rozhraní API tady není nejdůležitější. Jakmile budete mít webové rozhraní API, které se může popsat v metadatech Swaggeru, můžete rozhraní API bez problémů používat z nástrojů založených na Swaggeru, včetně generátorů kódu třídy proxy klientů, které můžou cílit na mnoho platforem. Jak už jsme zmínili, AutoRest například automaticky vygeneruje klientské třídy .NET. K dispozici jsou ale také další nástroje, jako je swagger-codegen , které umožňují automatické generování kódu klientských knihoven rozhraní API, zástupné procedury serverů a dokumentaci.

Swashbuckle se v současné době skládá z pěti interních balíčků NuGet v rámci metabalíku vysoké úrovně Swashbuckle.AspNetCore pro aplikace ASP.NET Core.

Po instalaci těchto balíčků NuGet do projektu webového rozhraní API je potřeba nakonfigurovat Swagger ve třídě Program.cs stejně jako v následujícím zjednodušeném kódu:

// Add framework services.

builder.Services.AddSwaggerGen(options =>
{
    options.DescribeAllEnumsAsStrings();
    options.SwaggerDoc("v1", new OpenApiInfo
    {
        Title = "eShopOnContainers - Catalog HTTP API",
        Version = "v1",
        Description = "The Catalog Microservice HTTP API. This is a Data-Driven/CRUD microservice sample"
    });
});

// Other startup code...

app.UseSwagger();

if (app.Environment.IsDevelopment())
{
    app.UseSwaggerUI(c =>
    {
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1");
    });
}

Jakmile to uděláte, můžete spustit aplikaci a procházet následující koncové body JSON a uživatelského rozhraní Swaggeru pomocí adres URL, jako jsou tyto:

  http://<your-root-url>/swagger/v1/swagger.json

  http://<your-root-url>/swagger/

Dříve jste viděli vygenerované uživatelské rozhraní vytvořené Swashbuckle pro adresu URL, jako je http://<your-root-url>/swagger. Na obrázku 6–9 můžete také zjistit, jak můžete otestovat jakoukoli metodu rozhraní API.

Snímek obrazovky s uživatelským rozhraním Swagger zobrazující dostupné testovací nástroje

Obrázek 6–9 Swashbuckle UI testing the Catalog/Items API method

Podrobnosti o rozhraní API Swaggeru ukazují ukázku odpovědi a lze ji použít ke spuštění skutečného rozhraní API, což je skvělé pro zjišťování vývojářů. Pokud chcete zobrazit metadata JSON Swaggeru vygenerovaná z mikroslužby eShopOnContainers (což je to, co nástroje používají pod ním), vytvořte požadavek http://<your-root-url>/swagger/v1/swagger.json pomocí rozšíření Visual Studio Code: REST Client.

Další materiály

PředchozíDalší