Compartir a través de


Cómo implementar la limitación de velocidad en Azure API Management

Con la limitación de velocidad, puede limitar el número de llamadas API que un usuario o servicio puede realizar en un período de tiempo determinado. La limitación de velocidad le ayuda a garantizar un uso justo y evita que cualquier usuario o servicio único pueda monopolizar los recursos de api. Azure API Management (APIM) proporciona una manera cómoda de implementar la limitación de velocidad para las API.

¿Por qué Azure API Management?

Azure API Management es un servicio en la nube eficaz y versátil que ayuda a las organizaciones a publicar API en desarrolladores externos, asociados e internos. Proporciona herramientas para proteger, administrar y escalar llamadas API. Una de sus características es controlar la limitación de velocidad, lo que resulta útil para mantener el estado y la confiabilidad de las API.

Configuración de la limitación de velocidad en Azure API Management

Azure API Management usa directivas para aplicar la limitación de velocidad. Puede definir estas directivas en distintos ámbitos: global, producto o específico de la API. Esta flexibilidad le permite adaptar la limitación de velocidad según los requisitos y los patrones de uso de la API.

Antes de empezar a implementar la limitación de velocidad, decida cuáles son los límites de velocidad. Los límites establecidos dependen de la capacidad de la API y del tráfico esperado. Los límites comunes se establecen como una serie de llamadas por segundo, minuto o hora. Por ejemplo, puede permitir 1000 llamadas por minuto por usuario.

Para definir los límites de velocidad en la API en Azure API Management, use las rate-limit directivas o rate-limit-by-key . El primero establece un límite en todos los usuarios, mientras que este último permite los límites por clave identificada (como una suscripción o un identificador de usuario).

Este es un ejemplo de una directiva que limita las llamadas a 1000 por minuto.

<policies>
  <inbound>
    <base />
    <rate-limit calls="1000" renewal-period="60" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Cuando se supera el número especificado de llamadas, Azure API Management envía un código de estado 429 Demasiadas solicitudes, junto con el retry-after encabezado de respuesta y un mensaje que indica cuándo puede intentarlo de nuevo.

HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 60
    
{
  "statusCode": 429,
  "message": "Rate limit is exceeded. Try again in 60 seconds."
}

Exposición de la información de límite de frecuencia en los encabezados de respuesta

De forma predeterminada, Azure API Management no expone información de límite de velocidad en los encabezados de respuesta. No comunicar los límites de velocidad dificulta que las aplicaciones eviten superar el límite y se limiten. Para exponer información de límite de frecuencia, extienda la rate-limit directiva con las remaining-calls-header-name propiedades y total-calls-header-name .

<policies>
  <inbound>
    <base />
    <rate-limit calls="1000" renewal-period="60" remaining-calls-header-name="ratelimit-remaining" total-calls-header-name="ratelimit-limit" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Al llamar a la API ahora, cada respuesta incluye los ratelimit-remaining encabezados y ratelimit-limit , que comunican cuántas llamadas más puede controlar la API antes de superar el límite.

Resumen

La implementación de la limitación de velocidad en Azure API Management le ayuda a crear API sólidas y escalables. Al usar la limitación de velocidad, puede asegurarse de que la API sirve a los usuarios de forma confiable y eficaz. Recuerde que la clave es encontrar el equilibrio correcto , demasiado estricto, y podría dificultar la facilidad de uso; demasiado leniento y corre el riesgo de sobrecargar la API. Con una planeación cuidadosa y supervisión continua, puede lograr este equilibrio y mantener un entorno de API correcto.

Pasos siguientes