Diretrizes de limitação do Microsoft Graph
Os limites de controle limitam número de chamadas simultâneas para um serviço para evitar a utilização exagerada dos recursos. O serviço Microsoft Graph implementa limites de limitação para garantir a disponibilidade e fiabilidade do serviço.
Os limites de controle variam de acordo com o cenário. Por exemplo, se estiver a efetuar um grande volume de escritas, a possibilidade de limitação é maior do que se estiver a realizar apenas leituras.
Observação
As soluções que precisam extrair um grande volume de dados do Microsoft Graph devem usar o Microsoft Graph Data Connect em vez das APIs REST do Microsoft Graph. O Microsoft Graph Data Connect permite que as organizações extraiam dados do Microsoft 365 em massa sem estarem sujeitas a limites de limitação.
O que acontece quando a limitação ocorre?
Quando um limiar de limitação é excedido, o Microsoft Graph:
- Limita quaisquer pedidos adicionais dessa aplicação cliente durante algum tempo.
- Devolve HTTP status código 429 Demasiados Pedidos e os pedidos falham.
- Devolve um tempo de espera sugerido no cabeçalho de resposta do pedido falhado.
O comportamento da limitação pode depender do tipo e do número de pedidos. Por exemplo, se tiver um grande volume de pedidos, todos os tipos de pedidos são limitados. Os limites de limiar variam com base no tipo de pedido. Por conseguinte, pode encontrar um cenário em que as escritas são limitadas, mas as leituras continuam a ser permitidas.
Cenários comuns de limitação
As causas mais comuns de limitação dos clientes incluem:
- Um grande número de solicitações em todos os aplicativos em um locatário.
- Um grande número de solicitações de um aplicativo específico entre todos os locatários.
Resposta de amostra
Sempre que o limite de estrangulamento é excedido, o Microsoft Graph responde com uma resposta semelhante a esta.
HTTP/1.1 429 Too Many Requests
Content-Length: 312
Content-Type: application/json
Retry-After: 10
{
"error": {
"code": "TooManyRequests",
"innerError": {
"code": "429",
"date": "2020-08-18T12:51:51",
"message": "Please retry after",
"request-id": "94fb3b52-452a-4535-a601-69e0a90e3aa2",
"status": "429"
},
"message": "Please retry again later."
}
}
Práticas recomendadas para lidar com a limitação
Estas são as práticas recomendadas para lidar com a limitação:
- Reduza o número de operações por solicitação.
- Reduza a frequência de chamadas.
- Evite novas tentativas imediatas, pois todas as solicitações se acumulam em relação aos seus limites de uso.
Quando implementar o processamento de erros, utilize o código de erro HTTP 429 para detetar a limitação. A resposta falhada inclui o cabeçalho de Retry-After resposta. Recuar nos pedidos com o Retry-After atraso é a forma mais rápida de recuperar da limitação porque o Microsoft Graph continua a registar a utilização de recursos enquanto um cliente está a ser limitado.
- Aguarde o número de segundos especificado no cabeçalho
Retry-After. - Repita a solicitação.
- Se o pedido falhar novamente com um código de erro 429, ainda está a ser limitado. Continue a utilizar o atraso recomendado
Retry-Aftere repita o pedido até que seja bem-sucedido.
Todos os recursos e APIs descritos nos limites específicos do serviço fornecem um Retry-After cabeçalho, exceto quando indicado.
Para uma discussão mais ampla sobre a limitação no Microsoft Cloud, veja Padrão de Limitação.
Observação
Se nenhum cabeçalho Retry-After for fornecido pela resposta, recomendamos implementar uma política de repetição exponencial de retirada. Você também pode implementar padrões mais avançados ao criar aplicativos em grande escala.
Os SDKs do Microsoft Graph já implementam manipuladores que dependem do cabeçalho Retry-After ou padrão para uma política de repetição de retirada exponencial.
Práticas recomendadas para evitar a limitação
Padrões de programação como pesquisando continuamente um recurso para verificar se há atualizações e a verificação regular das coleções de recursos para verificar se há recursos novos ou excluídos, possuem maior propensão de levar aplicativos a serem regulados e prejudicam o desempenho geral. Em vez disso, deve utilizar o controlo de alterações e alterar as notificações quando disponíveis.
Observação
Práticas recomendadas para descobrir arquivos e detectar alterações em escala descrevem as práticas recomendadas em detalhes.
Limitação e dosagem
O lote JSON permite que você otimize seu aplicativo combinando várias solicitações em um único objeto JSON. Os pedidos num lote são avaliados individualmente relativamente aos limites de limitação e, se um pedido exceder os limites, falha com um código de status de 429 e um erro semelhante à resposta de exemplo anterior. O lote em si é bem-sucedido com um código de status de 200 (OK). Vários pedidos podem ser limitados num único lote. Você deve tentar novamente a cada solicitação com falha no lote utilizando o valor fornecido no cabeçalho de resposta retry-after do conteúdo JSON. Você pode tentar novamente para todas as solicitações com falha em um novo lote após o valor retry-after mais longo.
Se os SDKs repetirem pedidos limitados automaticamente quando não estiverem em lotes, os pedidos limitados que faziam parte de um lote não serão repetidos automaticamente.