Partilhar via

Criando, evoluindo e versionando APIs e contratos de microsserviço

  • 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

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

Uma API de microsserviço é um contrato entre o serviço e seus clientes. Você só poderá evoluir um microsserviço de forma independente se não quebrar seu contrato de API, e é por isso que o contrato é tão importante. Se você alterar o contrato, isso afetará seus aplicativos cliente ou seu API Gateway.

A natureza da definição de API depende do protocolo que você está usando. Por exemplo, se você estiver usando mensagens, como AMQP, a API consiste nos tipos de mensagem. Se você estiver usando serviços HTTP e RESTful, a API consistirá nas URLs e nos formatos JSON de solicitação e resposta.

No entanto, mesmo que você esteja atento ao seu contrato inicial, uma API de serviço precisará mudar ao longo do tempo. Quando isso acontece — e especialmente se sua API for uma API pública consumida por vários aplicativos cliente — você normalmente não pode forçar todos os clientes a atualizar para seu novo contrato de API. Normalmente, você precisa implantar incrementalmente novas versões de um serviço de forma que as versões antiga e nova de um contrato de serviço sejam executadas simultaneamente. Portanto, é importante ter uma estratégia para o controle de versão do serviço.

Quando as alterações de API são pequenas, como se você adicionar atributos ou parâmetros à sua API, os clientes que usam uma API mais antiga devem alternar e trabalhar com a nova versão do serviço. Você pode ser capaz de fornecer valores padrão para quaisquer atributos ausentes que são necessários, e os clientes podem ser capazes de ignorar quaisquer atributos de resposta extra.

No entanto, às vezes você precisa fazer alterações importantes e incompatíveis em uma API de serviço. Como você pode não conseguir forçar aplicativos ou serviços cliente a atualizar imediatamente para a nova versão, um serviço deve oferecer suporte a versões mais antigas da API por algum período. Se você estiver usando um mecanismo baseado em HTTP, como REST, uma abordagem é incorporar o número da versão da API na URL ou em um cabeçalho HTTP. Em seguida, você pode decidir entre implementar ambas as versões do serviço simultaneamente na mesma instância de serviço ou implantar instâncias diferentes que manipulam cada uma uma versão da API. Uma boa abordagem para essa funcionalidade é o padrão Mediator (por exemplo, biblioteca MediatR) para separar as diferentes versões de implementação em manipuladores independentes.

Finalmente, se você estiver usando uma arquitetura REST, a Hypermedia é a melhor solução para versionar seus serviços e permitir APIs evolutivas.

Recursos adicionais

AnteriorSeguinte