BLOG | NGINX

Os benefícios de uma abordagem de Prioridade à API para a construção de microsserviços

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Andrew Stiefel Miniatura
André Stiefel
Publicado em 19 de janeiro de 2023

As APIs são o tecido conjuntivo dos aplicativos nativos da nuvem – o meio pelo qual os microsserviços componentes de um aplicativo se comunicam. À medida que os aplicativos crescem e se expandem, também aumenta o número de microsserviços e APIs. Embora esse seja um resultado inevitável na maioria dos casos, ele cria desafios significativos para as equipes de operações de plataforma responsáveis por garantir a confiabilidade, escalabilidade e segurança dos aplicativos modernos. Chamamos esse problema de proliferação de API e escrevemos sobre isso em uma postagem anterior do blog .

Como primeira tentativa de resolver a proliferação de APIs, uma organização pode tentar usar uma abordagem de cima para baixo implementando ferramentas para descoberta e correção automatizadas de APIs. Embora isso seja eficaz no curto prazo, muitas vezes impõe uma carga indevida às equipes responsáveis por criar e operar APIs e microsserviços. Eles precisam retrabalhar microsserviços e APIs existentes para resolver problemas de segurança e conformidade ou passar por um árduo processo de revisão para obter as aprovações necessárias. É por isso que muitas grandes organizações de software adotam uma abordagem descentralizada que usa governança adaptativa para dar aos desenvolvedores a autonomia de que precisam .

Em vez de implementar salvaguardas de última hora, uma abordagem de baixo para cima para resolver o problema é mais eficaz a longo prazo. As equipes que criam e operam APIs para diferentes microsserviços e aplicativos são as primeiras a se envolver e geralmente começam adotando uma abordagem API-first para o desenvolvimento de software em sua organização.

O que é prioridade à API?

As APIs existem há décadas. Mas elas não são mais simplesmente “interfaces de programação de aplicativos”. No fundo, as APIs são interfaces de desenvolvedor. Como qualquer interface de usuário, as APIs precisam de planejamento, design e testes. API‑first significa reconhecer e priorizar a importância da conectividade e da simplicidade em todas as equipes que operam e usam APIs. Ele prioriza a comunicação, a reutilização e a funcionalidade para consumidores de API, que quase sempre são desenvolvedores.

Existem muitos caminhos para API‑first , mas uma abordagem orientada ao design para o desenvolvimento de software é o objetivo final para a maioria das empresas que embarcam em uma jornada API‑first. Na prática, essa abordagem significa que as APIs são completamente definidas antes da implementação. O trabalho começa com o design e a documentação de como a API funcionará. A equipe depende do artefato resultante, geralmente chamado de contrato de API , para informar como eles implementam a funcionalidade do aplicativo.

Explore técnicas de design para dar suporte a uma abordagem API-first para desenvolvimento de software que seja durável e flexível no Capítulo 1 do e-book Mastering API Architecture da O'Reilly, cortesia da NGINX.

O valor da API-First para organizações

Uma estratégia de API em primeiro lugar geralmente é ideal para arquiteturas de microsserviços porque garante que os ecossistemas de aplicativos comecem a vida como sistemas modulares e reutilizáveis. A adoção de um modelo de desenvolvimento de software API-first oferece benefícios significativos para desenvolvedores e organizações, incluindo:

  • Maior produtividade do desenvolvedor – As equipes de desenvolvimento podem trabalhar em paralelo, atualizando aplicativos de back-end sem impactar as equipes que trabalham em outros microsserviços que dependem das APIs dos aplicativos. A colaboração geralmente é mais fácil em todo o ciclo de vida da API, pois cada equipe pode consultar o contrato de API estabelecido.
  • Experiência aprimorada do desenvolvedor – O design API‑first prioriza a experiência do desenvolvedor, garantindo que uma API seja lógica e bem documentada. Isso cria uma experiência perfeita para os desenvolvedores quando eles interagem com uma API. Saiba por que é tão importante para as equipes de Platform Ops levar em consideração a experiência do desenvolvedor de API<.htmla>.
  • Governança e segurança consistentes – Arquitetos de nuvem e plataforma podem organizar o ecossistema de API de forma consistente incorporando regras de segurança e governança durante a fase de design da API. Isso evita as revisões dispendiosas necessárias quando problemas são descobertos mais tarde no processo de software.
  • Qualidade de software aprimorada – Projetar APIs primeiro garante que os requisitos de segurança e conformidade sejam atendidos no início do processo de desenvolvimento, bem antes de a API estar pronta para ser implantada na produção. Com menos necessidade de corrigir falhas de segurança na produção, suas equipes de operações, qualidade e engenharia de segurança têm mais tempo para trabalhar diretamente com as equipes de desenvolvimento para garantir que os padrões de qualidade e segurança sejam atendidos na fase de design.
  • Tempo de comercialização mais rápido – Com menos dependências e uma estrutura consistente para comunicação entre serviços, diferentes equipes podem criar e melhorar seus serviços com muito mais eficiência. Uma especificação de API consistente e legível por máquina é uma ferramenta que pode ajudar desenvolvedores e equipes de operações de plataforma a trabalhar melhor juntos .

No geral, adotar uma abordagem API-first pode ajudar uma empresa a construir uma arquitetura de microsserviços mais flexível, escalável e segura.

Como a adoção de uma especificação de API comum pode ajudar

No cenário típico de microsserviços e APIs empresariais, há mais componentes em jogo do que uma equipe de operações de plataforma consegue monitorar diariamente. Adotar uma especificação de API padrão e legível por máquina ajuda as equipes a entender, monitorar e tomar decisões sobre as APIs que operam atualmente em seus ambientes.

Adotar uma especificação de API comum também pode ajudar a melhorar a colaboração com as partes interessadas durante a fase de design da API. Ao produzir um contrato de API e formalizá-lo em uma especificação padrão, você pode garantir que todas as partes interessadas estejam na mesma página sobre como uma API funcionará. Também facilita o compartilhamento de definições e recursos reutilizáveis entre equipes.

Hoje, existem três especificações comuns de API, cada uma delas suportando a maioria dos tipos de APIs:

  • OpenAPI – descrições JSON ou YAML de todas as APIs da web e webhooks
  • AsyncAPI – descrições JSON ou YAML de APIs orientadas a eventos
  • Esquema JSON – descrições JSON dos objetos de esquema usados para APIs

As APIs REST compõem a maior parte das APIs em produção hoje e a Especificação OpenAPI é a maneira padrão de escrever uma definição de API para uma API REST. Ela fornece um contrato legível por máquina que descreve como uma determinada API funciona. A especificação OpenAPI é amplamente suportada por uma variedade de ferramentas de gerenciamento de API e gateway de API, incluindo NGINX. O restante deste blog se concentrará em como você pode usar a especificação OpenAPI para realizar alguns casos de uso importantes.

A especificação OpenAPI é um formato de código aberto para definir APIs em JSON ou YAML. Você pode incluir uma ampla gama de características de API, conforme ilustrado pelo seguinte exemplo simples de API. Aqui, uma simples solicitação HTTP GET retorna uma lista de itens em uma lista de compras imaginária.

API aberta: 3.0.0info:
versão: 1.0.0
título: API de lista de compras
descrição: Um exemplo de API para ilustrar a especificação OpenAPI

servers:
url: https://api.example.io/v1

paths:
/list:
get:
description: Retorna uma lista de coisas na sua lista de compras
respostas:
        '200':
descrição: Retornou uma lista com sucesso
conteúdo:
esquema:
tipo: array
itens:
tipo: objeto
propriedades:
item_name:
tipo: string

As definições que seguem a especificação OpenAPI são legíveis tanto por humanos quanto por máquinas. Isso significa que há uma única fonte de verdade que documenta como cada API funciona, o que é especialmente importante em organizações com muitas equipes criando e operando APIs. É claro que, para gerenciar, governar e proteger APIs em escala, você precisa garantir que o restante das ferramentas em sua plataforma de API – gateways de API, portais de desenvolvedores e segurança avançada – também sejam compatíveis com a especificação OpenAPI.

Aprofunde-se em como projetar APIs REST usando a especificação OpenAPI no Capítulo 1 de Mastering API Architecture .

Benefícios da adoção de uma especificação de API comum

Usar uma especificação de API comum, como a Especificação OpenAPI, tem vários benefícios:

  • Interoperabilidade aprimorada – Uma especificação comum e legível por máquina significa que diferentes sistemas e clientes podem consumir e usar o contrato de API. Isso facilita para as equipes de operações de plataforma integrar, gerenciar e monitorar arquiteturas complexas.
  • Documentação consistente – O contrato da API é documentado em um formato padrão, incluindo os endpoints, formatos de solicitação e resposta e outros detalhes relevantes. Muitos sistemas podem usar o contrato para gerar documentação abrangente, fornecendo clareza e facilitando para os desenvolvedores entenderem como usar a API.
  • Melhores testes – As especificações da API podem ser usadas para gerar e executar testes automaticamente, o que pode ajudar a garantir que a implementação da API esteja de acordo com o contrato e funcionando conforme o esperado. Isso pode ajudar a identificar problemas com uma API antes que ela seja publicada para produção.
  • Segurança aprimorada – Ferramentas de segurança avançadas podem usar a especificação OpenAPI para analisar o tráfego da API e o comportamento do usuário. Eles podem aplicar segurança positiva<.htmla> verificando se as solicitações de API estão em conformidade com os métodos, pontos de extremidade e parâmetros suportados pelo ponto de extremidade da API. O tráfego não conforme é bloqueado por padrão, reduzindo o número de chamadas que seus microsserviços precisam processar.
  • Evolução mais fácil – As especificações da API podem ajudar a facilitar a evolução do contrato e do aplicativo da API ao longo do tempo, fornecendo uma maneira clara e padronizada de documentar e comunicar mudanças em formatos legíveis por máquinas e humanos. Quando combinado com práticas adequadas de controle de versão, isso ajuda a minimizar os impactos das alterações da API nos consumidores da API e garante que a API permaneça compatível com versões anteriores.

No geral, usar uma especificação de API comum pode ajudar a melhorar a interoperabilidade, a documentação, os testes, a segurança e a evolução gradual de uma API.

Como o NGINX oferece suporte ao desenvolvimento de software API-First

O NGINX fornece um conjunto de ferramentas leves e nativas da nuvem que facilitam a operação, o monitoramento, o governo e a proteção de APIs em escala. Por exemplo, o API Connectivity Manager , parte do F5 NGINX Management Suite , fornece um único plano de gerenciamento para suas operações de API. Com ele você pode configurar e gerenciar gateways de API e portais de desenvolvedores. Como uma ferramenta API-first, cada função é acessível via API REST, facilitando a automação e integração de CI/CD para equipes de DevOps .

Usando a especificação OpenAPI, você pode usar produtos NGINX para:

Use a especificação OpenAPI para publicar uma API no gateway da API e documentação no portal do desenvolvedor e para definir políticas de segurança para o WAF por meio de pipelines de CI/CD ou da interface do usuário

Publicar APIs no API Gateway

O API Connectivity Manager usa a especificação OpenAPI para otimizar a publicação e o gerenciamento de APIs. Os desenvolvedores de API podem publicar APIs no gateway de API usando a interface de usuário do NGINX Management Suite ou a API REST totalmente declarativa. As APIs são adicionadas ao gateway como proxies de API, que contêm todas as configurações de entrada, backend e roteamento que o gateway de API precisa para direcionar solicitações de API de entrada para o microsserviço de backend. Você pode usar a API REST para implantar e gerenciar APIs como código criando scripts simples de automação de CI/CD com ferramentas como o Ansible.

Para obter instruções completas sobre como usar a especificação OpenAPI para publicar uma API, consulte a documentação do API Connectivity Manager .

Gerar documentação de API para o Portal do Desenvolvedor

Manter a documentação costuma ser uma dor de cabeça para as equipes de API. Mas a documentação desatualizada nos portais de desenvolvedores também é um sintoma importante da proliferação de APIs. O API Connectivity Manager usa a especificação OpenAPI para gerar documentação automaticamente e publicá-la no portal do desenvolvedor, economizando tempo dos desenvolvedores de API e garantindo que os consumidores de API sempre possam encontrar o que precisam. Você pode carregar arquivos de especificação OpenAPI diretamente por meio da interface de usuário do API Connectivity Manager ou da API REST.

Para obter instruções completas sobre como publicar a documentação da API no portal do desenvolvedor, consulte a documentação do API Connectivity Manager .

Aplique Segurança Positiva para Proteger Endpoints de API

Você também pode usar a especificação OpenAPI para verificar se as solicitações de API para o gateway de API do NGINX Plus estão em conformidade com o que uma API suporta. Ao aplicar segurança positiva (um modelo de segurança que define o que é permitido e bloqueia todo o resto), você pode evitar que solicitações maliciosas investiguem seus serviços de backend em busca de possíveis vulnerabilidades.

No momento em que este artigo foi escrito, você não pode usar o API Connectivity Manager para configurar o NGINX App Protect WAF ; essa funcionalidade estará disponível no final de 2023. No entanto, você pode usar o Instance Manager (outro módulo do NGINX Management Suite) e a especificação OpenAPI para escrever políticas personalizadas para seu WAF. Para obter informações adicionais, consulte a documentação do NGINX App Protect WAF e do Instance Manager .

Saiba mais sobre segurança de API e modelagem de ameaças, e como aplicar autenticação e autorização no gateway de API no Capítulo 7 de Mastering API Architecture .

Resumo

Uma abordagem API-first para criar microsserviços e aplicativos pode beneficiar sua organização de muitas maneiras. Alinhar equipes em torno da especificação OpenAPI (ou outra especificação de API comum que seja legível tanto por humanos quanto por máquinas) ajuda a permitir a colaboração, a comunicação e as operações entre as equipes.

Os aplicativos modernos operam em ambientes complexos e nativos da nuvem. Adotar ferramentas que permitam uma abordagem API-first para operar APIs é um passo fundamental para concretizar sua estratégia API-first. Com o NGINX, você pode usar a especificação OpenAPI para gerenciar suas APIs em escala entre equipes e ambientes distribuídos.

Inicie uma avaliação gratuita de 30 dias do NGINX Management Suite , que inclui acesso ao API Connectivity Manager , ao NGINX Plus como um gateway de API e ao NGINX App Protect para proteger suas APIs.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."