As APIs e endpoints sempre foram um assunto bastante discutido entre desenvolvedores frontend e backend. Para desenvolver aplicativos e serviços úteis e sustentáveis, as APIs têm sido meios e facilitadores poderosos.

As APIs facilitam a transmissão de dados entre vários artefatos de software para resolver os problemas dos clientes. Quase todos os produtos modernos baseados na web oferecem suas próprias APIs para interagir e integrar seus serviços diretamente em qualquer projeto.

Para manter-se atualizado com seus concorrentes e fornecer aos seus usuários uma experiência perfeita entre plataformas, você precisa conhecer e dominar o jogo de APIs.

Este guia irá esclarecer o termo e ajudá-lo a entender o que é um endpoint de API, como você pode consumir uma API disponível publicamente e as várias maneiras de proteger e monitorar seus endpoints de API.

Entendendo os endpoints de API

“API” é a abreviação de “Application Programming Interface.” É essencialmente um conjunto de regras que permitem que um aplicativo compartilhe seus dados com outros aplicativos. Em outras palavras, uma API permitirá que você “compartilhe coisas” entre o seu aplicativo e um aplicativo de terceiros.

Um endpoint de API é uma localização digital exposta pela API a partir da API que recebe e responde as consultas. Cada endpoint é uma URL (Uniform Resource Locator) que fornece a localização de um recurso no servidor da API.

Para entender o propósito e o uso das APIs, vamos primeiro entender como elas funcionam.

Como funcionam as APIs

Para que dois aplicativos de software se comuniquem pela internet, um aplicativo (indicado como cliente) envia uma solicitação para os endpoints de API do outro aplicativo (indicado como servidor). Dependendo das habilidades de API, o cliente pode solicitar um recurso de um banco de dados ou pedir ao servidor para executar alguma ação em seu ambiente e retornar os resultados.

Ao receber o resultado do cliente, a API (ou o servidor) executa a operação solicitada e envia o resultado da operação de volta para o cliente na forma de uma resposta. Esta resposta também pode incluir quaisquer recursos que o cliente tenha solicitado.

Pode haver vários tipos de APIs, incluindo REST, SOAP, e GraphQL. Todas elas funcionam de uma forma diferente, mas seu propósito ainda é o mesmo: facilitar a comunicação entre entidades baseadas na web. Neste guia, abordaremos principalmente sobre as APIs REST, já que elas estão entre as APIs mais populares do mundo.

Qual é a diferença entre uma API e um Endpoint?

Isso nos leva à próxima e mais comum pergunta: Qual é a diferença entre uma API e um endpoint?

Uma API é um conjunto de protocolos e ferramentas para facilitar a interação entre dois aplicativos. Um endpoint é um lugar na API onde a troca acontece. Endpoints são URIs (Uniform Resource Identifiers) em uma API que um aplicativo pode acessar.

Todas as APIs têm endpoints. Sem um endpoint, seria impossível interagir com uma API.

Como os Endpoints funcionam com as APIs?

Para expandir o seu entendimento de APIs e endpoints, vamos utilizar um pequeno exemplo.

Considere o Cat Facts API. Este API fornece fatos aleatórios sobre gatos. No entanto, ela lista vários endpoints usando os quais você pode solicitar informações categorizadas. Existem três endpoints disponíveis:

  • /fact: Retorna um cat fact único e aleatório.
  • /facts: Devolve uma lista de cat facts aleatórios.
  • /breeds: Devolve uma lista de cat breeds.

Para fazer um pedido a esta API e retornar um cat fact, você precisa anexar o endpoint correto (que é /fact) à URL base da API (que é https://catfact.ninja/). Isso lhe dará a seguinte URL de endpoint: https://catfact.ninja/fact

Se você enviar uma solicitação GET para a URL acima, você receberá um resultado similar:


{
    "fact": "Spanish-Jewish folklore recounts that Adamu2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the childu2019s breath.",
    "length": 245
}

Você não teria conseguido obter esses dados caso tivesse acessado outro endpoint, como /breeds. É dessa forma que os endpoints ajudam a interagir e organizar os recursos fornecidos por uma API – cada endpoint é específico para uma porção particular dos dados.

Por que os Endpoints de API são importantes?

A transferência de dados e o compartilhamento de recursos são alguns dos fundamentos essenciais da internet. A cada dia, mais e mais processos e aplicativos são adicionados à rede global, aumentando o valor da rede ao compartilhar coisas.

Sem APIs, nada disso seria possível. As APIs fornecem um poderoso meio de comunicação e interação entre aplicativos baseados na web.

Os endpoints de API, por sua vez, ajudam a determinar a localização exata dos recursos na API. Eles ajudam os desenvolvedores de API a organizar os recursos disponíveis e controlar o acesso do consumidor também. Portanto, o desempenho e a produtividade dos aplicativos que consomem APIs dependem diretamente do design e desempenho dos endpoints de API.

Trabalhando com os Endpoints de API existentes

Geralmente, você será obrigado a consumir APIs pré-construídas. Para fazer isso eficientemente, você precisa entender como localizar os endpoints e encontrar seu caminho com as várias regras de versionamento usadas na indústria. Esta seção irá guiá-lo através delas.

Localizando um Endpoint de API

Localizar um endpoint de API é um trabalho simples se você tiver acesso à documentação da API. Às vezes, a documentação pode listar os endpoints simplesmente com descrições curtas ao lado de cada um. Em outros casos (como o Swagger), a documentação pode ser mais complexa e poderosa, e você pode ser capaz de testar os endpoints diretamente da página de documentação.

De qualquer forma, é do seu melhor interesse dedicar tempo para entender o propósito de cada endpoint antes de começar a usá-lo. Isso pode ajudá-lo a evitar a maioria dos erros e aumentar sua eficiência.

Versão do Endpoint de API

Assim como outros artefatos de software, as APIs também têm versões. O versionamento ajuda a observar e analisar a API conforme ela cresce durante o processo de desenvolvimento. Ter acesso a versões antigas também pode ajudar a voltar para versões anteriores e estáveis em caso de uma atualização falha. Aqui estão algumas maneiras comuns pelas quais os endpoints da API são versionados.

Caminho do URI

Uma das maneiras mais populares de se obter uma versão dos endpoints de API é incluir um número de versão no caminho do URI. Por exemplo:

http://example.com/api/1/resourcename

Você pode ver esta abordagem como uma forma de versionar globalmente os endpoints de API. Caso você use um subdomínio para à sua API, como, por exemplo:

http://api.example.com/resourcename

…você também pode colocar um indicador de versão em seu subdomínio, como este:

http://api-v2.example.com/resourcename

Como você pode ver, esta abordagem modifica a caminho URI da API, de modo que cada versão se comporta como um recurso independente. Isso significa que você pode acessar simultaneamente as duas versões da API conforme necessário e até mesmo armazená-las em cache independentemente para acesso mais rápido.

Ao incluir um número de versão no caminho da URI (e não no subdomínio), aqui está um formato interessante que você pode seguir para incluir mais informações:

MAJOR.MINOR.PATCH

Por exemplo, é assim que a API interna do nosso exemplo acima seria versionada:

http://example.com/api/1.2.3/resourcename

Agora, explicaremos o significado de cada um desses novos termos de versão e para que cada um serve:

  • MAJOR: Usado quando são feitas mudanças incompatíveis ou quebram a compatibilidade da API
  • MINOR: Para adicionar funcionalidade compatível com o passado
  • PATCH: Para correções de bugs compatíveis com as versões anteriores

A versão MAJOR é a versão usada na API pública. Normalmente, esse número é atualizado quando há mudanças grandes ou que quebram a compatibilidade da API. Internamente, essa mudança indica que uma nova instância ou recurso da API foi criado.

As versões MINOR e PATCH são usadas internamente para atualizações de compatibilidade com versões anteriores. Elas são normalmente atualizadas quando novas funcionalidades são introduzidas, ou quando pequenas alterações são feitas no mesmo recurso API. O número PATCH é atualizado especificamente para correções de bugs ou atualizações de resolução de problemas.

  • Benefícios:
    • O acesso simultâneo a múltiplas versões é possível.
    • A nomenclatura URL segue uma convenção simples e padrão, portanto os endpoints de API são altamente acessíveis.
  • Limitações:
    • No caso de alterações significativas que quebram a compatibilidade, essa abordagem leva ao desenvolvimento de um novo recurso de API completamente separado. Isso pode adicionar um peso significativo à sua base de código.
Parâmetros de consulta

Outra alternativa para fazer a versão de uma REST API é colocar o número da versão nos parâmetros de consulta da URL. Essa abordagem permite que o ambiente do servidor acesse o número da versão necessário como qualquer outro parâmetro de consulta e o use para redirecionar o fluxo de controle no aplicativo. Além disso, não é necessário criar um novo recurso de API completamente separado, pois seu recurso de API existente pode ler o número da versão e agir conforme necessário.

A URL do exemplo anterior, quando versionada usando parâmetros de consulta, ficaria assim:

http://example.com/api/resourcename?version=1
  • Benefícios:
    • Muito fácil de implementar em código.
    • Você pode rapidamente definir a versão mais recente.
  • Limitações:
    • O uso de parâmetros pode ser mais desafiador para rotear solicitações para a versão correta do que a versão do caminho do URI.
Cabeçalhos personalizados

Você também pode fazer a versão REST APIs, fornecendo cabeçalhos personalizados com o número da versão como um atributo. A diferença mais significativa entre este método e os dois mencionados anteriormente é que este não desorganiza a URL do endpoint com informações da versão.

É assim que o exemplo de antes pareceria quando versionado usando esta abordagem:

curl -H "Accepts-version: 2.0"

http://example.com/api/resourcename
  • Benefícios:
    • A URL não fica lotada de informações da versão
    • Os clientes podem codificar manualmente as URLs dos endpoints da API e escolher entre as versões por meio de cabeçalhos enquanto enviam rapidamente a solicitação
  • Limitações:
    • Você precisa definir cabeçalhos personalizados manualmente sempre que fizer qualquer solicitação
Negociação de conteúdo
A negociação de conteúdo permite que os desenvolvedores de APIs versionem uma única representação do recurso em vez de toda a API. Com isso, é possível ter um controle mais preciso sobre a versão do recurso. Além disso, assim como no método anterior, essa abordagem também remove a confusão nas URLs da API.

Assim é como nosso exemplo anterior ficaria quando versionado via negociação de conteúdo:

curl -H "Accept: application/vnd.kb.api+json; version=2"

http://example.com/api/resourcename

No entanto, os endpoints versionados usando esse método são mais difíceis de acessar do que aqueles com a abordagem URI. Além disso, o uso de cabeçalhos HTTP com tipos de mídia dificulta o teste da API em um navegador. E se o cabeçalho de conteúdo for opcional, pode causar confusão sobre qual versão os clientes receberão por padrão.

Suponha que você tenha lançado a versão v2 da sua API e tenha depreciado a versão anterior v1. Se um cliente não especificar a versão em sua solicitação, ele receberá o recurso v2, o que pode quebrar sua funcionalidade devido a problemas de compatibilidade não considerados. É por isso que a negociação de conteúdo geralmente não é recomendada como meio de versionamento de API.

  • Benefícios:
    • É possível versionar um único recurso, se necessário.
    • Cria uma área de código menor.
    • Não exige a modificação de regras de roteamento (URLs).
  • Limitações:
    • Os cabeçalhos HTTP com tipos de mídia dificultam testar e explorar os endpoints em um navegador.
    • Tenha em mente, também, que a falta de cabeçalho de conteúdo pode quebrar a funcionalidade do cliente.

Exemplo de um endpoint do API

Para entender melhor APIs e endpoints, ilustremos um exemplo usando a API do Twitter. Esta API expõe dados sobre tweets, mensagens diretas, usuários, e mais da plataforma de rede social. Ela oferece vários endpoints para realizar várias operações em seus dados.

Por exemplo, você pode usar o tweet lookup endpoint (https://api.twitter.com/2/tweets/{id}) ara recuperar o conteúdo de um tweet específico usando seu identificador exclusivo. Você também pode usar a API do Twitter para transmitir tweets públicos em tempo real para o seu aplicativo e atualizar os usuários sobre tópicos de interesse e específicos.

A API do Twitter oferece um endpoint de fluxo filtrado para este fim (https://api.twitter.com/2/tweets/search/stream). Eles também criaram um índice estendido de outros endpoints que você pode usar.

Como os Endpoints de API são protegidos?

Agora que você entende como os endpoints de API funcionam, é importante entender como protegê-los. Sem medidas de segurança adequadas, os endpoints da API podem violar seriamente as defesas do seu aplicativo e levar ao comprometimento de dados e recursos.

Aqui estão algumas sugestões básicas para garantir o acesso aos endpoints da sua API.

Hashing de senha unidirecional

Ao construir recursos web, você muitas vezes encontrará senhas como uma forma de autenticar entidades. Enquanto as senhas ajudam a proteger os dados dos aplicativos de seus usuários, você precisa proteger o armazenamento das senhas também para torná-las um meio de autenticação verdadeiramente eficaz.

Em geral, você nunca deve armazenar senhas como texto simples. No caso de uma quebra de segurança, todas as contas de usuário serão comprometidas se um agente mal-intencionado colocar suas mãos na tabela de pares de senhas e nomes de usuário.

Uma maneira de parar isso é codificá-las antes de armazená-las. Existem dois métodos de criptografia: simétrica e assimétrica.

Na criptografia simétrica, você pode usar a mesma chave de criptografia para bloquear e desbloquear o conteúdo. No entanto, isso não é aconselhável para senhas, uma vez que hackers persistentes e sofisticados podem facilmente quebrá-las.

A maneira recomendada de armazenar senhas é usando criptografia unidirecional ou “assimétrica”. Ao invés de empregar uma única chave de criptografia, uma função matemática é usada para codificar os dados.

A versão codificada é armazenada no banco de dados para que ninguém, incluindo seus administradores do servidor, possa decifrar as senhas e visualizá-las. Para autenticar usuários, a senha digitada é executada através da mesma função matemática, e os resultados são comparados para verificar se a senha digitada estava correta.

HTTPS

Suponha que seus endpoints de API são projetados para permitir que os consumidores falem com seus serviços. Nesse caso, você estará colocando eles em risco significativo ao não implementar HTTPS (ou outro protocolo de segurança similar).

As conexões de API normalmente trocam dados confidenciais, como senhas, chaves privadas e informações de pagamento. Esses dados podem ser facilmente roubados por ataques machine-in-the-middle ou técnicas de detecção de pacotes.

É por isso que você deve fazer questão de sempre escolher HTTPS sempre que disponível. Se seus aplicativos estão atualmente usando o protocolo HTTP, você deve considerar fortemente a migração para HTTPS. Não importa quão insignificante seja a conexão; ela sempre pode levar a um vazamento.

Você também deve considerar a possibilidade de obter um certificado TLS ou SSL para aumentar ainda mais a segurança da sua API.

Limite de taxa

Geralmente, estabelecer um limite para o número de vezes que sua API pode ser usada em um minuto é uma boa ideia. Ele ajuda a controlar o abuso de recursos e possui um modelo de preços controlado com base no tráfego de clientes.

Entretanto, uma das principais razões para implementar a limitação da taxa é evitar o uso excessivo de recursos automatizados, que geralmente é graças aos bots que podem enviar centenas ou milhares de pedidos simultâneos a cada segundo. A limitação de taxas também pode ajudá-lo a bloquear qualquer ataque DDoS lançado por esses bots.

A maioria dos frameworks de desenvolvimento web fornece middlewares limitadores de taxa que são fáceis de configurar. Mesmo que o seu framework não tenha um middleware, você pode obter um através de uma biblioteca de terceiros e configurá-lo rapidamente.

Além de cuidar dos bots, é também uma boa prática limitar o número permitido de solicitações ou dados recuperados a um número razoável. Fazer isso ajuda a prevenir o uso excessivo não intencional de recursos que podem ser acionados por erros manuais, tais como loops infinitos. Também ajuda a fornecer aos seus usuários uma disponibilidade uniforme – um pico no uso de um usuário não afeta a experiência de outros usuários.

Medidas de autenticação API

Sempre que você constrói uma API voltada para o público, você precisa implementar medidas de autenticação para evitar o uso indevido e abuso de seus serviços. Uma boa opção é o sistema OAuth2.

O sistema OAuth2 divide sua conta em recursos e permite que você forneça acesso controlado aos portadores de token de autenticação. Você pode definir estes tokens para expirar em determinadas durações – digamos, 24 horas – após as quais eles serão renovados. Isso assegura que mesmo que seu token seja vazado, a janela de uso limitado irá reduzir o impacto do vazamento.

Uma parte essencial da segurança da API é usar chaves de API para autenticar pedidos. Você pode definir chaves de API para limitar a taxa de chamadas à sua API e reduzir as chances de ataques DoS. Se você oferece um serviço de API pago, você pode usar chaves de API para fornecer acesso baseado nos planos que cada usuário comprou.

Você também deve considerar adequar os terminais internos de autenticação multi-fator, software antivírus e atualizações automáticas de aplicativos. Estas medidas simples irão contribuir muito para garantir que não haja quebra na qualidade dos serviços que você oferece.

Validação de entrada

Embora isso pareça uma coisa óbvia a ser feita ao construir qualquer aplicativo de software, um número surpreendente de APIs não consegue implementar isso corretamente. A validação de entrada refere-se não apenas à verificação de que os dados recebidos estão em um formato correto, mas também à observação de surpresas.

Um dos exemplos mais simples, porém mais comuns, é a injeção SQL. Não cobrir isso pode apagar todo o seu banco de dados caso a consulta errada for executada. Certifique-se de validar os dados de entrada para o formato adequado e retire os caracteres que possam indicar intenção maliciosa.

Outra coisa a ser observada é o tamanho da solicitação. No caso de solicitações POST, tentar aceitar e analisar uma entrada extremamente grande só irá sobrecarregar sua API. Você deve sempre se concentrar em validar o tamanho de uma requisição POST primeiro e retornar um código de erro apropriado e uma mensagem para o cliente, se necessário.

Filtragem de endereço IP

Se você oferece serviços B2B e seus clientes usam sua API de locais definidos globalmente, você deve considerar adicionar uma camada adicional de segurança aos seus sistemas, restringindo os endereços IP que acessam sua API, com base na localização deles.

Para novos locais e clientes, você precisará adicionar seus dados à sua lista de “locais permitidos”. Embora isso possa incluir fricção adicional ao processo de integração de seus clientes, isso irá contribuir muito para aumentar a segurança e, por sua vez, a qualidade da experiência deles.

Para minimizar ainda mais os riscos de segurança, você também deve considerar limitar as permissões dos clientes e o acesso ao mínimo necessário para as operações padrão. Da mesma forma, restrinja seu acesso HTTP para assegurar que clientes mal configurados não recebam nada mais do que as especificações da API e o código de acesso. Certifique-se de que sua API rejeita essas solicitações com um código de resposta 405.

Vale notar que uma grande parte de ciberataques ao redor do mundo é originário de um número limitado de países. Outra boa prática é bloquear o acesso aos seus recursos de tais locais inteiramente se você não tiver clientes lá.

Além disso, se você detectar um ataque, comece bloqueando os pedidos de GET/POST da região do atacante. A capacidade de restringir solicitações HTTP com base na localização do cliente está entre as formas mais rápidas de combater um ataque cibernético em andamento.

XDR (Extended Detection and Response)

A maioria das organizações emprega ferramentas tradicionais de segurança, como firewalls e técnicas de proteção/detecção de intrusão. Embora estas sejam rudimentares para qualquer sistema de segurança, elas não são projetadas explicitamente para APIs.

Uma nova tecnologia chamada XDR fornece uma abordagem de proteção em todos os seus ambientes de TI, incluindo seus endpoints de API. O XDR fornece às equipes de segurança, alertas em tempo real sobre comportamentos maliciosos, o que lhes permite investigar ataques rapidamente.

Aqui estão algumas maneiras pelas quais o XDT assegura os endpoints de API:

  • Monitoramento de HTTPS: XDR pode gerenciar certificados de segurança de seus endpoints e inspecionar as comunicações HTTP também. Quando ele detecta uma anomalia, ele pode rapidamente terminar a conexão ou tomar outras ações automatizadas.
  • Monitoramento de chamadas API: XDR pode acompanhar o número de chamadas de API feitas por seus clientes e notificar suas equipes de segurança quando detectar tendências suspeitas, mesmo dentro dos limites de taxa definidos.
  • JSON web token (JWT): JWT é um método padrão usado para representar com segurança a identidade de um usuário quando se comunica através de uma rede. XDR pode ajudar a identificar usuários através do JWT em suas redes sem ter que transmitir credenciais. Isso permite que você identifique contas de usuários em seu tráfego API e analise seu comportamento em busca de anomalias.
  • Filtragem de endereços IP: XDR se integra bem com bancos de dados de inteligência de ameaças e verifica as solicitações de entrada de endereços IP legítimos ou origens.
  • Validação de entrada: Mesmo que você não tenha implementado medidas adequadas de sanitização de entrada em seu serviço, as soluções XDR podem analisar automaticamente SQL ou outras consultas sensíveis a bancos de dados para detectar ataques de injeção, pará-los em seus rastros e notificar as equipes de segurança sobre eles.

Rotinas de manutenção

Existem algumas rotinas de manutenção geral que você pode configurar para melhorar a qualidade da segurança de suas APIs. Aqui estão algumas delas:

  • Limpe os dados: Elimine dados redundantes de usuários e funcionários de seus serviços. A limpeza de rotina de dados não é apenas uma boa prática, mas também ajuda a diminuir as chances de perda acidental ou corrupção de dados.
  • Realize atualizações regulares: Lembre-se de atualizar sua pilha de tecnologia e certificações de serviços regularmente. Você deve implementar patches de rotina para seus serviços de endpoint, e todas às suas licenças devem refletir os mais recentes padrões regulatórios e de conformidade.
  • Revise as medidas de segurança: Mantenha seus planos de recuperação e segurança atualizados. Elas devem refletir as últimas alterações ou adições à sua infraestrutura de rede com a maior frequência possível. Se você adiciona regularmente novos recursos para dispositivos móveis, IoT ou outros recursos no local, esta prática é ainda mais crítica.

Monitorando os Endpoints de API

Agora que você entende como construir, consumir e proteger endpoints de API, a próxima coisa essencial a saber é monitorá-los. O monitoramento é um conceito crucial aplicado através da dinâmica da engenharia de software para analisar e reforçar o crescimento de produtos técnicos.

Dicas, truques e melhores práticas

No caso de endpoints de API, o monitoramento pode ajudá-lo a proteger e otimizar seus endpoints para obter melhor desempenho e confiabilidade. Esta próxima seção irá guiá-lo por algumas das melhores práticas a serem seguidas ao instrumentar e monitorar endpoints de API.

1. Valide o tempo de atividade funcional

Geralmente, as equipes tendem a monitorar a disponibilidade ou tempo de atividade da API e tratá-lo como o padrão para medir a qualidade do serviço da API. No entanto, medir apenas a disponibilidade geral da API não é suficiente para os vários tipos de transações de troca de dados que ocorrem por meio da API. Você precisa monitorar a disponibilidade e o desempenho de todos os verbos (Criar, Ler, Atualizar, Excluir, etc.) individualmente para garantir que todos estejam operacionais.

Para fazer isso, você pode implementar ferramentas de monitoramento sintético com monitores de API de vários passos. Isso ajudará você a melhorar simultaneamente a disponibilidade da API e dos dados. Ao mesmo tempo, você deve lembrar que o monitoramento sintético usa um conjunto limitado e predefinido de chamadas de API para testes. Portanto, o tráfego real do mundo real pode diferir dos inputs definidos no monitoramento sintético.

2. Lembre-se de monitorar as dependências da API

Nem todas as APIs são criadas independentemente. Muitas vezes, é necessário consumir APIs de terceiros ao criar a sua própria. Mesmo que você possa monitorar o seu código em profundidade, é fácil esquecer de acompanhar o comportamento das APIs de terceiros.

Portanto, você também deve acompanhar as respostas das APIs de terceiros. Em nossa experiência, dependências defeituosas causam muitos problemas sempre que deixamos de analisá-las independentemente.

3. Implemente testes automatizados no monitoramento de API

Se você tem um pipeline CI/CD bem definido, provavelmente já conhece a importância da automação. Portanto, é melhor se você puder configurar testes automatizados para seus endpoints de API juntamente com o monitoramento. Você deve considerar adicionar um passo adicional em seus pipelines CI/CD para executar testes automatizados em seus endpoints antes de um lançamento. Embora isso tenha se tornado uma norma nos tempos atuais, você deve verificar se o implementou ou não.

4. Escolha uma ferramenta com uma forte funcionalidade de alerta

Com a variedade de ferramentas que estão disponíveis no mercado atual, pode ser complicado encontrar a ferramenta certa para o seu caso de uso. Para facilitar a sua busca, aqui está uma regra rápida a ser lembrada: procure sempre por uma forte capacidade de alerta. Se à sua ferramenta selecionada não alerta você adequadamente sobre os problemas recebidos, você terá que perder tempo intervindo consistentemente para verificar se algum evento ocorreu. A automação nesse domínio ajuda muito a aumentar a produtividade da sua equipe.

5. Dê prioridade às ferramentas que são diretamente integráveis ao seu pipeline CI/CD

Você deve considerar a integração do monitoramento em cada etapa do seu Pipeline CI/CD para analisar a eficiência de seus processos DevOps. Para isso, você precisa selecionar cuidadosamente as ferramentas que oferecem tal funcionalidade.

Para verificar se a ferramenta escolhida possui essa funcionalidade, procure a lista de integrações de terceiros fornecida. Se o seu servidor CI, como Jenkins ou GitHub, é suportado pela ferramenta, você está pronto para começar!

6. Nunca comprometa a privacidade da API

Algumas ferramentas de monitoramento de API usam plataformas SaaS de terceiros que exigem que os clientes abram determinadas portas em seus firewalls para monitorar APIs internas de outra forma inacessíveis. No entanto, isso representa um grande risco de segurança. Qualquer pessoa com conhecimento dessas portas pode usá-las para obter acesso não autorizado aos seus sistemas.

É por isso que é fundamental escolher uma boa solução de monitoramento de API que considere o design da sua API e permita monitorar com segurança cada endpoint, interno ou externo. As melhores ferramentas para esse fim são aquelas que podem acessar suas APIs internas de forma privada, sem deixar espaço para invasores.

7. Monitore 24/7

Não monitorar suas APIs literalmente o tempo todo pode custar uma fortuna. Qualquer serviço pode cair em qualquer momento aleatório. E se seu serviço de monitoramento estiver indisponível nesse momento, você terá que esperar até que o serviço volte ao ar para saber que houve tempo de inatividade. Você pode perder negócios valiosos nessa janela.

Por isso, sugerimos que você configure monitores de alta frequência que rodem pelo menos cinco vezes por hora para testes funcionais e uma vez por hora para monitoramento de segurança e OAuth.

8. Prefira o monitoramento externo ao interno

Muitas vezes, os problemas não ocorrem uniformemente interna e externamente. Seus usuários podem enfrentar um problema que você não pode reproduzir dentro dos firewalls do seu sistema. Nesse caso, não importa se suas métricas internas estão funcionando corretamente; o usuário não pode acessar seu produto, então todas as métricas operacionais são de pouca utilidade.

Para evitar tais cenários, sempre prefira uma configuração de monitoramento externo em vez de um monitoramento interno. Para corrigir problemas enfrentados por seus usuários, você precisa olhar para suas APIs a partir da perspectiva do seu usuário.

9. Monitore todos os recursos

No processo de build do serviço ou aplicativo por trás da sua API, você pode projetar alguns componentes básicos ou complexos. Embora possa ser tentador ignorar o monitoramento dos componentes essenciais, isso não é uma boa prática em todos os casos. Muitas vezes, um erro aparentemente trivial em um componente simples e sem importância pode quebrar um aplicativo extenso.

Se você não tiver olhos em todos os lugares, você será forçado a perder horas tentando encontrar o componente que causou o problema, apenas para descobrir que a única pequena peça que você considerou inocente demais para culpar é, na verdade, o culpado.

10. Analise todos os parâmetros de resposta

Verificar apenas que o código de status retornado foi 200 não é suficiente. A maioria dos desenvolvedores usam códigos de status HTTP básicos, como 200 para sucesso e 500 para erro de servidor, para denotar respostas genéricas. No entanto, sucesso ou erro podem assumir várias formas, e rastrear cada instância desses é essencial para determinar como suas APIs estão se saindo.

Você também deve considerar a procura por alterações no tamanho do conteúdo retornado pelas APIs. Se a resposta usual é de 500 kb, mas você recebeu apenas 100 kb ou menos, você provavelmente já encontrou algum tipo de falha.

Ferramentas de monitoramento de APIs

Para implementar as melhores práticas mencionadas acima, você precisa começar com uma solução de monitoramento API. Enquanto existem plugins prontos para uso em frameworks como WordPress para monitoramento de API, você precisa procurar por uma solução mais completa no caso de aplicativos codificados.

Nesta próxima seção, discutiremos um pequeno conjunto de ferramentas de monitoramento de API de tendências para ajudá-lo a começar com o mínimo de custo e esforço.

Uptrends

O painel de controle geral Uptrends
O painel de controle geral Uptrends

Uptrends oferece monitoramento para aplicativos web, APIs, servidores e muito mais. Possui uma vasta base de clientes de mais de 25.000 pequenas e grandes organizações, incluindo alguns nomes de destaque como Microsoft, Vimeo e Volkswagen.

Uma funcionalidade marcante que este provedor oferece é o teste baseado em navegador. Ele usa navegadores reais e únicos para executar seus aplicativos e sites e capturar métricas detalhadas sobre o desempenho deles.

Entretanto, os tempos de resposta e métricas não são as únicas funcionalidades do serviço. Com Uptrends, você também recebe um relatório de desempenho detalhado sobre cada um de seus recursos para que você entenda todos os tipos possíveis de gargalos em seu sistema. Para cada erro, a Uptrends tira uma captura de tela e a envia para você para que você possa experimentar o erro conforme ele ocorreu.

Dotcom-Monitor

O painel do Dotcom-Monitor.
O painel do Dotcom-Monitor.

O Dotcom-Monitor tem orgulho em permitir aos usuários configurar um dispositivo de monitoramento multi-tarefa usando HTTP ou HTTPS. Isso permite que você monitore as APIs da web para disponibilidade, respostas adequadas e desempenho.

Os agentes do Dotcom-Monitor replicam um ou mais pedidos do cliente para verificar se os dados podem ser adequadamente trocados entre a API e os clientes. Quando um dos agentes detecta um erro, ele verifica o erro em relação a uma lista de filtros pré-definidos. Se o erro não estiver definido para ser filtrado, o agente dispara um alerta.

A ferramenta permite que você configure cronogramas de alerta personalizados e alternativas de escalonamento. Você pode exportar relatórios de erro em vários formatos, incluindo CSV, PDF, TXT e outros. Os relatórios de erro do Dotcom-Monitor mostram diferentes métricas valiosas, como tempo de inatividade, tempos de resposta e desempenho médio por localização.

O Dotcom-Monitor está entre as soluções de monitoramento API mais acessíveis, e seus planos começam a partir de $1,99 por mês. Se você é uma organização em crescimento com um orçamento limitado, o Dotcom-Monitor pode ser a solução de monitoramento de API certa para você.

Graphite

O painel de monitoramento da API Graphite.
O painel de monitoramento da API Graphite.

Graphite é um sistema de monitoramento de APIs de código aberto que permite que você capture métricas de APIs fazendo com que o serviço envie os dados para o componente Graphites Carbon. O Graphite então armazena estes dados em um banco de dados para extrair informações  a partir dele.

O grafite é popular entre seus usuários pela simplicidade que oferece no processo de instalação, que inclui um script automatizado de instalação e configuração da sua pilha, conhecido como Synthesize.

Outra funcionalidade marcante oferecida pelo Graphite é a capacidade de armazenar eventos arbitrários. Estes eventos são geralmente relacionados a métricas de série temporal. Você também pode adicionar e rastrear implementações de aplicativos ou infraestrutura do Graphite, permitindo que sua equipe de desenvolvimento encontre a fonte de problemas e gargalos mais rapidamente e ganhe mais contexto sobre os eventos e anomalias que levam a comportamentos inesperados.

Sematext

Painel de controle Sematext Synthetics.
Painel de controle Sematext Synthetics.

O Sematext é uma solução popular entre as equipes DevOps, devido ao conjunto de ferramentas de monitoramento que ele oferece. O monitoramento API é uma parte do seu serviço de monitoramento sintético, conhecido como Sematext Synthetics.

Sematext oferece um sistema avançado de monitoramento e alerta de API que pode ser personalizado para trabalhar com base em vários erros e métricas. Você pode configurar essa ferramenta para realizar uma verificação dupla ou tripla antes de enviar um alerta. Isso pode ajudar a eliminar falsos positivos de alertas e fornecer informações mais precisas e relevantes.

Além do poderoso monitor HTTP que o Sematext oferece, você também obtém um recurso abrangente de monitoramento do navegador. Isso permite que você colete métricas de desempenho da web com base em interações pré-scriptadas do usuário com seus aplicativos da web. Isso significa que você pode ir além dos padrões habituais de teste de rastreamento de tempos de carregamento de página, tempos de pintura do conteúdo, etc., e dar uma olhada mais detalhada em interações emuladas de usuários, como fluxo de autenticação no aplicativo, execução de consulta de pesquisa ou adição, ou remoção de itens do carrinho. O Sematext oferece várias dessas interações de usuário prontas para uso.

BlazeMeter

O painel de monitoramento do BlazeMeter API.
O painel de monitoramento do BlazeMeter API.

Blazemeter é uma solução de teste e monitoramento de ponta a ponta para aplicativos modernos. A ferramenta lhe dá total liberdade para escolher estruturas de teste de código aberto e analisá-las usando painéis de controle simples. Ele também oferece integração perfeita com o Apache JMeter, que está entre as melhores ferramentas de medição de desempenho para aplicativos complexos.

Como a maioria das soluções de monitoramento API, o BlazeMeter também fornece funcionalidades essenciais como testes funcionais (chamados de “cenários”), que você pode configurar usando uma interface gráfica interativa com o usuário. O BlazeMeter expôs uma DSL (Domain Specific Language) através da sua ferramenta dedicada de testes Taurus que permite aos desenvolvedores escrever testes genéricos. Você pode então executar estes testes contra o JMeter e outras ferramentas populares de código aberto.

Devido ao seu design robusto, o BlazeMeter tem preços mais elevados. Se o seu aplicativo tiver mais de 5.000 usuários simultâneos, esteja preparado para gastar mais de $600 por mês. No entanto, você pode optar por planos de custo fixo com base no uso que fizer.

Se o seu produto está na mesma linha de empresas como Pfizer, Adobe, NFL, Atlassian, entre outras, BlazeMeter é a solução perfeita de monitoramento de API para você.

Embora esta seja uma coleção bastante concisa de ferramentas de monitoramento de API, existem muitas outras ótimas opções disponíveis. Certifique-se de verificar a coleção detalhada de ferramentas de monitoramento de API da Geekflare e o guia completo de compra de ferramentas de monitoramento de API da Sematext antes de tomar uma decisão!

Resumo

As APIs são a base dos sistemas computacionais modernos. A maioria dos produtos no mercado de software vem com uma API para oferecer integração perfeita com entidades de terceiros.Para fornecer uma experiência de usuário suave e manter seus clientes, é necessário considerar a build e fornecimento de uma API com seu produto de software… o que significa que é preciso conhecer APIs completamente.

Este guia tem o objetivo de ajudá-lo a ingressar neste domínio, apresentando-lhe os conceitos básicos da tecnologia, incluindo a ilustração de conceitos fundamentais, melhores práticas e ferramentas úteis de monitoramento de API disponíveis no mercado.

Apesar de tudo o que discutimos, exploramos apenas uma pequena parte do que as APIs e os endpoints de API podem realizar. Continue lendo, testando e se conectando com a comunidade de desenvolvimento para expandir seus conhecimentos e habilidades com os endpoints de API.