fbpx

Políticas em APIs RESTful

por jul 26, 2019Técnico

Estamos aqui para mais um post da nossa série. Hoje, as políticas em APIs RESTful são o tema do artigo!

Como tudo na vida, se você disponibiliza algo liberado e sem regras, você pode ter problemas.

Esse é um assunto muito importante, pois normalmente uma API é desenvolvida para ser uma interface pública de comunicação.

Nesse sentido, se você conhecer bem sobre políticas de APIs, você conseguirá manter tudo sob controle.

Se você não leu os primeiros artigos, dá uma lida para ficar 100% atualizado:

Além disso, existem outros benefícios de utilização dessa técnica. Você ganha segurança e escalabilidade, pois ela praticamente obriga o consumidor da sua API a utilizar sua infraestrutura de forma mais consciente.

Agora vamos entender mais sobre isso na prática:

Throttling e Rate limiting

Esses são os termos mais utilizados quando falamos de políticas em APIs RESTful. Muitas vezes throttling e rate limiting podem ser utilizados como sinônimos, mas tecnicamente eles não são.

Em linhas teóricas, rate limit e throttling são complementares mas não tem as mesmas funções.

Rate-limiting é a configuração do limite de requisições aceitas pela API em uma determinada janela de tempo. Isso pode ser medido em segundos, horas, dias, etc. Por exemplo: 100 requisições a cada 1 hora.

Throttling por sua vez é a configuração da fila de requisições excedidas para processamento em uma janela de tempo posterior, ou seja, é o tempo de delay do processamento da requisição após o client exceder os parâmetros de rate limit. Por exemplo: 2 retentativas com delay de 1 minuto.

Ambos podem ser configurados de forma granular, como por exemplo: por client, por recurso, pela API, etc.

Em resumo, rate limiting protege sua API de um alto consumo de requisições. Já o throttling prepara sua API para cenários de picos de acesso.

Usando o exemplo da API dos artigos anteriores:

https://api.minhagastronomia.com

Nesse caso, imaginem que eu queira configurar o meu rate-limit para 5 requisições por minuto, e um throttling de 1 retentativa com 1 minuto de delay.

Caso o client faça uma requisição às 20:00, nossa API deveria se comportar da seguinte forma:

imagem representando uma linha do tempo, onde a ideia de rate limiting de APIs RESTful é demonstrada através dos tipos de erros e sucesso durante os intervalos das requisições.

Notem que ao chegar na sétima requisição, então a API não deverá permitir mais requisições, e retornará o HTTP status code 429 – Too Many Requests.

Se você não leu meu artigo sobre códigos de status HTTP, leia aqui.

API Quota

Em uma visão comercial de uso da API e com um período maior de renovação das cotas de consumo, o termo API quota é bastante utilizado.

Por exemplo, a API Quota do cliente X é 5 mil requisições por mês.

Notem que agora estou falando de um período mensal, e não mais minutos, ou horas, que são períodos bem mais curtos.

Isso normalmente é utilizado quando o consumo da API é cobrado do client, pois facilita a visualização do consumo na fatura (É quase como uma conta de celular.)

É importante ressaltar que as API quotas podem ser combinadas com o rate-limiting, pois você pode limitar um client de consumir 5 mil requisições em um mês via API Quota e ao mesmo tempo limitar um client de consumir 100 requisições por minuto via Rate Limit, notem que os períodos não batem, pois o client não irá sempre consumir 100 requisições por minuto, então no fundo as técnicas não tem dependência direta.

API Burst (Plus)

Se você tem uma infraestrutura ociosa, e quer disponibilizar temporariamente mais performance de processamento e requisições para um client específico, então você pode usar a técnica de API Burst.

Por exemplo, sua configuração de rate-limit é de 10 requisições por minuto, porém um client envia 20 requisições de uma vez, porém sua API RESTful está com capacidade ociosa no servidor, então você processa todas as requisições em alta performance e retorna ao client.

Para quem quiser saber mais sobre esse algoritmo, recomendo esse link.

E aí hackers, conseguiram entender esse negócio de políticas em APIs?

Lembrando que cada linguagem pode ter uma implementação diferente das técnicas, então minha recomendação é utilizar frameworks existentes ou obviamente utilizar um API Management.

Então é isso, chegamos no final de mais um artigo…

Compartilhe

O melhor sobre APIs e Integrações.
Toda semana no seu inbox.

Fique por dentro das novidades e melhores práticas

use o linkapi agora!

Construa integrações gratuitamente

use o linkapi agora

Construa integrações gratuitamente

Thiago Lima

Thiago Lima

Thiago Lima é o CEO e fundador da LinkApi. Programador desde os 12 anos e empreendedor desde os 17, é referência no assunto de APIs e Integrações, carreiras para desenvolvedores e empreendedorismo.
    O melhor sobre APIs e Integrações.
Toda semana no seu inbox.

    O melhor sobre APIs e Integrações.

    Toda semana no seu inbox.

    Conteúdos técnicos, novidades sobre integrações, dicas de mercado e mais conteúdos exclusivos!

    Assinatura realizada com sucesso!

    Pin It on Pinterest