Partilhar via

Criando um microsserviço CRUD simples orientado por dados

  • Artigo

Gorjeta

Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Descarregar PDF

Miniatura da capa do eBook .NET Microservices Architecture for Containerized .NET Applications.

Esta seção descreve como criar um microsserviço simples que executa operações de criação, leitura, atualização e exclusão (CRUD) em uma fonte de dados.

Projetando um microsserviço CRUD simples

Do ponto de vista do design, este tipo de microsserviço conteinerizado é muito simples. Talvez o problema a resolver seja simples, ou talvez a implementação seja apenas uma prova de conceito.

Diagrama mostrando um padrão de design interno de microsserviço CRUD simples.

Figura 6-4. Design interno para microsserviços CRUD simples

Um exemplo desse tipo de serviço de unidade de dados simples é o microsserviço de catálogo do aplicativo de exemplo eShopOnContainers. Esse tipo de serviço implementa todas as suas funcionalidades em um único projeto de API Web ASP.NET Core que inclui classes para seu modelo de dados, sua lógica de negócios e seu código de acesso a dados. Ele também armazena seus dados relacionados em um banco de dados em execução no SQL Server (como outro contêiner para fins de desenvolvimento/teste), mas também pode ser qualquer host regular do SQL Server, como mostra a Figura 6-5.

Diagrama mostrando um contêiner de microsserviço orientado por dados/CRUD.

Figura 6-5. Design simples de microsserviço orientado por dados/CRUD

O diagrama anterior mostra o microsserviço lógico do Catálogo, que inclui seu banco de dados do Catálogo, que pode estar ou não no mesmo host do Docker. Ter o banco de dados no mesmo host do Docker pode ser bom para o desenvolvimento, mas não para a produção. Quando você está desenvolvendo esse tipo de serviço, você só precisa de ASP.NET Core e uma API de acesso a dados ou ORM como o Entity Framework Core. Você também pode gerar metadados Swagger automaticamente através do Swashbuckle para fornecer uma descrição do que seu serviço oferece, conforme explicado na próxima seção.

Observe que a execução de um servidor de banco de dados como o SQL Server em um contêiner do Docker é ótima para ambientes de desenvolvimento, porque você pode ter todas as suas dependências em execução sem a necessidade de provisionar um banco de dados na nuvem ou no local. Essa abordagem é conveniente ao executar testes de integração. No entanto, para ambientes de produção, a execução de um servidor de banco de dados em um contêiner não é recomendada, porque você geralmente não obtém alta disponibilidade com essa abordagem. Para um ambiente de produção no Azure, é recomendável usar o Banco de Dados SQL do Azure ou qualquer outra tecnologia de banco de dados que possa fornecer alta disponibilidade e alta escalabilidade. Por exemplo, para uma abordagem NoSQL, você pode escolher CosmosDB.

Finalmente, editando o Dockerfile e os arquivos de metadados docker-compose.yml, você pode configurar como a imagem desse contêiner será criada — qual imagem base ele usará, além de configurações de design, como nomes internos e externos e portas TCP.

Implementando um microsserviço CRUD simples com ASP.NET Core

Para implementar um microsserviço CRUD simples usando .NET e Visual Studio, comece criando um projeto simples de API Web ASP.NET Core (em execução no .NET para que possa ser executado em um host Linux Docker), como mostra a Figura 6-6.

Captura de tela do Visual Studios mostrando a configuração do projeto.

Figura 6-6. Criando um projeto ASP.NET Core Web API no Visual Studio 2019

Para criar um projeto de API Web ASP.NET Core, primeiro selecione um Aplicativo Web ASP.NET Core e, em seguida, selecione o tipo de API. Depois de criar o projeto, você pode implementar seus controladores MVC como faria em qualquer outro projeto de API da Web, usando a API do Entity Framework ou outra API. Em um novo projeto de API Web, você pode ver que a única dependência que você tem nesse microsserviço é ASP.NET próprio Core. Internamente, dentro da dependência Microsoft.AspNetCore.All, ele está fazendo referência ao Entity Framework e a muitos outros pacotes NuGet do .NET, como mostra a Figura 6-7.

Captura de tela do VS mostrando as dependências do NuGet de Catalog.Api.

Figura 6-7. Dependências em um microsserviço de API Web CRUD simples

O projeto de API inclui referências a Microsoft.AspNetCore.App pacote NuGet, que inclui referências a todos os pacotes essenciais. Poderia incluir alguns outros pacotes também.

Implementando serviços de API Web CRUD com o Entity Framework Core

O Entity Framework (EF) Core é uma versão leve, extensível e multiplataforma da popular tecnologia de acesso a dados do Entity Framework. O EF Core é um mapeador objeto-relacional (ORM) que permite que os desenvolvedores .NET trabalhem com um banco de dados usando objetos .NET.

O microsserviço de catálogo usa o EF e o provedor do SQL Server porque seu banco de dados está sendo executado em um contêiner com a imagem do SQL Server para Linux Docker. No entanto, o banco de dados pode ser implantado em qualquer SQL Server, como o Windows local ou o Banco de Dados SQL do Azure. A única coisa que você precisa alterar é a cadeia de conexão no microsserviço da API Web do ASP.NET.

O modelo de dados

Com o EF Core, o acesso aos dados é realizado usando um modelo. Um modelo é composto de classes de entidade (modelo de domínio) e um contexto derivado (DbContext) que representa uma sessão com o banco de dados, permitindo que você consulte e salve dados. Você pode gerar um modelo a partir de um banco de dados existente, codificar manualmente um modelo para corresponder ao seu banco de dados ou usar a técnica de migrações EF para criar um banco de dados a partir do seu modelo, usando a abordagem code-first (que facilita a evolução do banco de dados à medida que seu modelo muda ao longo do tempo). Para o microsserviço de catálogo, a última abordagem foi usada. Você pode ver um exemplo da classe de entidade CatalogItem no exemplo de código a seguir, que é uma classe de entidade POCO (Plain Old Class Object) simples.

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 ...
}

Você também precisa de um DbContext que representa uma sessão com o banco de dados. Para o microsserviço de catálogo, a classe CatalogContext deriva da classe base DbContext, conforme mostrado no exemplo a seguir:

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 ...
}

Você pode ter implementações adicionais DbContext . Por exemplo, no microsserviço Catalog.API de exemplo, há um segundo DbContext nome CatalogContextSeed onde ele preenche automaticamente os dados de exemplo na primeira vez que tenta acessar o banco de dados. Esse método também é útil para dados de demonstração e para cenários de teste automatizados.

DbContextNo , você usa o OnModelCreating método para personalizar mapeamentos de entidade de objeto/banco de dados e outros pontos de extensibilidade do EF.

Consultando dados de controladores de API da Web

As instâncias de suas classes de entidade normalmente são recuperadas do banco de dados usando LINQ (Language-Integrated Query), conforme mostrado no exemplo a seguir:

[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);
    }
    //...
}
Guardar dados

Os dados são criados, excluídos e modificados no banco de dados usando instâncias de suas classes de entidade. Você pode adicionar código como o seguinte exemplo codificado (dados simulados, neste caso) aos seus controladores de API da Web.

var catalogItem = new CatalogItem() {CatalogTypeId=2, CatalogBrandId=2,
                                     Name="Roslyn T-Shirt", Price = 12};
_context.Catalog.Add(catalogItem);
_context.SaveChanges();
Injeção de dependência em controladores ASP.NET Core e API Web

No ASP.NET Core, você pode usar a Injeção de Dependência (DI) pronta para uso. Você não precisa configurar um contêiner de Inversão de Controle (IoC) de terceiros, embora possa conectar seu contêiner IoC preferido à infraestrutura ASP.NET Core, se desejar. Nesse caso, isso significa que você pode injetar diretamente o EF DBContext necessário ou repositórios adicionais por meio do construtor do controlador.

Na classe mencionada CatalogController anteriormente, CatalogContext (que herda de ) tipo é injetado DbContextjunto com os outros objetos necessários no CatalogController() construtor.

Uma configuração importante a ser configurada no projeto de API Web é o registro da classe DbContext no contêiner IoC do serviço. Normalmente, você faz isso no arquivo Program.cs chamando o builder.Services.AddDbContext<CatalogContext>() método, conforme mostrado no exemplo simplificado a seguir:

// 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));
});

Importante

A Microsoft recomenda que você use o fluxo de autenticação mais seguro disponível. Se você estiver se conectando ao SQL do Azure, as Identidades Gerenciadas para recursos do Azure serão o método de autenticação recomendado.

Recursos adicionais

A cadeia de conexão de banco de dados e as variáveis de ambiente usadas pelos contêineres do Docker

Você pode usar as configurações do ASP.NET Core e adicionar uma propriedade ConnectionString ao seu arquivo settings.json, conforme mostrado no exemplo a seguir:

{
    "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"
        }
    }
}

O arquivo settings.json pode ter valores padrão para a propriedade ConnectionString ou para qualquer outra propriedade. No entanto, essas propriedades serão substituídas pelos valores das variáveis de ambiente especificadas no arquivo docker-compose.override.yml, ao usar o Docker.

A partir de seus arquivos docker-compose.yml ou docker-compose.override.yml, você pode inicializar essas variáveis de ambiente para que o Docker as configure como variáveis de ambiente do sistema operacional para você, conforme mostrado no arquivo de docker-compose.override.yml a seguir (a cadeia de conexão e outras linhas são quebradas neste exemplo, mas não seriam encapsuladas em seu próprio arquivo).

# 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"

Importante

A Microsoft recomenda que você use o fluxo de autenticação mais seguro disponível. Se você estiver se conectando ao SQL do Azure, as Identidades Gerenciadas para recursos do Azure serão o método de autenticação recomendado.

Os arquivos docker-compose.yml no nível da solução não são apenas mais flexíveis do que os arquivos de configuração no nível do projeto ou do microsserviço, mas também mais seguros se você substituir as variáveis de ambiente declaradas nos arquivos de composição do docker por valores definidos de suas ferramentas de implantação, como as tarefas de implantação do Docker dos Serviços de DevOps do Azure.

Finalmente, você pode obter esse valor do seu código usando builder.Configuration["ConnectionString"], como mostrado em um exemplo de código anterior.

No entanto, para ambientes de produção, convém explorar maneiras adicionais de como armazenar segredos, como as cadeias de conexão. Uma excelente maneira de gerenciar segredos de aplicativos é usando o Azure Key Vault.

O Azure Key Vault ajuda a armazenar e proteger chaves criptográficas e segredos usados por seus aplicativos e serviços na nuvem. Um segredo é qualquer coisa que você queira manter um controle estrito, como chaves de API, cadeias de conexão, senhas, etc. e o controle estrito inclui registro de uso, definição de expiração, gerenciamento de acesso, entre outros.

O Azure Key Vault permite um nível de controle detalhado do uso de segredos do aplicativo sem a necessidade de avisá-los. Os segredos podem até ser alternados para maior segurança sem interromper o desenvolvimento ou as operações.

Os aplicativos precisam ser registrados no Ative Directory da organização, para que possam usar o Cofre da Chave.

Você pode verificar a documentação Key Vault Concepts para obter mais detalhes.

Implementando o controle de versão em APIs Web ASP.NET

À medida que os requisitos de negócios mudam, novas coleções de recursos podem ser adicionadas, as relações entre recursos podem mudar e a estrutura dos dados em recursos pode ser alterada. Atualizar uma API da Web para lidar com novos requisitos é um processo relativamente simples, mas você deve considerar os efeitos que essas alterações terão nos aplicativos cliente que consomem a API da Web. Embora o desenvolvedor que projeta e implementa uma API da Web tenha controle total sobre essa API, o desenvolvedor não tem o mesmo grau de controle sobre os aplicativos cliente que podem ser criados por organizações de terceiros que operam remotamente.

O controle de versão permite que uma API da Web indique os recursos e recursos que ela expõe. Um aplicativo cliente pode então enviar solicitações para uma versão específica de um recurso ou recurso. Há várias abordagens para implementar o controle de versão:

  • Controlo de versões de URI
  • Controlo de versões de cadeia de consulta
  • Controlo de versões do cabeçalho

A cadeia de caracteres de consulta e o controle de versão de URI são os mais simples de implementar. O controle de versão de cabeçalho é uma boa abordagem. No entanto, o controle de versão de cabeçalho não é tão explícito e direto quanto o controle de versão de URI. Como o controle de versão de URL é o mais simples e explícito, o aplicativo de exemplo eShopOnContainers usa o controle de versão de URI.

Com o controle de versão de URI, como no aplicativo de exemplo eShopOnContainers, cada vez que você modifica a API da Web ou altera o esquema de recursos, adiciona um número de versão ao URI de cada recurso. Os URIs existentes devem continuar a operar como antes, retornando recursos que estejam em conformidade com o esquema que corresponde à versão solicitada.

Como mostrado no exemplo de código a seguir, a versão pode ser definida usando o atributo Route no controlador de API Web, que torna a versão explícita no URI (v1 neste caso).

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

Esse mecanismo de controle de versão é simples e depende do servidor roteando a solicitação para o ponto de extremidade apropriado. No entanto, para um controle de versão mais sofisticado e o melhor método ao usar REST, você deve usar hipermídia e implementar HATEOAS (Hypertext as the Engine of Application State).

Recursos adicionais

Gerando metadados de descrição do Swagger a partir de sua API Web principal do ASP.NET

Swagger é uma estrutura de código aberto comumente usada apoiada por um grande ecossistema de ferramentas que ajuda você a projetar, criar, documentar e consumir suas APIs RESTful. Ele está se tornando o padrão para o domínio de metadados de descrição de APIs. Você deve incluir metadados de descrição do Swagger com qualquer tipo de microsserviço, seja microsserviços controlados por dados ou microsserviços controlados por domínio mais avançados (conforme explicado na seção a seguir).

O coração do Swagger é a especificação Swagger, que são metadados de descrição da API em um arquivo JSON ou YAML. A especificação cria o contrato RESTful para sua API, detalhando todos os seus recursos e operações em um formato legível por humanos e por máquina para facilitar o desenvolvimento, a descoberta e a integração.

A especificação é a base da OpenAPI Specification (OAS) e é desenvolvida em uma comunidade aberta, transparente e colaborativa para padronizar a maneira como as interfaces RESTful são definidas.

A especificação define a estrutura de como um serviço pode ser descoberto e como seus recursos são compreendidos. Para obter mais informações, incluindo um editor da Web e exemplos de especificações do Swagger de empresas como Spotify, Uber, Slack e Microsoft, consulte o site do Swagger (https://swagger.io).

Porquê usar Swagger?

Os principais motivos para gerar metadados do Swagger para suas APIs são os seguintes.

Capacidade de outros produtos consumirem e integrarem automaticamente suas APIs. Dezenas de produtos e ferramentas comerciais e muitas bibliotecas e estruturas suportam o Swagger. A Microsoft tem produtos e ferramentas de alto nível que podem consumir automaticamente APIs baseadas em Swagger, como as seguintes:

  • AutoRest. Você pode gerar automaticamente classes de cliente .NET para chamar Swagger. Essa ferramenta pode ser usada a partir da CLI e também se integra ao Visual Studio para facilitar o uso por meio da GUI.

  • Microsoft Flow. Você pode usar e integrar automaticamente sua API em um fluxo de trabalho de alto nível do Microsoft Flow, sem a necessidade de habilidades de programação.

  • Microsoft PowerApps. Você pode consumir automaticamente sua API a partir de aplicativos móveis PowerApps criados com o PowerApps Studio, sem a necessidade de habilidades de programação.

  • Aplicativos Lógicos do Serviço de Aplicativo do Azure. Você pode usar e integrar automaticamente sua API em um Aplicativo Lógico do Serviço de Aplicativo do Azure, sem a necessidade de habilidades de programação.

Capacidade de gerar automaticamente documentação de API. Ao criar APIs RESTful de grande escala, como aplicativos complexos baseados em microsserviços, você precisa lidar com muitos pontos de extremidade com diferentes modelos de dados usados nas cargas úteis de solicitação e resposta. Ter uma documentação adequada e ter um explorador de API sólido, como acontece com o Swagger, é fundamental para o sucesso da sua API e adoção pelos desenvolvedores.

Os metadados do Swagger são o que o Microsoft Flow, o PowerApps e os Aplicativos Lógicos do Azure usam para entender como usar APIs e se conectar a elas.

Há várias opções para automatizar a geração de metadados do Swagger para ASP.NET aplicativos de API REST Core, na forma de páginas de ajuda de API funcionais, com base em swagger-ui.

Provavelmente o mais conhecido é o Swashbuckle, que atualmente é usado no eShopOnContainers e abordaremos com alguns detalhes neste guia, mas também há a opção de usar o NSwag, que pode gerar clientes Typescript e C# API, bem como controladores C#, a partir de uma especificação Swagger ou OpenAPI e até mesmo verificando o .dll que contém os controladores, usando NSwagStudio.

Como automatizar a geração de metadados do API Swagger com o pacote NuGet Swashbuckle

Gerar metadados Swagger manualmente (em um arquivo JSON ou YAML) pode ser um trabalho tedioso. No entanto, você pode automatizar a descoberta de API de ASP.NET serviços de API da Web usando o pacote NuGet do Swashbuckle para gerar dinamicamente metadados da API do Swagger.

O Swashbuckle gera automaticamente metadados Swagger para seus projetos de API Web ASP.NET. Ele dá suporte a projetos de API Web ASP.NET Core e à API Web ASP.NET tradicional e qualquer outro sabor, como Aplicativo de API do Azure, Aplicativo Móvel do Azure, microsserviços do Azure Service Fabric baseados em ASP.NET. Ele também suporta API Web simples implantada em contêineres, como no aplicativo de referência.

O Swashbuckle combina o API Explorer e o Swagger ou swagger-ui para fornecer uma rica experiência de descoberta e documentação para seus consumidores de API. Além de seu mecanismo gerador de metadados Swagger, o Swashbuckle também contém uma versão incorporada do swagger-ui, que servirá automaticamente assim que o Swashbuckle for instalado.

Isso significa que você pode complementar sua API com uma boa interface do usuário de descoberta para ajudar os desenvolvedores a usar sua API. Ele requer uma pequena quantidade de código e manutenção porque é gerado automaticamente, permitindo que você se concentre na construção de sua API. O resultado para o API Explorer se parece com a Figura 6-8.

Captura de tela do Swagger API Explorer exibindo a API do eShopOContainers.

Figura 6-8. Swashbuckle API Explorer baseado em metadados Swagger — microsserviço de catálogo eShopOnContainers

A documentação da API da interface do usuário do Swagger gerada pelo Swashbuckle inclui todas as ações publicadas. O explorador de API não é a coisa mais importante aqui. Depois de ter uma API da Web que pode descrever-se em metadados do Swagger, sua API pode ser usada perfeitamente a partir de ferramentas baseadas no Swagger, incluindo geradores de código de classe proxy cliente que podem ter como alvo muitas plataformas. Por exemplo, como mencionado, o AutoRest gera automaticamente classes de cliente .NET. Mas ferramentas adicionais como swagger-codegen também estão disponíveis, que permitem a geração de código de bibliotecas de clientes de API, stubs de servidor e documentação automaticamente.

Atualmente, o Swashbuckle consiste em cinco pacotes NuGet internos sob o metapacote de alto nível Swashbuckle.AspNetCore para aplicativos ASP.NET Core.

Depois de instalar esses pacotes NuGet em seu projeto de API Web, você precisa configurar o Swagger na classe Program.cs , como no seguinte código simplificado :

// 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");
    });
}

Feito isso, você pode iniciar seu aplicativo e procurar os seguintes pontos de extremidade JSON e UI do Swagger usando URLs como estas:

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

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

Você viu anteriormente a interface do usuário gerada criada pelo Swashbuckle para uma URL como http://<your-root-url>/swagger. Na Figura 6-9, você também pode ver como pode testar qualquer método de API.

Captura de tela da interface do usuário do Swagger mostrando as ferramentas de teste disponíveis.

Figura 6-9. Swashbuckle UI testando o método Catalog/Items API

O detalhe da API da interface do usuário do Swagger mostra uma amostra da resposta e pode ser usado para executar a API real, o que é ótimo para a descoberta do desenvolvedor. Para ver os metadados JSON do Swagger gerados a partir do microsserviço eShopOnContainers (que é o que as ferramentas usam abaixo), faça uma solicitação http://<your-root-url>/swagger/v1/swagger.json usando a extensão Visual Studio Code: REST Client.

Recursos adicionais

AnteriorSeguinte