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:
- [1] A anatomia de uma API RESTful
- [2] O que você precisa saber sobre métodos e códigos de status do protocolo HTTP
- [3] Segurança em APIs RESTful
- [4] Versionando APIs RESTful
- [5] Paginação, Ordenação e Filtros em APIs RESTFul
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:
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.
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, recomendamos a leitura do nosso artigo sobre códigos de status HTTP para saber mais.
Conclusão sobre Políticas em APIs RESTful
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.
Confira mais artigos e nosso blog e voe alto em APIs!
