Guía de limitación de Microsoft Graph

La limitación restringe el número de llamadas simultáneas a un servicio para evitar el uso excesivo de los recursos. Microsoft Graph está diseñado para admitir un gran volumen de solicitudes. Si se produce un número abrumador de solicitudes, la limitación ayuda a mantener un rendimiento y una confiabilidad óptimos del servicio de Microsoft Graph.

Los márgenes de la limitación varían en función del escenario. Por ejemplo, si está realizando un gran volumen de escrituras, la posibilidad de limitación es mayor que si solo está realizando lecturas.

Nota:

Las soluciones que necesitan extraer un gran volumen de datos de Microsoft Graph deben usar Microsoft Graph Data Connect en lugar de las API de REST de Microsoft Graph. Microsoft Graph Data Connect permite a las organizaciones extraer datos de Microsoft 365 de forma masiva sin estar sujetas a limitaciones.

¿Qué sucede cuando se produce la limitación?

Cuando se supera un umbral de limitación, Microsoft Graph limita las solicitudes adicionales de ese cliente durante un período de tiempo. Cuando se produce una limitación, Microsoft Graph devuelve el código de estado HTTP 429 (demasiadas solicitudes) y se produce un error en las solicitudes. Se devuelve un tiempo de espera sugerido en el encabezado de respuesta de la solicitud con error. El comportamiento de limitación puede depender del tipo y número de solicitudes. Por ejemplo, si tiene un gran volumen de solicitudes, se limitan todos los tipos de solicitudes. Los límites de umbral varían en función del tipo de solicitud. Por lo tanto, podría encontrar un escenario en el que las escrituras están limitadas, pero las lecturas siguen permitidas.

Escenarios de limitación comunes

Las causas más comunes de limitación de los clientes incluyen:

• Un gran número de solicitudes en todas las aplicaciones de un espacio empresarial.
• Un gran número de solicitudes de una aplicación determinada a través de todos los espacios empresariales.

Respuesta de ejemplo

Siempre que se supera el umbral de limitación, Microsoft Graph responde con una respuesta similar a la siguiente.

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."
  }
}

Procedimientos recomendados para tratar la limitación

Las siguientes son recomendaciones para el tratamiento de la limitación:

• Reduzca el número de operaciones por solicitud.
• Reduzca la frecuencia de llamadas.
• Evite los reintentos inmediatos, dado que todas las solicitudes se acumulan contra los límites de uso.

Al implementar el control de errores, use el código de error HTTP 429 para detectar la limitación. La respuesta errónea incluye el encabezado de Retry-After respuesta. La copia de seguridad de las solicitudes mediante el Retry-After retraso es la forma más rápida de recuperarse de la limitación porque Microsoft Graph sigue registrando el uso de recursos mientras se limita un cliente.

1. Espere el número de segundos especificado en el encabezado Retry-After.
2. Vuelva a intentar realizar la solicitud.
3. Si la solicitud vuelve a producir un error con un código de error 429, se le seguirá limitando. Siga usando el retraso recomendado Retry-After y vuelva a intentar la solicitud hasta que se realice correctamente.

Todos los recursos y API descritos en los límites específicos del servicio proporcionan un encabezado Retry-After excepto cuando se indique.

Para obtener una explicación más amplia sobre la limitación de solicitudes en Microsoft Cloud, vea Patrón de limitación de solicitudes.

Nota:

Si la respuesta no proporciona ningún encabezado Retry-After, se recomienda implementar una directiva de reintento exponencial. También puede implementar modelos más avanzados en la creación de aplicaciones a gran escala.

SDK de Microsoft Graph ya implementan controladores que confían en el encabezado Retry-After o de forma predeterminada en una directiva de reintentos de interrupción exponencial.

Prácticas recomendadas para evitar la limitación

Los patrones de programación como el sondeo continuo recursos para comprobar las actualizaciones y el análisis periódico de las colecciones de recursos para comprobar si hay recursos nuevos o eliminados, son más propensos a provocar que las aplicaciones se limiten y afecten el rendimiento general. En su lugar, debería sacar provecho al seguimiento de cambios y a las notificaciones de cambios cuando estén disponibles.

Nota:

Prácticas recomendadas para descubrir archivos y detectar cambios a escala describe las prácticas recomendadas en detalle.

Limitación y procesamiento por lotes

El procesamiento por lotes de JSON le permite optimizar la aplicación combinando varias solicitudes en un solo objeto JSON. Las solicitudes de un lote se evalúan individualmente con respecto a los límites de limitación y, si alguna solicitud supera los límites, se produce un error con un código de estado de 429 y un error similar a la respuesta de ejemplo anterior. El propio lote se ejecuta correctamente con un código de estado de 200 (Aceptar). Se pueden limitar varias solicitudes en un único lote. Debe volver a intentar cada solicitud fallida desde el lote con el valor proporcionado en el encabezado de respuesta de retry-after del contenido JSON. Es posible que vuelva a intentar todas las solicitudes con errores en un lote nuevo después del valor más largo de retry-after.

Si los SDK intentan Reintentar automáticamente las solicitudes aceleradas cuando no son por lotes, las solicitudes limitadas que eran parte de un lote no se vuelven a intentar automáticamente.

Paso siguiente

Identificación de los límites de limitación para diferentes recursos de Microsoft Graph