As APIs s\u00e3o uma \u00f3tima maneira para aplicativos de software se comunicarem entre si. Elas permitem que aplicativos interajam e compartilhem recursos ou privil\u00e9gios.<\/p>\n
Atualmente, muitas empresas B2B oferecem seus servi\u00e7os por meio de APIs que podem ser consumidas por aplicativos desenvolvidos em qualquer linguagem de programa\u00e7\u00e3o e framework. No entanto, isso as torna vulner\u00e1veis a ataques de DoS e DDoS, al\u00e9m de poder causar uma distribui\u00e7\u00e3o desigual de largura de banda entre os usu\u00e1rios. Para lidar com esses problemas, \u00e9 implementada uma t\u00e9cnica conhecida como limita\u00e7\u00e3o de taxa API. A ideia \u00e9 simples: voc\u00ea limita o n\u00famero de solicita\u00e7\u00f5es que os usu\u00e1rios podem fazer \u00e0 sua API.<\/p>\n
Neste guia, voc\u00ea aprender\u00e1 o que \u00e9 limita\u00e7\u00e3o de taxa API, as v\u00e1rias maneiras de implement\u00e1-la e algumas pr\u00e1ticas recomendadas e exemplos a serem lembrados ao configurar limites de taxa API.
\n
Em palavras simples, a limita\u00e7\u00e3o de taxa API refere-se \u00e0 defini\u00e7\u00e3o de um limite sobre o n\u00famero de vezes que uma API<\/a> pode ser acessada por seus usu\u00e1rios. Os limites podem ser decididos de v\u00e1rias maneiras.<\/p>\n Uma das maneiras de definir um limite de taxa \u00e9 reduzir o n\u00famero de vezes que um determinado usu\u00e1rio pode acessar a API<\/a> em um determinado per\u00edodo de tempo. Isso pode ser feito contando o n\u00famero de solicita\u00e7\u00f5es feitas usando a mesma chave de API ou endere\u00e7o IP e, quando um limite \u00e9 atingido, outras solicita\u00e7\u00f5es s\u00e3o limitadas ou negadas.<\/p>\n Em muitos casos, os desenvolvedores desejam distribuir a largura de banda dispon\u00edvel para sua API igualmente entre determinadas localiza\u00e7\u00f5es geogr\u00e1ficas.<\/p>\n O recente servi\u00e7o de visualiza\u00e7\u00e3o do ChatGPT<\/a> \u00e9 um bom exemplo de limita\u00e7\u00e3o de taxa baseada em localiza\u00e7\u00e3o<\/a>, pois\u00a0come\u00e7aram a limitar as solicita\u00e7\u00f5es com base nas localiza\u00e7\u00f5es dos usu\u00e1rios na vers\u00e3o gratuita do servi\u00e7o assim que a vers\u00e3o paga foi lan\u00e7ada. Isso fazia sentido, pois a vers\u00e3o de visualiza\u00e7\u00e3o gratuita deveria ser usada por pessoas de todo o mundo para gerar uma boa amostra de dados de uso para o servi\u00e7o.<\/p>\n A limita\u00e7\u00e3o de taxa baseada no servidor \u00e9 uma limita\u00e7\u00e3o interna implementada no lado do servidor para garantir uma distribui\u00e7\u00e3o equitativa dos recursos do servidor, como CPU, mem\u00f3ria, espa\u00e7o em disco, etc. Isso \u00e9 feito implementando um limite em cada servidor de uma implanta\u00e7\u00e3o.<\/p>\n Quando um servidor atinge seu limite, outras solicita\u00e7\u00f5es de entrada s\u00e3o encaminhadas para outro servidor com capacidade dispon\u00edvel. Se todos os servidores atingirem a capacidade, o usu\u00e1rio receber\u00e1 uma resposta 429 Too Many Requests<\/a>. \u00c9 importante observar que os limites de taxa baseados no servidor s\u00e3o aplicados a todos os clientes, independentemente de sua localiza\u00e7\u00e3o geogr\u00e1fica, hor\u00e1rio de acesso ou outros fatores.<\/p>\n\n Al\u00e9m da natureza da implementa\u00e7\u00e3o dos limites de taxa, voc\u00ea tamb\u00e9m pode classific\u00e1-los com base em seu efeito no usu\u00e1rio final. Alguns tipos comuns s\u00e3o:<\/p>\n Existem v\u00e1rias raz\u00f5es pelas quais voc\u00ea precisa implementar a limita\u00e7\u00e3o de taxa em suas APIs da Web<\/a>. Alguns dos principais motivos s\u00e3o:<\/p>\n O primeiro motivo pelo qual voc\u00ea deve considerar a implementa\u00e7\u00e3o de um limite de taxa API em seu aplicativo \u00e9 para proteger seus recursos contra a explora\u00e7\u00e3o excessiva por usu\u00e1rios com inten\u00e7\u00f5es mal-intencionadas. Os invasores podem usar t\u00e9cnicas como ataques DDoS<\/a> para monopolizar o acesso aos seus recursos e impedir que o aplicativo funcione normalmente para outros usu\u00e1rios. Ter um limite de taxa em vigor garante que voc\u00ea n\u00e3o esteja facilitando a interrup\u00e7\u00e3o de suas APIs pelos invasores.<\/p>\n Al\u00e9m de proteger os seus recursos, o limite de taxa permite que voc\u00ea divida os recursos da API entre os usu\u00e1rios. Isso significa que voc\u00ea pode criar modelos de pre\u00e7os diferenciados e atender \u00e0s necessidades din\u00e2micas dos seus clientes sem permitir que elas afetem outros clientes.<\/p>\n A limita\u00e7\u00e3o de taxas tamb\u00e9m equivale \u00e0 limita\u00e7\u00e3o de custos. Isso significa que voc\u00ea pode fazer uma distribui\u00e7\u00e3o criteriosa dos seus recursos entre os usu\u00e1rios. Com uma estrutura particionada, \u00e9 mais f\u00e1cil estimar o custo necess\u00e1rio para a manuten\u00e7\u00e3o do sistema. Quaisquer picos podem ser tratados de forma inteligente, provisionando ou desativando a quantidade certa de recursos.<\/p>\n Muitas APIs dependem de uma arquitetura distribu\u00edda que usa v\u00e1rios workers\/threads\/inst\u00e2ncias para lidar com as solicita\u00e7\u00f5es recebidas. Nessa estrutura, voc\u00ea pode usar limites de taxa para controlar a carga de trabalho passada para cada worker node. Isso pode ajudar voc\u00ea a garantir que os worker nodes recebam workloads equitativas e sustent\u00e1veis. Voc\u00ea pode adicionar ou remover workers com facilidade, quando necess\u00e1rio, sem reestruturar todo o gateway da API.<\/p>\n Outra forma comum de controlar o uso de uma API \u00e9 definir um limite de burst (tamb\u00e9m conhecido como throttling) em vez de um limite de taxa. Os limites de burst s\u00e3o limites de taxa implementados para um intervalo de tempo muito curto, como alguns segundos. Por exemplo, em vez de estabelecer um limite de 1,3 milh\u00e3o de solicita\u00e7\u00f5es por m\u00eas, voc\u00ea pode definir um limite de 5 solicita\u00e7\u00f5es por segundo. Embora isso resulte no mesmo limite de tr\u00e1fego mensal, ele garante que seus clientes n\u00e3o sobrecarreguem seus servidores enviando milhares de solicita\u00e7\u00f5es de uma s\u00f3 vez.<\/p>\n No caso dos limites de burst, as solicita\u00e7\u00f5es s\u00e3o geralmente atrasadas at\u00e9 o pr\u00f3ximo intervalo em vez de serem negadas completamente. Geralmente, \u00e9 recomendado usar tanto limites de taxa quanto de burst juntos para um controle \u00f3timo de tr\u00e1fego e uso.<\/p>\n Quando se trata de implementa\u00e7\u00e3o, h\u00e1 alguns m\u00e9todos que voc\u00ea pode usar para configurar a limita\u00e7\u00e3o de taxa API em seu aplicativo. Eles incluem:<\/p>\n Um dos m\u00e9todos mais simples e pr\u00e1ticos de restringir o acesso \u00e0 API \u00e9 por meio de filas de solicita\u00e7\u00f5es. As filas de solicita\u00e7\u00f5es referem-se a um mecanismo no qual as solicita\u00e7\u00f5es recebidas s\u00e3o armazenadas em uma fila e processadas uma ap\u00f3s a outra at\u00e9 um determinado limite.<\/p>\n Um caso de uso comum de filas de solicita\u00e7\u00f5es \u00e9 a separa\u00e7\u00e3o de solicita\u00e7\u00f5es recebidas de usu\u00e1rios gratuitos e pagos. Veja como voc\u00ea pode fazer isso em um aplicativo Express<\/a> usando o pacote O throttling \u00e9 outra t\u00e9cnica usada para controlar o acesso \u00e0s APIs. Em vez de interromper o acesso ap\u00f3s atingir um limite, o throttling tem como objetivo nivelar os picos no tr\u00e1fego da API, implementando pequenos limites para pequenos intervalos de tempo. Em vez de definir um limite de taxa, como 3 milh\u00f5es de chamadas por m\u00eas, o throttling estabelece limites de 10 chamadas por segundo. Uma vez que um cliente envia mais de 10 chamadas em um segundo, as pr\u00f3ximas solicita\u00e7\u00f5es no mesmo segundo s\u00e3o automaticamente limitadas, mas o cliente recupera instantaneamente o acesso \u00e0 API no pr\u00f3ximo segundo.<\/p>\n Voc\u00ea pode implementar o throttling no Express usando o pacote Voc\u00ea pode testar o aplicativo usando uma ferramenta de teste de carga como o AutoCannon<\/a>. Voc\u00ea pode instalar o AutoCannon executando o seguinte comando em seu terminal:<\/p>\n Voc\u00ea pode testar o aplicativo usando o seguinte:<\/p>\n O teste usa 10 conex\u00f5es simult\u00e2neas que enviam solicita\u00e7\u00f5es \u00e0 API. Aqui est\u00e1 o resultado do teste:<\/p>\n Como apenas 10 solicita\u00e7\u00f5es por segundo foram permitidas (com uma explos\u00e3o extra de 5 solicita\u00e7\u00f5es), apenas 114 solicita\u00e7\u00f5es foram processadas com \u00eaxito pela API, e as solicita\u00e7\u00f5es restantes foram respondidas com um c\u00f3digo de erro 503 pedindo que voc\u00ea aguardasse algum tempo.<\/p>\n Embora a limita\u00e7\u00e3o de taxa pare\u00e7a um conceito simples que pode ser implementado usando uma fila, ela pode, de fato, ser implementada de v\u00e1rias maneiras, oferecendo v\u00e1rios benef\u00edcios. Aqui est\u00e3o alguns algoritmos populares usados para implementar a limita\u00e7\u00e3o de taxa:<\/p>\n O algoritmo de janela fixa \u00e9 um dos algoritmos de limita\u00e7\u00e3o de taxa mais simples. Ele limita o n\u00famero de solicita\u00e7\u00f5es que podem ser tratadas em um intervalo de tempo fixo.<\/p>\n Voc\u00ea define um n\u00famero fixo de solicita\u00e7\u00f5es, digamos 100, que podem ser processadas pelo servidor de API em uma hora. Agora, quando a 101\u00aa solicita\u00e7\u00e3o chegar, o algoritmo se recusar\u00e1 a process\u00e1-la. Quando o intervalo de tempo for redefinido (ou seja, na pr\u00f3xima hora), outras 100 solicita\u00e7\u00f5es recebidas poder\u00e3o ser processadas.<\/p>\n Este algoritmo \u00e9 f\u00e1cil de implementar e funciona bem em muitos casos em que \u00e9 necess\u00e1rio limitar a taxa no lado do servidor para controlar a largura de banda (em contraste com a distribui\u00e7\u00e3o da largura de banda entre os usu\u00e1rios). No entanto, pode resultar em tr\u00e1fego\/processamento inst\u00e1vel nos limites do intervalo de tempo fixo. O algoritmo da janela deslizante \u00e9 uma alternativa melhor em casos em que \u00e9 necess\u00e1rio um processamento uniforme.<\/p>\n O algoritmo da janela deslizante \u00e9 uma varia\u00e7\u00e3o do algoritmo da janela fixa. Em vez de usar intervalos de tempo fixos predefinidos, esse algoritmo usa uma janela de tempo deslizante para rastrear o n\u00famero de solicita\u00e7\u00f5es processadas e recebidas.<\/p>\n Em vez de analisar os intervalos de tempo absolutos (por exemplo, 60 segundos cada), como 0s a 60s, 61s a 120s, e assim por diante, o algoritmo da janela deslizante analisa os 60 segundos anteriores ao recebimento de uma solicita\u00e7\u00e3o. Digamos que uma solicita\u00e7\u00e3o seja recebida no 82\u00ba segundo; ent\u00e3o, o algoritmo contar\u00e1 o n\u00famero de solicita\u00e7\u00f5es processadas entre o 22\u00ba segundo e o 82\u00ba segundo (em vez do intervalo absoluto de 60s a 120s) para determinar se esta solicita\u00e7\u00e3o pode ser processada ou n\u00e3o. Isso pode evitar situa\u00e7\u00f5es em que um grande n\u00famero de solicita\u00e7\u00f5es \u00e9 processado tanto no 59\u00ba quanto no 61\u00ba segundo, sobrecarregando o servidor por um per\u00edodo muito curto.<\/p>\n Este algoritmo \u00e9 melhor para lidar com tr\u00e1fego de rajada de forma mais f\u00e1cil, mas pode ser mais dif\u00edcil de implementar e manter em compara\u00e7\u00e3o com o algoritmo da janela fixa.<\/p>\n Nesse algoritmo, um bucket fict\u00edcio \u00e9 preenchido com tokens e, sempre que o servidor processa uma solicita\u00e7\u00e3o, um token \u00e9 retirado do bucket. Quando o bucket est\u00e1 vazio, nenhuma outra solicita\u00e7\u00e3o pode ser processada pelo servidor. Outras solicita\u00e7\u00f5es s\u00e3o adiadas ou negadas at\u00e9 que o bucket seja reabastecido.<\/p>\n O bucket de tokens \u00e9 reabastecido a uma taxa fixa (conhecida como taxa de gera\u00e7\u00e3o de tokens), e o n\u00famero m\u00e1ximo de tokens que podem ser armazenados no bucket tamb\u00e9m \u00e9 fixo (conhecido como profundidade do bucket).<\/p>\n Ao controlar a taxa de regenera\u00e7\u00e3o de tokens e a profundidade do intervalo, voc\u00ea pode controlar a taxa m\u00e1xima de fluxo de tr\u00e1fego permitida pela API. O pacote A maior vantagem desse algoritmo \u00e9 que ele suporta o tr\u00e1fego de explos\u00e3o, desde que possa ser acomodado na profundidade do bucket. Isso \u00e9 especialmente \u00fatil para tr\u00e1fego imprevis\u00edvel.<\/p>\n O algoritmo de balde com vazamento \u00e9 outro algoritmo para lidar com o tr\u00e1fego de API. Em vez de manter uma profundidade do balde que determina quantas solicita\u00e7\u00f5es podem ser tratadas em um per\u00edodo de tempo (como em um bucket de token), ele permite um fluxo fixo de solicita\u00e7\u00f5es do balde, que \u00e9 an\u00e1logo ao fluxo constante de \u00e1gua de um balde com vazamento.<\/p>\n A profundidade do balde, nesse caso, \u00e9 usada para determinar quantas solicita\u00e7\u00f5es podem ser colocadas na fila para serem processadas antes que o balde comece a transbordar, ou seja, a negar as solicita\u00e7\u00f5es recebidas.<\/p>\n O balde com vazamento promete um fluxo constante de solicita\u00e7\u00f5es e, ao contr\u00e1rio do bucket com token, n\u00e3o lida com picos de tr\u00e1fego.<\/p>\n Agora que voc\u00ea j\u00e1 sabe o que \u00e9 limita\u00e7\u00e3o de taxa API e como ela \u00e9 implementada. Aqui est\u00e3o algumas pr\u00e1ticas recomendadas que voc\u00ea deve considerar ao implement\u00e1-lo em seu aplicativo.<\/p>\n Ao considerar a implementa\u00e7\u00e3o de um limite de taxa API, tente sempre oferecer um n\u00edvel gratuito adequado que os usu\u00e1rios em perspectiva possam usar para experimentar sua API. N\u00e3o precisa ser muito generoso, mas deve ser suficiente para permitir que eles testem sua API confortavelmente no aplicativo de desenvolvimento.<\/p>\n Embora os limites de taxa da API sejam vitais para manter a qualidade dos pontos de extremidade da API para os usu\u00e1rios, uma pequena camada gratuita sem limita\u00e7\u00e3o pode ajudar voc\u00ea a conquistar novos usu\u00e1rios.<\/p>\n Quando um usu\u00e1rio excede o limite de taxa API definido, h\u00e1 alguns cuidados que voc\u00ea deve tomar para garantir uma experi\u00eancia positiva para o usu\u00e1rio e, ao mesmo tempo, proteger seus recursos. Algumas perguntas que voc\u00ea deve fazer e considera\u00e7\u00f5es que deve fazer s\u00e3o:<\/p>\n A primeira coisa que voc\u00ea deve cuidar \u00e9 informar aos usu\u00e1rios que eles excederam o limite de taxa de API definido. Para fazer isso, voc\u00ea precisa alterar a resposta da API para uma mensagem predefinida que explique o problema. \u00c9 importante que o c\u00f3digo de status para essa resposta seja 429 “Too Many Requests” (Muitas solicita\u00e7\u00f5es). Tamb\u00e9m \u00e9 comum explicar o problema no corpo da resposta. Veja como pode ser o corpo de resposta de exemplo:<\/p>\n O exemplo de corpo de resposta mostrado acima menciona o nome e a descri\u00e7\u00e3o do erro e tamb\u00e9m especifica uma dura\u00e7\u00e3o (geralmente em segundos) ap\u00f3s a qual o usu\u00e1rio pode tentar enviar solicita\u00e7\u00f5es novamente. Um corpo de resposta descritivo como esse ajuda os usu\u00e1rios a entender o que deu errado e por que eles n\u00e3o receberam a resposta que esperavam. Isso tamb\u00e9m permite que eles saibam quanto tempo devem esperar antes de enviar outra solicita\u00e7\u00e3o.<\/p>\n Outro ponto de decis\u00e3o \u00e9 o que fazer depois que um usu\u00e1rio ultrapassa o limite de taxa API definido. Normalmente, voc\u00ea impediria o usu\u00e1rio de interagir com o servidor enviando uma resposta 429 “Too Many Requests” (Muitas solicita\u00e7\u00f5es), como voc\u00ea viu acima. No entanto, voc\u00ea tamb\u00e9m deve considerar uma abordagem alternativa: throttling.<\/p>\n Em vez de interromper completamente o acesso ao recurso do servidor, voc\u00ea pode reduzir a velocidade do n\u00famero total de solicita\u00e7\u00f5es que o usu\u00e1rio pode enviar em um determinado per\u00edodo de tempo. Isso \u00e9 \u00fatil quando voc\u00ea deseja dar um pequeno aviso aos usu\u00e1rios, mas ainda permitir que eles continuem trabalhando se reduzirem o volume de solicita\u00e7\u00f5es.<\/p>\n Os limites de taxa API s\u00e3o desagrad\u00e1veis: eles restringem a intera\u00e7\u00e3o e o uso dos servi\u00e7os de API pelos usu\u00e1rios. Isso \u00e9 ainda pior para os usu\u00e1rios que precisam fazer solicita\u00e7\u00f5es semelhantes repetidas vezes, como acessar um conjunto de dados de previs\u00e3o do tempo que \u00e9 atualizado apenas semanalmente ou buscar uma lista de op\u00e7\u00f5es para um menu suspenso que pode ser alterado uma vez por outra. Nesses casos, uma abordagem inteligente seria implementar o armazenamento em cache.<\/p>\n O armazenamento em cache<\/a> \u00e9 uma abstra\u00e7\u00e3o de armazenamento de alta velocidade implementada nos casos em que o volume de acesso aos dados \u00e9 alto, mas os dados n\u00e3o s\u00e3o alterados com muita frequ\u00eancia. Em vez de fazer uma chamada de API que pode invocar v\u00e1rios servi\u00e7os internos e incorrer em despesas pesadas, voc\u00ea pode armazenar em cache os pontos de extremidade usados com mais frequ\u00eancia para que a segunda solicita\u00e7\u00e3o em diante seja atendida a partir do cache est\u00e1tico, o que geralmente \u00e9 mais r\u00e1pido, mais barato e pode reduzir a carga de trabalho dos seus servi\u00e7os principais.<\/p>\n Pode haver outro caso em que voc\u00ea receba um n\u00famero excepcionalmente alto de solicita\u00e7\u00f5es de um usu\u00e1rio. Mesmo ap\u00f3s definir um limite de taxa, eles est\u00e3o constantemente atingindo sua capacidade e sendo limitados pela taxa. Essas situa\u00e7\u00f5es indicam que h\u00e1 uma chance de poss\u00edvel abuso da API.<\/p>\n Para proteger seus servi\u00e7os contra sobrecarga e manter uma experi\u00eancia uniforme para o restante dos usu\u00e1rios, voc\u00ea deve considerar restringir completamente o acesso do usu\u00e1rio suspeito \u00e0 API. Isso \u00e9 conhecido como circuit breaking e, embora pare\u00e7a semelhante \u00e0 limita\u00e7\u00e3o de taxa, \u00e9 geralmente usado quando o sistema enfrenta uma sobrecarga de solicita\u00e7\u00f5es e precisa de tempo para desacelerar e recuperar a qualidade do servi\u00e7o.<\/p>\n Embora os limites de taxa API tenham o objetivo de distribuir seus recursos de forma equitativa entre os usu\u00e1rios, \u00e0s vezes eles podem causar problemas desnecess\u00e1rios aos usu\u00e1rios ou at\u00e9 mesmo indicar atividades suspeitas.<\/p>\n Configurar uma solu\u00e7\u00e3o de monitoramento robusta<\/a> para sua API pode ajud\u00e1-lo a entender com que frequ\u00eancia os limites de taxa s\u00e3o atingidos pelos usu\u00e1rios, se voc\u00ea precisa reconsiderar os limites gerais levando em considera\u00e7\u00e3o a carga de trabalho m\u00e9dia de seus usu\u00e1rios, e identificar usu\u00e1rios que frequentemente atingem seus limites (o que poderia indicar que eles possivelmente precisar\u00e3o de um aumento em seus limites em breve ou que precisam ser monitorados por atividade suspeita). Em qualquer caso, uma configura\u00e7\u00e3o de monitoramento ativo ajudar\u00e1 voc\u00ea a entender melhor o impacto de seus limites de taxa de API.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n A limita\u00e7\u00e3o de taxa pode ser implementada em v\u00e1rios n\u00edveis (usu\u00e1rio, aplicativo ou sistema). Muitas pessoas cometem o erro de configurar limites de taxa em apenas um desses n\u00edveis e esperam que isso cubra todos os casos poss\u00edveis. Embora n\u00e3o seja exatamente um anti-padr\u00e3o, pode se revelar ineficaz em alguns casos.<\/p>\n Se as solicita\u00e7\u00f5es recebidas sobrecarregarem a interface de rede do seu sistema, a limita\u00e7\u00e3o de taxa no n\u00edvel do aplicativo pode n\u00e3o ser capaz de otimizar as cargas de trabalho. Portanto, \u00e9 melhor configurar as regras de limita\u00e7\u00e3o de taxa em mais de um n\u00edvel, preferencialmente nas camadas mais altas de sua arquitetura, para garantir que n\u00e3o sejam criados gargalos.<\/p>\n Nesta se\u00e7\u00e3o, voc\u00ea aprender\u00e1 como testar os limites de taxa API para um determinado endpoint de API e como implementar um controle de uso no seu cliente para garantir que voc\u00ea n\u00e3o acabe esgotando os limites da API remota.<\/p>\n Para identificar o limite de taxa de uma API, sua primeira abordagem deve sempre ser ler a documenta\u00e7\u00e3o da API para identificar se os limites foram claramente definidos. Geralmente, a documenta\u00e7\u00e3o da API informar\u00e1 o limite e como ele foi implementado. Voc\u00ea deve recorrer \u00e0 “teste” do limite de taxa da API apenas quando n\u00e3o puder identific\u00e1-lo na documenta\u00e7\u00e3o da API, no suporte ou na comunidade. Isso ocorre porque testar uma API para encontrar seu limite de taxa significa que voc\u00ea acabar\u00e1 esgotando seu limite de taxa pelo menos uma vez, o que pode incorrer em custos financeiros e\/ou na indisponibilidade da API por um determinado per\u00edodo.<\/p>\n Se voc\u00ea deseja identificar manualmente o limite de taxa, deve come\u00e7ar com uma ferramenta simples de teste de API, como o Postman, para fazer solicita\u00e7\u00f5es manualmente \u00e0 API e verificar se consegue esgotar o limite de taxa. Se n\u00e3o conseguir, pode usar uma ferramenta de teste de carga, como Autocannon ou Gatling, para simular um grande n\u00famero de solicita\u00e7\u00f5es e ver quantas solicita\u00e7\u00f5es s\u00e3o processadas pela API antes de ela come\u00e7ar a responder com o c\u00f3digo de status 429.<\/p>\n Outra abordagem pode ser usar uma ferramenta de verifica\u00e7\u00e3o de limite de taxa, como o AppBrokers’ No entanto, se n\u00e3o tiver certeza do limite de taxa de uma API, voc\u00ea sempre pode tentar estimar os requisitos de solicita\u00e7\u00e3o e configurar limites no lado do cliente para garantir que o n\u00famero de solicita\u00e7\u00f5es do seu aplicativo n\u00e3o exceda esse n\u00famero. Voc\u00ea aprender\u00e1 como fazer isso na pr\u00f3xima se\u00e7\u00e3o.<\/p>\n Se voc\u00ea est\u00e1 fazendo chamadas para uma API a partir do seu c\u00f3digo, pode ser interessante implementar limites no seu lado para garantir que voc\u00ea n\u00e3o acabe fazendo chamadas demais para a API e excedendo o limite permitido. Existem v\u00e1rias maneiras de fazer isso. Uma das formas populares \u00e9 usar o m\u00e9todo throttle na biblioteca de utilit\u00e1rios lodash.<\/p>\n Antes de come\u00e7ar a limitar uma chamada de API, voc\u00ea precisar\u00e1 criar uma API. Aqui est\u00e1 um c\u00f3digo de exemplo para uma API baseada em Node.js que imprime o n\u00famero m\u00e9dio de solicita\u00e7\u00f5es que recebe por minuto no console:<\/p>\n Quando esse aplicativo for executado, ele imprimir\u00e1 o n\u00famero m\u00e9dio de solicita\u00e7\u00f5es recebidas a cada segundo:<\/p>\n Em seguida, crie um novo arquivo JavaScript com o nome test-throttle.js<\/b> e salve o seguinte c\u00f3digo nele:<\/p>\n Ap\u00f3s executar esse script, voc\u00ea perceber\u00e1 que o n\u00famero m\u00e9dio de solicita\u00e7\u00f5es para o servidor salta para perto de 10:<\/p>\n E se essa API permitir apenas 6 solicita\u00e7\u00f5es por segundo, por exemplo? Voc\u00ea desejar\u00e1 manter a contagem m\u00e9dia de solicita\u00e7\u00f5es abaixo desse limite. No entanto, se seu cliente enviar uma solicita\u00e7\u00e3o com base em alguma atividade do usu\u00e1rio, como o clique de um bot\u00e3o ou uma rolagem, talvez voc\u00ea n\u00e3o consiga limitar o n\u00famero de vezes que a chamada de API \u00e9 acionada.<\/p>\n Nesse caso, a fun\u00e7\u00e3o Em seguida, atualize o arquivo test-throttle.js<\/b> para que ele contenha o seguinte c\u00f3digo:<\/p>\n Agora, se voc\u00ea observar os registros do servidor, ver\u00e1 uma sa\u00edda semelhante:<\/p>\n Isso significa que, mesmo que seu aplicativo esteja chamando a fun\u00e7\u00e3o Ao trabalhar com APIs com limite de taxa, voc\u00ea pode encontrar uma variedade de respostas que indicam quando um limite de taxa foi excedido. Geralmente, voc\u00ea receber\u00e1 o c\u00f3digo de status 429 com uma mensagem semelhante a uma destas:<\/p>\n No entanto, a mensagem que voc\u00ea recebe depende da implementa\u00e7\u00e3o da API que voc\u00ea est\u00e1 usando. Essa implementa\u00e7\u00e3o pode variar, e algumas APIs podem nem usar o c\u00f3digo de status 429. Aqui est\u00e3o outros tipos de c\u00f3digos e mensagens de erro de limita\u00e7\u00e3o de taxa que voc\u00ea pode receber ao trabalhar com APIs com limita\u00e7\u00e3o de taxa:<\/p>\n Ao definir o limite de taxa da sua API, pode ser \u00fatil dar uma olhada em como alguns dos principais provedores de API fazem isso:<\/p>\n Ao criar APIs, \u00e9 fundamental garantir o controle ideal do tr\u00e1fego. Se voc\u00ea n\u00e3o ficar de olho no gerenciamento do tr\u00e1fego, logo ter\u00e1 uma API sobrecarregada e n\u00e3o funcional. Por outro lado, ao trabalhar com uma API com taxa limitada, \u00e9 importante entender como funciona a limita\u00e7\u00e3o de taxa e como voc\u00ea deve usar a API para garantir o m\u00e1ximo de disponibilidade e uso.<\/p>\n Neste guia, voc\u00ea aprendeu sobre limita\u00e7\u00e3o de taxa de API, por que ela \u00e9 necess\u00e1ria, como pode ser implementada e algumas melhores pr\u00e1ticas a serem consideradas ao trabalhar com limites de taxa de API.<\/p>\n Confira a hospedagem de aplicativos<\/a> da Kinsta e crie seu pr\u00f3ximo projeto Node.js<\/a> hoje mesmo!<\/p>\n Voc\u00ea est\u00e1 trabalhando com uma API com limita\u00e7\u00e3o de taxa? Ou j\u00e1 implementou a limita\u00e7\u00e3o de taxa em sua pr\u00f3pria API? Deixe-nos saber nos coment\u00e1rios abaixo!<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" As APIs s\u00e3o uma \u00f3tima maneira para aplicativos de software se comunicarem entre si. Elas permitem que aplicativos interajam e compartilhem recursos ou privil\u00e9gios. Atualmente, muitas …<\/p>\n","protected":false},"author":199,"featured_media":60532,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[951],"class_list":["post-60531","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-api"],"yoast_head":"\n1. Limites baseados no usu\u00e1rio<\/h3>\n
2. Limites baseados em localiza\u00e7\u00e3o<\/h3>\n
3. Limites baseados no servidor<\/h3>\n
Tipos de limites de taxa API<\/h2>\n
\n
Por que a limita\u00e7\u00e3o de taxa \u00e9 necess\u00e1ria?<\/h2>\n
1. Prote\u00e7\u00e3o do acesso a recursos<\/h3>\n
2. Divis\u00e3o da cota entre os usu\u00e1rios<\/h3>\n
3. Aumento da efici\u00eancia de custos<\/h3>\n
4. Gerenciamento do fluxo entre os workers<\/h3>\n
Entendendo os limites de burst<\/h2>\n
3 m\u00e9todos de implementa\u00e7\u00e3o da limita\u00e7\u00e3o de taxa<\/h2>\n
1. Filas de solicita\u00e7\u00f5es<\/h3>\n
express-queue<\/code>:<\/p>\nconst express = require('express')\nconst expressQueue = require('express-queue');\n\nconst app = express()\n\nconst freeRequestsQueue = expressQueue({\n activeLimit: 1, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\nconst paidRequestsQueue = expressQueue({\n activeLimit: 5, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\n\/\/ Middleware that selects the appropriate queue handler based on the presence of an API token in the request\nfunction queueHandlerMiddleware(req, res, next) {\n \/\/ Check if the request contains an API token\n const apiToken = req.headers['api-token'];\n\n if (apiToken && isValidToken(apiToken)) {\n console.log(\"Paid request received\")\n paidRequestsQueue(req, res, next);\n } else {\n console.log(\"Free request received\")\n freeRequestsQueue(req, res, next);\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', queueHandlerMiddleware, (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\n\/\/ Check here is the API token is valid or not\nconst isValidToken = () => {\n return true;\n}\n\napp.listen(3000);<\/code><\/pre>\n2. Throttling<\/h3>\n
express-throttle<\/code>. Aqui est\u00e1 um exemplo de um aplicativo Express que mostra como configurar o throttling em seu aplicativo:<\/p>\nconst express = require('express')\nconst throttle = require('express-throttle')\n\nconst app = express()\n\nconst throttleOptions = {\n \"rate\": \"10\/s\",\n \"burst\": 5,\n \"on_allowed\": function (req, res, next, bucket) {\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", bucket.tokens);\n next()\n },\n \"on_throttled\": function (req, res, next, bucket) {\n \/\/ Notify client\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", 0);\n res.status(503).send(\"System overloaded, try again after a few seconds.\");\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', throttle(throttleOptions), (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\napp.listen(3000);<\/code><\/pre>\nnpm install autocannon -g<\/code><\/pre>\nautocannon http:\/\/localhost:3000\/route<\/code><\/pre>\nRunning 10s test @ http:\/\/localhost:3000\/route\n\n10 connections\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 99% \u2502 Avg \u2502 Stdev \u2502 Max \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Latency \u2502 0 ms \u2502 0 ms \u2502 1 ms \u2502 1 ms \u2502 0.04 ms \u2502 0.24 ms \u2502 17 ms \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 1% \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 Avg \u2502 Stdev \u2502 Min \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Req\/Sec \u2502 16591 \u2502 16591 \u2502 19695 \u2502 19903 \u2502 19144 \u2502 1044.15 \u2502 16587 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Bytes\/Sec \u2502 5.73 MB \u2502 5.73 MB \u2502 6.8 MB \u2502 6.86 MB \u2502 6.6 MB \u2502 360 kB \u2502 5.72 MB \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nReq\/Bytes counts sampled once per second.\n# of samples: 11\n114 2xx responses, 210455 non 2xx responses\n211k requests in 11.01s, 72.6 MB read<\/code><\/pre>\n3. Algoritmos de limita\u00e7\u00e3o de taxa<\/h3>\n
Algoritmo da janela fixa (Fixed Window Algorithm)<\/h4>\n
Algoritmo da janela deslizante (Sliding Window Algorithm)<\/h4>\n
Algoritmo do bucket de tokens (Token Bucket Algorithm)<\/h4>\n
express-throttle<\/code> que voc\u00ea viu anteriormente usa o algoritmo de token bucket para limitar ou controlar o fluxo de tr\u00e1fego da API.<\/p>\nAlgoritmo de balde com vazamento (Leaky Bucket Algorithm)<\/h4>\n
Pr\u00e1ticas recomendadas para limita\u00e7\u00e3o de taxa API<\/h2>\n
Ofere\u00e7a um n\u00edvel gratuito para os usu\u00e1rios explorarem seus servi\u00e7os<\/h3>\n
Decida o que acontece quando o limite de taxa \u00e9 excedido<\/h3>\n
Qual c\u00f3digo de erro e mensagem seus usu\u00e1rios ver\u00e3o?<\/h4>\n
{\n \"error\": \"Too Many Requests\",\n \"message\": \"You have exceeded the set API rate limit of X requests per minute. Please try again in a few minutes.\",\n \"retry_after\": 60\n}<\/code><\/pre>\nAs novas solicita\u00e7\u00f5es ser\u00e3o limitadas ou interrompidas completamente?<\/h4>\n
Considere o cache e o circuit breaking<\/h3>\n
Monitore sua configura\u00e7\u00e3o de perto<\/h3>\n
Implemente a limita\u00e7\u00e3o de taxa em m\u00faltiplas camadas<\/h3>\n
Como trabalhar com limites de taxa API<\/h2>\n
Como testar os limites de taxa de uma API<\/h3>\n
rate-limit-test-tool<\/a><\/code>. Ferramentas dedicadas como essa automatizam o processo para voc\u00ea e tamb\u00e9m fornecem uma interface de usu\u00e1rio para analisar cuidadosamente os resultados do teste.<\/p>\nComo limitar chamadas de API (Throttle)<\/h3>\n
const express = require('express');\nconst app = express();\n\n\/\/ maintain a count of total requests\nlet requestTotalCount = 0;\nlet startTime = Date.now();\n\n\/\/ increase the count whenever any request is received\napp.use((req, res, next) => {\n requestTotalCount++;\n next();\n});\n\n\/\/ After each second, print the average number of requests received per second since the server was started\nsetInterval(() => {\n const elapsedTime = (Date.now() - startTime) \/ 1000;\n const averageRequestsPerSecond = requestTotalCount \/ elapsedTime;\n console.log(`Average requests per second: ${averageRequestsPerSecond.toFixed(2)}`);\n}, 1000);\n\napp.get('\/', (req, res) => {\n res.send('Hello World!');\n});\n\napp.listen(3000, () => {\n console.log('Server listening on port 3000!');\n});<\/code><\/pre>\nAverage requests per second: 0\nAverage requests per second: 0\nAverage requests per second: 0<\/code><\/pre>\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ Loop to call the request function once every 100 ms, i.e., 10 times per second\nsetInterval(request, 100)<\/code><\/pre>\nAverage requests per second: 9.87\nAverage requests per second: 9.87\nAverage requests per second: 9.88<\/code><\/pre>\nthrottle()<\/code> do lodash<\/code> pode ajudar. Antes de tudo, instale a biblioteca executando o seguinte comando:<\/p>\nnpm install lodash<\/code><\/pre>\n\/\/ import the lodash library\nconst { throttle } = require('lodash');\n\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ create a throttled function that can only be called once every 200 ms, i.e., only 5 times every second\nconst throttledRequest = throttle(request, 200)\n\n\/\/ loop this throttled function to be called once every 100 ms, i.e., 10 times every second\nsetInterval(throttledRequest, 100)<\/code><\/pre>\nAverage requests per second: 4.74\nAverage requests per second: 4.80\nAverage requests per second: 4.83\n<\/code><\/pre>\nrequest<\/code> de solicita\u00e7\u00e3o 10 vezes a cada segundo, a fun\u00e7\u00e3o throttle garante que ela seja chamada apenas 5 vezes por segundo, ajudando voc\u00ea a ficar dentro do limite de taxa. \u00c9 assim que voc\u00ea pode configurar o throttling no lado do cliente para evitar exceder os limites de taxa da API.<\/p>\nErros comuns de limita\u00e7\u00e3o de taxa API<\/h2>\n
\n
\n
Como os principais provedores de API implementam os limites de taxa API<\/h2>\n
\n
retry_after<\/code> que pode ser usado para aguardar antes de enviar outra solicita\u00e7\u00e3o.<\/li>\nx-rate-limit-reset<\/code> que informar\u00e1 quando voc\u00ea poder\u00e1 retomar o acesso.<\/li>\nX-Ratelimit-Used<\/code>, X-Ratelimit-Remaining<\/code> e X-Ratelimit-Reset<\/code> com os quais voc\u00ea pode determinar quando o limite pode ser excedido e por quanto tempo.<\/li>\nX-App-Usage<\/code> ou X-Ad-Account-Usage<\/code> para ajudar voc\u00ea a entender quando seu uso ser\u00e1 limitado.<\/li>\n<\/ul>\n\nResumo<\/h2>\n