Política de cuotas

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

ícono de política

Descripción general

Una cuota es una asignación de mensajes de solicitud que un proxy de API puede controlar durante un período, como un minuto, una hora, un día, una semana o un mes. La política de cuotas mantiene contadores que recopilan la cantidad de solicitudes recibidas por el proxy de API. Esta capacidad permite que los proveedores de API apliquen límites a la cantidad de llamadas a la API que realizan las aplicaciones en un intervalo de tiempo. Mediante las políticas de cuotas, puedes, por ejemplo, limitar las apps a 1 solicitud por minuto o 10,000 solicitudes por mes.

Esta política es una política extensible, y el uso de esta puede tener implicaciones de costo o uso, según tu licencia de Apigee. Para obtener información sobre los tipos de políticas y sus implicaciones de uso, consulta Tipos de políticas.

Por ejemplo, si una cuota se define como 10,000 mensajes por mes, el límite de frecuencia comienza después del mensaje 10,000. No importa si se cuentan 10,000 mensajes el primer día o el último día de ese período. No se permiten solicitudes adicionales hasta que el contador de cuota se restablezca automáticamente al final del intervalo de tiempo especificado o hasta que la cuota se restablezca de manera explícita mediante la política ResetQuota.

Una variación de la política de cuotas, política SpikeArrest, evita los aumentos repentinos del tráfico (o los aumentos de actividad) que pueden deberse a un aumento repentino en el uso, a los clientes defectuosos o a los ataques maliciosos.

Usa la política de cuotas para configurar la cantidad de mensajes de solicitud que permite el proxy de API durante un período, como un minuto, una hora, un día, una semana o un mes. Puedes configurar la cuota para que sea la misma para todas las apps que acceden al proxy de API. También puedes configurar la cuota en función de lo siguiente:

  • El producto que contiene el proxy de API
  • La app que solicita la API
  • El programador de apps
  • Muchos otros criterios

No uses la política de cuotas para protegerte contra los incrementos de tráfico repentinos generales. Para eso, usa la política SpikeArrest.

Videos

En estos videos, se presenta la administración de cuotas con la política de cuotas:

Introducción

Cuota dinámica

Sincrónico y distribuido

Peso del mensaje

Calendario

Ventana móvil

Flexi

Cuota condicional

Variables de flujo

Soluciona errores

Tipos de políticas de cuotas

La política de cuotas admite varias formas diferentes en las que el contador de cuotas se inicia y se restablece. Puedes definir cuál usar con el atributo type en el elemento <Quota>, como se muestra en el siguiente ejemplo:

<Quota name="QuotaPolicy" type="calendar">
  ...
</Quota>

Los valores válidos de type incluyen lo siguiente:

  • calendar: Configura una cuota según una hora de inicio explícita. El contador de cuotas para cada app se actualiza según los valores <StartTime>, <Interval> y <TimeUnit> que establezcas.
  • rollingwindow: Configura una cuota que use una “ventana móvil” para determinar el uso de la cuota. Con rollingwindow, determina el tamaño de la ventana con los elementos <Interval> y <TimeUnit>. Por ejemplo, 1 día. Cuando llega una solicitud, Apigee analiza la hora exacta de la solicitud (por ejemplo, 5:01 p.m.), cuenta la cantidad de solicitudes que llegaron entre entonces y las 5:01 p.m. del día anterior (1 día) y determina si se superó o no la cuota durante ese período.
  • flexi: Configura una cuota que genere que el contador comience cuando se reciba el primer mensaje de solicitud de una app y se restablezca según los valores <Interval> y <TimeUnit>.

En la siguiente tabla, se describen los restablecimientos de cuota para cada tipo:

Unidad de tiempo Tipo
default (o nulo) calendar flexi
minuto Inicio del próximo minuto Un minuto después de <StartTime> Un minuto después de la primera solicitud
hora Parte superior de la próxima hora Una hora después de <StartTime> Una hora después de la primera solicitud
día Medianoche GMT del día actual 24 horas después del <StartTime> 24 horas después de la primera solicitud
semana El domingo a la medianoche GMT cuando termina la semana Una semana después de <StartTime> Una semana después de la primera solicitud
mes Medianoche GMT del último día del mes Un mes (28 días) después de <StartTime> Un mes (28 días) después de la primera solicitud

Para type="calendar", debes especificar el valor de <StartTime>.

La tabla no enumera el valor del tipo rollingwindow. Las cuotas de ventana móvil funcionan si configuras el tamaño de una ventana de cuota, como una ventana de una hora o un día. Cuando llega una solicitud nueva, la política determina si se superó la cuota en el período anterior de tiempo.

Por ejemplo, puedes definir un período de dos horas que permita 1,000 solicitudes. Se envía una solicitud nueva a las 4:45 p.m. La política calcula la cantidad de cuotas para las últimas dos horas, lo que significa la cantidad de solicitudes desde las 2:45 p.m. Si el límite de cuota no se excede en esa ventana de dos horas, se permite la solicitud.

Un minuto después, a las 4:46 p.m., ingresa otra solicitud. Ahora la política calcula el recuento de cuotas desde las 2:46 p.m. para determinar si se superó el límite.

Para el tipo rollingwindow, el contador nunca se restablece, pero se vuelve a calcular en cada solicitud.

Obtén información sobre los contadores de cuota

Cuando una política de cuotas se ejecuta en un flujo del proxy de API, se reduce un contador de cuota. Cuando el contador alcanza su límite, no se permiten más llamadas a la API asociadas con ese contador. Según la configuración que uses, la política de cuotas puede emplear uno o más contadores. Es importante comprender cuándo se emplean varios contadores y cómo se comportan.

Cómo se cuentan las cuotas para los productos de API

Si tu proxy de API se incluye en un producto de API, puedes configurar la política de cuotas para usar las reglas de cuota que se definen en ese producto. Un producto de API puede especificar reglas de cuota a nivel de producto o a nivel de operaciones individuales.

Se mantiene un contador de cuota separado para cada operación definida en un producto de API, y se observan las siguientes reglas:

  • Si una operación tiene una cuota definida para ella, las reglas de cuota de la operación tienen prioridad sobre las de cuota definidas a nivel del producto. Se crea un contador de cuotas por separado para cada operación. Cualquier llamada a la API a la ruta de una operación aumenta su contador.
  • Si una operación no tiene una cuota definida para ella, se aplica la regla de cuota a nivel del producto. Sin embargo, se mantiene un contador de cuota independiente para la operación. Es importante comprender en este caso que, aunque la regla de cuota se toma de la definición a nivel de producto, la operación mantiene su propio contador.
  • Si el producto de API no incluye ninguna definición de cuota, ni a nivel del producto ni de la operación, se aplican las reglas de cuota especificadas en la política. Sin embargo, en este caso también se mantiene un contador de cuota individual para cada operación en el producto de API.

En las siguientes secciones, se describen las opciones y el comportamiento de los contadores con más detalle.

Configura contadores a nivel del proxy de API

Es posible configurar un producto de API para mantener un recuento de cuota en el alcance del proxy de API. En este caso, todas las operaciones que no tienen su propia cuota comparten la configuración de cuota especificada en el nivel de producto de la API. El efecto de esta configuración es crear un contador global a nivel del proxy de API para este producto de API.

Para lograr esta configuración, debes usar la API de Apigee /apiproducts para crear o actualizar el producto y establecer el atributo quotaCountScope como PROXY en la solicitud de creación o actualización. Con la configuración PROXY, todas las operaciones definidas para el producto de API que estén asociadas con el mismo proxy y no tengan su propio contador compartirán el mismo contador de cuota establecido a nivel de producto de la API.

En la Figura 1, la operación 1 y 2 se asocian con el Proxy1 y las operaciones 4 y 5 están asociadas con el Proxy3. Debido a que quotaCounterScope=PROXY se establece en el producto de API, cada una de estas operaciones comparte la configuración de cuota a nivel de producto de la API. Ten en cuenta que, aunque estas operaciones comparten la misma configuración de cuota, usan contadores independientes según su asociación de proxy. Por otro lado, la operación 3 tiene su propia configuración de cuota y, por lo tanto, no se ve afectada por la marca quotaCounterScope.

Figura 1: Uso de la marca cuotaCounterScope

De forma predeterminada, si una operación no tiene una cuota definida para ella, se aplica la regla de cuota a nivel del producto. Sin embargo, se mantiene un contador de cuota independiente para la operación.

Cómo se cuentan las cuotas si no se usan productos de API

Si no hay un producto de API asociado con un proxy de API, una política de cuotas mantiene un solo contador, sin importar cuántas veces hagas referencia a él en un proxy de API. El nombre del contador de cuotas se basa en el atributo name de la política.

Por ejemplo, creas una política de cuotas llamada MyQuotaPolicy con un límite de 5 solicitudes y la coloca en varios flujos (flujo A, B y C) en el proxy de API. Aunque se usa en varios flujos, mantiene un solo contador que se actualiza en todas las instancias de la política:

  • Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y su contador = 1
  • Se ejecuta el flujo B -> Se ejecuta MyQuotaPolicy y el contador = 2
  • Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y el contador = 3
  • Se ejecuta el flujo C -> MyQuotaPolicy se ejecuta y su contador = 4
  • Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y su contador = 5

La siguiente solicitud a cualquiera de los tres flujos es rechazada porque el contador de cuota alcanzó su límite.

El uso de la misma política de cuotas en más de un lugar en un flujo de proxy de API, que puede provocar de forma involuntaria que la cuota se ejecute más rápido de lo esperado, es un antipatrón descrito en Introducción a los antipatrones.

Como alternativa, puedes definir varias políticas de cuotas en tu proxy de API y usar una política diferente en cada flujo. Cada política de cuota mantiene su propio contador, según el atributo name de la política.

Crea varios contadores a través de la configuración de la política

Puedes usar los elementos <Class> o <Identifier> en la política de cuotas para definir varios contadores únicos en una sola política. Si usas estos elementos, una sola política puede mantener diferentes contadores según la aplicación que realice la solicitud, el desarrollador de la aplicación que realiza la solicitud, un ID de cliente o cualquier otro identificador de cliente y más. Consulta los ejemplos anteriores para obtener más información sobre el uso de los elementos <Class> o <Identifier>.

Notación de tiempo

Todas las horas de la cuota se establecen en la zona horaria Horario universal coordinado (UTC).

La notación de hora de la cuota sigue la notación de fechas estándar internacional que se define en ISO 8601.

Las fechas se definen como año, mes y día, con el siguiente formato: YYYY-MM-DD. Por ejemplo, 2021-02-04 representa el 4 de febrero de 2021.

La hora del día se define como horas, minutos y segundos con el siguiente formato: hours:minutes:seconds. Por ejemplo, 23:59:59 representa la hora un segundo antes de la medianoche.

Ten en cuenta que dos notaciones, 00:00:00 y 24:00:00, están disponibles para distinguir las dos medianoches que se pueden asociar con una fecha. Por lo tanto, 2021-02-04 24:00:00 tiene la misma fecha y hora que 2021-02-05 00:00:00. Esta última suele ser la notación preferida.

Obtén la configuración de cuotas desde la configuración de productos de la API

Puedes establecer límites de cuota en las configuraciones de productos de API. Esos límites no aplican automáticamente la cuota. En su lugar, puedes hacer referencia a la configuración de la cuota de productos en una política de cuotas. Estas son algunas ventajas de establecer una cuota en el producto para la referencia de las políticas de cuota:

  • Las políticas de cuotas pueden usar una configuración uniforme en todos los proxies de API del producto de la API.
  • Puedes realizar cambios en el entorno de ejecución a la configuración de cuotas en un producto de API y las políticas de cuota que hacen referencia al valor tienen automáticamente valores de cuota actualizados.

Si deseas obtener más información para usar la configuración de cuota desde un producto de la API, consulta el ejemplo de “Cuota dinámica” anterior.

Si deseas obtener más información para configurar productos de API con límites de cuota, consulta Administra productos de la API.

Configura contadores de cuotas compartidas

Por lo general, la política de cuotas cuenta todas las solicitudes enviadas a un proxy de API. En algunos casos de uso, es posible que desees aplicar el recuento de cuotas de solicitudes entrantes, pero también aumentarlo para las respuestas de destino que cumplan con una condición específica. Tres elementos de la política de cuotas cuando se usan en conjunto, <SharedName>, <CountOnly> y <EnforceOnly>, te permiten personalizar la política de cuotas para aplicar la cuota de solicitud entrante y contar las respuestas de destino en función de un condición que especifiques.

Por ejemplo, supongamos que deseas aumentar el contador de la cuota para un proxy de API en el que las respuestas del destino de backend tienen un código de estado HTTP 200. Para lograr este conteo especializado, haz lo siguiente:

  • Agrega una política de cuotas al flujo de solicitudes de ProxyEndpoint con el elemento <SharedName> establecido con un valor de nombre y el elemento <EnforceOnly> establecido con true.
  • Agrega otra política de cuotas al flujo de respuesta de ProxyEndpoint con el elemento <SharedName> configurado con el mismo valor de nombre que la primera política y el elemento <CountOnly> configurado como true.
  • Coloca la segunda política de cuotas (la con <CountOnly>) en un paso condicional que establezca la condición para aumentar el recuento de cuotas.

Para ver un ejemplo de cómo usar los contadores compartidos, consulta Contadores compartidos en la sección Ejemplos.

Ejemplos

En estos ejemplos de código de política, se muestra cómo comenzar y finalizar los períodos de cuota:

Más cuota dinámica

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

Las cuotas dinámicas te permiten configurar una política de Cuota única que aplique una configuración de cuota diferente según la información que se pase a la política de cuotas. Otro término para la configuración de cuotas en este contexto es el plan de servicio. La cuota dinámica comprueba el plan de servicio de las apps y, luego, aplica esa configuración.

Por ejemplo, cuando creas un producto de API, tienes la opción de configurar el límite de cuota, la unidad de tiempo y el intervalo permitidos. Sin embargo, establecer este valor en el producto de API no impone su uso en un proxy de API. También debes agregar una política de cuota al proxy de API que lea estos valores. Consulta Crea productos de API para obtener más información.

En el ejemplo anterior, el proxy de API que contiene la política de cuotas usa una política VerifyAPIKey, llamada verify-api-key, para validar la clave de API que se pasa en una solicitud. Luego, la política de cuotas accede a las variables de flujo de la política VerifyAPIKey para leer los valores de cuota establecidos en el producto de API.

Otra opción es configurar atributos personalizados en desarrolladores o apps individuales y, luego, leer esos valores en la política de cuotas. Por ejemplo, para establecer diferentes valores de cuota por desarrollador, establece atributos personalizados en el desarrollador que contengan el límite, la unidad de tiempo y el intervalo. Luego, debes hacer referencia a estos valores en la política de cuotas como se muestra a continuación:

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

En este ejemplo, también se usan las variables de flujo VerifyAPIKey para hacer referencia a los atributos personalizados establecidos en el desarrollador.

Puedes usar cualquier variable para configurar los parámetros de la política de cuotas. Estas variables pueden provenir de las siguientes fuentes:

  • Variables de flujo
  • Propiedades en el producto, la app o el desarrollador de la API
  • Un mapa de clave-valor (KVM)
  • Un encabezado, parámetro de búsqueda, parámetro de formulario y otros

Para cada proxy de API, puedes agregar una política de cuotas que haga referencia a la misma variable que todas las demás políticas de cuotas, o la política de cuotas puede hacer referencia a variables únicas para esa política y proxy.

Hora de inicio

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2021-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Para una cuota con type establecido como calendar, debes definir un valor <StartTime> explícito. El valor de tiempo es la hora GMT, no la hora local. Si no proporcionas un valor <StartTime> para una política del tipo calendar, Apigee emite un error.

El contador de cuotas para cada app se actualiza en función de los valores <StartTime>, <Interval> y <TimeUnit>. En este ejemplo, la cuota comienza a contar a las 10:30 a.m. GMT del 18 de febrero de 2021 y se actualiza cada 5 horas. Por lo tanto, la próxima actualización es a las 3:30 p.m. GMT del 18 de febrero de 2021.

Contador de acceso

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Un proxy de API tiene acceso a las variables de flujo que configura la política de cuotas. Puedes acceder a estas variables de flujo en el proxy de API para realizar el procesamiento condicional, supervisar la política a medida que se acerca al límite de la cuota, mostrar el recuento de cuota actual a una app o por otras razones.

Debido a que el acceso a las variables de flujo para la política se basa en el atributo name de las políticas, para la política anterior <Quota>, puedes acceder a sus variables de flujo en el formato:

  • ratelimit.QuotaPolicy.allowed.count: Recuento Permitido
  • ratelimit.QuotaPolicy.used.count: Valor actual de contador
  • ratelimit.QuotaPolicy.expiry.time: Hora de UTC cuando se restablece el contador.

Existen muchas otras variables de flujo a las que puedes acceder, como se describe a continuación.

Por ejemplo, puedes usar la siguiente política AssignMessage para mostrar los valores de las variables de flujo de cuota como encabezados de respuesta:

<AssignMessage continueOnError="false" enabled="true" name="ReturnQuotaVars">
  <AssignTo createNew="false" type="response"/>
  <Set>
    <Headers>
      <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
      <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
      <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

Contadores compartidos

En el siguiente ejemplo, se ilustra cómo configurar un contador compartido para un proxy de API, en el que el contador de cuota también se incrementa cuando la respuesta de destino es el estado HTTP 200. Debido a que ambas políticas de cuotas usan el mismo valor <SharedName>, ambas políticas de cuota compartirán el mismo contador de cuota. Para obtener más información, consulta Configura contadores de cuota compartida.

Ejemplo de configuración de ProxyEndpoint: 

<ProxyEndpoint name="default">
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>Enforce-Only</Name>  <!--First quota policy enforces quota count -->
            </Step>
        </Request>
        <Response>
            <Step>
                <Name>Count-Only</Name>   <!-- Second quota policy counts quota if call is successful -->
                <Condition>response.status.code = 200</Condition>
            </Step>
        </Response>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <HTTPProxyConnection>
        <BasePath>/quota-shared-name</BasePath>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

Ejemplo de la primera política de cuotas:

<Quota continueOnError="false" enabled="true" name="Enforce-Only" type="rollingwindow">
    <DisplayName>Enforce-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <EnforceOnly>true</EnforceOnly>
    <SharedName>common-proxy</SharedName>  <!-- Notice that SharedName value is the same for both Quota policies -->
</Quota>

Ejemplo de la política de cuotas:

<Quota continueOnError="false" enabled="true" name="Count-Only" type="rollingwindow">
    <DisplayName>Count-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <CountOnly>true</CountOnly>
    <SharedName>common-proxy</SharedName>  <!-- Same name as the first policy -->
</Quota>

Primera solicitud

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

Usa este código de muestra para aplicar una cuota de 10,000 llamadas por hora. La política restablece el recuento de cuotas en la parte superior de cada hora. Si el recuento alcanza la cuota de 10,000 llamadas antes de que finalice la hora, se rechazan las llamadas que superen los 10,000.

Por ejemplo, si el recuento comienza el 2021-07-08 07:00:00, se restablece en 0 a las 2021-07-08 08:00:00 (1 hora desde la hora de inicio). Si el primer mensaje se recibe a las 2021-07-08 07:35:28 y el recuento de mensajes alcanza los 10,000 antes de 2021-07-08 08:00:00, las llamadas posteriores a ese recuento se rechazan hasta que el recuento se restablezca en la parte superior de la hora.

El tiempo de restablecimiento de contadores se basa en la combinación de <Interval> y <TimeUnit>. Por ejemplo, si estableces <Interval> en 12 por un <TimeUnit> de hora, el contador se restablece cada doce horas. Puedes configurar <TimeUnit> como minutos, horas, días, semanas o meses.

Puedes hacer referencia a esta política en varias partes del proxy de API. Por ejemplo, puedes ubicarla en el PreFlow del proxy para que se ejecute en cada solicitud. O bien, puedes ubicarla en varios flujos en el proxy de API. Si usas esta política en varios lugares del proxy, mantendrá un solo contador que se actualice para todas las instancias de la política.

También puedes definir varias políticas de cuotas en el proxy de API. Cada política de cuota mantiene su propio contador, según el atributo name de la política.

Identificador de conjunto

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2021-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

De forma predeterminada, una política de cuotas define un solo contador para el proxy de API, sin importar el origen de una solicitud. Como alternativa, puedes usar el atributo <Identifier> con una política de cuotas para mantener contadores separados según el valor del atributo <Identifier>.

Por ejemplo, usa la etiqueta <Identifier> a fin de definir contadores independientes para cada ID de cliente. En una solicitud a tu proxy, la app cliente pasa un encabezado que contiene clientID, como se muestra en el ejemplo anterior.

Puedes especificar cualquier variable de flujo para el atributo <Identifier>. Por ejemplo, puedes especificar que un parámetro de búsqueda llamado id contenga el identificador único:

<Identifier ref="request.queryparam.id"/>

Si usas la política VerifyAPIKey a fin de validar la clave de API o las políticas de OAuthV2 con tokens de OAuth, puedes usar información de la clave de API o del token para definir contadores individuales para la misma política de cuotas. Por ejemplo, el siguiente elemento <Identifier> usa la variable de flujo client_id de una política VerifyAPIKey llamada verify-api-key:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

Cada valor client_id único ahora define su propio contador en la política de cuotas.

Clase

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

Puedes establecer límites de cuotas de forma dinámica mediante un recuento de cuota basado en la clase. En este ejemplo, el límite de cuota se determina según el valor del encabezado developer_segment que se pasa con cada solicitud. Esa variable puede tener un valor de platinum o silver. Si el encabezado tiene un valor no válido, la política muestra un error de incumplimiento de cuota.

Elemento <Quota>

A continuación, se muestran los atributos y los elementos secundarios de <Quota>. Ten en cuenta que algunas combinaciones de elementos son mutuamente excluyentes o no obligatorias. Consulta las muestras para un uso específico.

Las variables verifyapikey.my-verify-key-policy.apiproduct.* que se muestran a continuación están disponibles de forma predeterminada cuando se usa una política VerifyAPIKey llamada my-verify-key-policy a fin de verificar la clave de API de la app en la solicitud. Los valores de las variables provienen de la configuración de cuota del producto de la API con el que está asociada la clave, como se describe en Obtén la configuración de cuotas desde la configuración de productos de la API.

<Quota continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="UPPER_REQUEST_LIMIT" countRef="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="UPPER_LIMIT_DURING_PEAK"/>
        <Allow class="off_peak_time" count="UPPER_LIMIT_DURING_OFFPEAK"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2021-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
   <UseQuotaConfigInAPIProduct>
     <DefaultConfig>
       <Allow>
          <Class ref="request.queryparam.time_variable">
            <Allow class="peak_time" count="5000"/>
            <Allow class="off_peak_time" count="1000"/>
          </Class>
       </Allow>
       <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval>
       <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit>
     </DefaultConfig>
   </UseQuotaConfigInAPIProduct>
   </SharedName>
   </CountOnly>
   </EnforceOnly>
</Quota>

Los siguientes atributos son específicos de esta política:

Atributo Descripción Predeterminado Presencia
tipo

Establece el Tipo de política de cuota, que determina cuándo y cómo el contador de cuota verifica el uso de la cuota y cómo se restablece.

Si no configuras type, el contador comienza al principio del minuto/hora/día/semana/mes.

Estos son algunos de los valores válidos:

  • calendar
  • rollingwindow
  • flexi

Para obtener una descripción completa de cada tipo, consulta Tipos de políticas de cuotas.

 N/A Opcional

En la siguiente tabla, se describen los atributos que son comunes a todos los elementos principales de las políticas:

Atributo Descripción Predeterminado Presencia
name

El nombre interno de la política. El valor del atributo name puede contener letras, números, espacios, guiones, guiones bajos y puntos. Este valor no puede superar los 255 caracteres.

De forma opcional, usa el elemento <DisplayName> para etiquetar la política en el editor de proxy de la IU de administración con un nombre de lenguaje natural diferente.

 N/A Obligatorio
continueOnError

Configúralo como false para mostrar un error cuando una política falla. Este es el comportamiento previsto para la mayoría de las políticas.

Configúralo como true para continuar con la ejecución del flujo incluso después de que una política falle. También consulta lo siguiente:

 falso Opcional
enabled

Configúralo como true para aplicar la política.

Configúralo como false para desactivar la política. La política no se aplicará incluso si permanece adjunta a un flujo.

 true Opcional
async

Este atributo dejó de estar disponible.

 falso Obsoleta

Elemento <DisplayName>

Se usan además del atributo name para etiquetar la política en el editor de proxy de la IU de administración con un nombre de lenguaje natural diferente.

<DisplayName>Policy Display Name</DisplayName>
Predeterminada

N/A

Si omites este elemento, se usa el valor del atributo name de la política.
Presencia Opcional
Tipo String

<Allow>

Especifica el límite de conteo para la cuota. Si el recuento de la política alcanza este valor de límite, las llamadas posteriores se rechazan hasta que se restablece el contador.

También puede contener un elemento <Class> que haga que el elemento <Allow> sea condicional según una variable de flujo.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo o número entero
Elemento principal <Quota>
Elementos secundarios <Class>

A continuación, se muestran tres formas de establecer el elemento <Allow>:

<Allow count="2000"/>
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

Si especificas count y countRef, entonces countRef tiene la prioridad. Si countRef no se resuelve en el entorno de ejecución, se usa el valor de count.

También puedes especificar un elemento <Class> como elemento secundario de <Allow> para determinar el recuento permitido de la política en función de una variable de flujo. Apigee hace coincidir el valor de la variable de flujo con el atributo class del elemento <Allow>, como se muestra a continuación:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

En la siguiente tabla, se enumeran los atributos de <Allow>:

Atributo Descripción Predeterminado Presencia
count

Se usa para especificar un recuento de mensajes de la cuota.

Por ejemplo, un valor de atributo count de 100, Interval de 1 y TimeUnit de mes especifican una cuota de 100 mensajes por mes.

 2000 Opcional
countRef

Se usa para especificar una variable de flujo que contiene el recuento de mensajes de una cuota. countRef tiene prioridad sobre el atributo count.

 ninguna Opcional

<Class>

Te permite hacer condicional el valor del elemento <Allow> según el valor de una variable de flujo. Por cada etiqueta secundaria <Allow> diferente de <Class>, la política mantiene un contador diferente.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo
Elemento principal <Allow>
Elementos secundarios <Allow> (secundario de <Class>)

Para usar el elemento <Class>, especifica una variable de flujo mediante el atributo ref al elemento <Class>. Luego, Apigee usa el valor de la variable de flujo para seleccionar una de los elementos secundarios <Allow> a fin de determinar el recuento permitido de la política. Apigee hace coincidir el valor de la variable de flujo con el atributo class del elemento <Allow>, como se muestra a continuación:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

En este ejemplo, el contador de la cuota actual se determina por el valor del parámetro de búsqueda time_variable que se pasa con cada solicitud. Esa variable puede tener un valor de peak_time o off_peak_time. Si el parámetro de consulta contiene un valor no válido, la política muestra un error de incumplimiento de cuota.

En la siguiente tabla, se enumeran los atributos de <Class>:

Atributo Descripción Predeterminado Presencia
ref Se usa para especificar una variable de flujo que contiene la clase de cuota de una cuota. ninguna Obligatorio

<Allow> (secundario de <Class>)

Especifica el límite para un contador de cuota definido por el elemento <Class>. Por cada etiqueta secundaria <Allow> diferente de <Class>, la política mantiene un contador diferente.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo
Elemento principal <Class>
Elementos secundarios Ninguno

Por ejemplo:

    <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow count="5000"/>
        <Allow count="1000"/>
      </Class>
    </Allow>

En este ejemplo, la política de cuotas mantiene dos contadores de cuota llamados peak_time y off_peak_time. La opción de cuál se use depende del parámetro de búsqueda que se pase, como se muestra en el ejemplo de <Class>.

En la siguiente tabla, se enumeran los atributos de <Allow>:

Atributo Descripción Predeterminado Presencia
clase Define el nombre del contador de cuota. ninguna Obligatorio
count Especifica el límite de cuota del contador. ninguna Obligatorio

<Interval>

Especifica la cantidad de períodos en los que se calculan las cuotas.

Valor predeterminado N/A
¿Es obligatorio? Obligatorio
Tipo Entero
Elemento principal <Quota>
Elementos secundarios Ninguno

Se usa para especificar un número entero (por ejemplo, 1, 2, 5, 60, etc.) que se sincronizará con el elemento <TimeUnit> que especifiques (minuto, hora, día, semana o mes) para determinar un período durante el cual Apigee calcula el uso de la cuota.

Por ejemplo, un intervalo de 24 con un <TimeUnit> de hour significa que la cuota se calculará durante 24 horas.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

En la siguiente tabla, se enumeran los atributos de <Interval>:

Atributo Descripción Predeterminado Presencia
ref

Se usa para especificar una variable de flujo que contiene el intervalo de una cuota. ref tiene prioridad sobre un valor del intervalo explícito. Si se especifican la referencia y el valor, la referencia obtiene la prioridad. Si ref no se resuelve en el entorno de ejecución, se usa el valor.

 ninguna Opcional

<TimeUnit>

Especifica la unidad de tiempo aplicable a la cuota.

Valor predeterminado N/A
¿Es obligatorio? Obligatorio
Tipo String
Elemento principal <Quota>
Elementos secundarios Ninguno

Selecciona entre minute, hour, day, week, month o year.

Por ejemplo, un Interval de 24 con un TimeUnit de hour significa que la cuota se calculará durante 24 horas.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
Predeterminado: ninguna
Presencia: Obligatorio
Tipo: String

En la siguiente tabla, se enumeran los atributos de <TimeUnit>:

Atributo Descripción Predeterminado Presencia
ref Especifica una variable de flujo que contiene la unidad de tiempo de una cuota. ref tiene prioridad sobre un valor del intervalo explícito. Si ref no se resuelve en el entorno de ejecución, se usa el valor del intervalo. ninguna Opcional

<StartTime>

Cuando type se configura como calendar, se especifica la fecha y la hora en que el contador de cuotas comenzará a contar, sin importar si se recibieron solicitudes de alguna app.

Valor predeterminado N/A
¿Es obligatorio? Opcional (obligatorio cuando type se establece en calendar)
Tipo String en formato de fecha y hora ISO 8601
Elemento principal <Quota>
Elementos secundarios Ninguno

Debes proporcionar un <StartTime> explícito cuando type se establece de forma explícita como calendar, no puedes usar una referencia a una variable de flujo. Si especificas un valor <StartTime> cuando no se estableció un valor type, Apigee mostrará un error.

Por ejemplo:

<StartTime>2021-7-16 12:00:00</StartTime>

<Distributed>

Determina si Apigee usa uno o más nodos para procesar solicitudes.

Valor predeterminado falso
¿Es obligatorio? Opcional
Tipo Booleano
Elemento principal <Quota>
Elementos secundarios Ninguno

Configúralo como true para especificar que la política debe mantener un recuento central y sincronizarlo continuamente en todos los nodos. Los nodos pueden estar ubicados en diferentes zonas o regiones de disponibilidad.

Si usas el valor predeterminado de false, puedes exceder tu cuota, ya que no se comparte el recuento de cada nodo:

<Distributed>false</Distributed>

Para garantizar que los contadores se sincronicen y se actualicen en cada solicitud, configura <Distributed> y <Synchronous> como true:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<Synchronous>

Determina si se debe actualizar un contador de cuotas distribuidas de forma síncrona.

Valor predeterminado falso
¿Es obligatorio? Opcional
Tipo Booleano
Elemento principal <Quota>
Elementos secundarios Ninguno

Configúralo como true para actualizar un contador de cuotas distribuidas de forma síncrona. Esto significa que las actualizaciones de los contadores se realizan al mismo tiempo que la cuota se comprueba en una solicitud a la API. Configúralo como true si es fundamental que no permitas ninguna llamada a la API cuando se supera la cuota.

Configúralo como false para actualizar el recuento de cuotas de forma asíncrona. Esto significa que es posible que algunas llamadas a la API que excedan la cuota se transferirán, dependiendo de cuándo se actualice de forma asíncrona el contador de cuota en el repositorio central. Sin embargo, no tendrás el impacto potencial de rendimiento asociado con las actualizaciones síncronas.

El intervalo de actualización asíncrono predeterminado es de 10 segundos. Usa el elemento <AsynchronousConfiguration> para configurar este comportamiento asíncrono.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration>

Configura el intervalo de sincronización entre los contadores de cuota distribuida cuando el elemento de configuración de la política <Synchronous> no está presente o está presente y se establece en false. Apigee ignora este elemento cuando <Synchronous> se establece en true.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo
Elemento principal <Quota>
Elementos secundarios <SyncIntervalInSeconds>
<SyncMessageCount>

Puedes sincronizar después de un período o un recuento de mensajes si usas los elementos secundarios <SyncIntervalInSeconds> o <SyncMessageCount>. Son mutuamente excluyentes. Por ejemplo:

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

o

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

<SyncIntervalInSeconds>

Anula el comportamiento predeterminado en el que se realizan actualizaciones asíncronas después de un intervalo de 10 segundos.

Valor predeterminado 10 segundos
¿Es obligatorio? Opcional
Tipo Entero
Elemento principal <AsynchronousConfiguration>
Elementos secundarios Ninguno
 
<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

El intervalo de sincronización debe ser mayor que 10 segundos, como se describe en Límites.

<SyncMessageCount>

Especifica el número de solicitudes en todos los nodos entre las actualizaciones de cuotas.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Entero
Elemento principal <AsynchronousConfiguration>
Elementos secundarios Ninguno
 
<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

En este ejemplo, se especifica que el recuento de cuota se actualiza cada 5 solicitudes en cada nodo.

<Identifier>

Configura la política para crear contadores únicos basados en una variable de flujo.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo String
Elemento principal <Quota>
Elementos secundarios Ninguno

A través del elemento Identificador, puedes asignar recuentos de llamadas a distintos buckets definidos por el valor en una variable de flujo. Por ejemplo, puedes usar la variable developer.id, que se propaga después de una política VerifyAPIKey, para aplicar un límite de cuota a todas las instancias de todas las apps que crea cada desarrollador específico. También puedes usar client_id a fin de aplicar un límite de cuota para cada app en particular. La configuración de esto último luce de la siguiente manera:

<Identifier ref="client_id"/>

Puedes hacer referencia a una variable personalizada que puedas establecer con la política AssignMessage o la política de JavaScript, o una variable establecida de forma implícita, como las que configuran la política VerifyAPIKey o la política VerifyJWT. Para obtener más información sobre las variables, consulta Usa variables de flujo. Para obtener una lista de las variables conocidas que define Apigee, consulta la Referencia de variables de flujo.

Si no usas este elemento, la política asigna todos los recuentos de llamadas a un solo contador para la política de cuotas específica.

También se analiza este elemento en ¿Cómo funciona la política de cuotas cuando no se especifica ningún identificador?

En la siguiente tabla, se describen los atributos de <Identifier>:

Atributo Descripción Predeterminado Presencia
ref

Especifica una variable de flujo que identifica el recuento que se usará para la solicitud. La variable puede hacer referencia a un encabezado HTTP, un parámetro de consulta, un parámetro de formulario o un elemento del contenido del mensaje, o algún otro valor para identificar cómo asignar recuentos de llamadas.

Por lo general, client_id se usa como la variable. El client_id también se conoce como la clave de API o de consumidor. Se genera para una app cuando se registra en una organización en Apigee. Puedes usar este identificador si habilitaste la clave de API o las políticas de autorización de OAuth para tu API.

 N/A Opcional

<MessageWeight>

Especifica el costo asignado a cada mensaje para fines de cuota. Usa este elemento para aumentar el impacto de los mensajes de solicitud que, por ejemplo, consumen más recursos de procesamiento que otros.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Entero
Elemento principal <Quota>
Elementos secundarios Ninguno

Por ejemplo, deseas contar los mensajes POST con el doble del costo que los mensajes GET. Por lo tanto, debes establecer <MessageWeight> en 2 para POST y 1 para GET. Puedes establecer <MessageWeight> en 0 para que la solicitud no afecte el contador.

En este ejemplo, si la cuota es de 10 mensajes por minuto y el <MessageWeight> para las solicitudes POST es 2, la cuota permitirá 5 solicitudes POST en cualquier intervalo de 10 minutos. Se rechazará cualquier solicitud adicional, POST o GET, antes de que se restablezcan los contadores.

Se debe especificar un valor que represente <MessageWeight> por una variable de flujo y se puede extraer de los encabezados HTTP, los parámetros de búsqueda, una carga útil de la solicitud XML o JSON, o cualquier otra variable de flujo. Por ejemplo, lo configuras en un encabezado llamado weight:

<MessageWeight ref="message_weight"/>

<UseQuotaConfigInAPIProduct>

Define la configuración de cuota para un producto de API, como las unidades de tiempo, el intervalo y el máximo permitido.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo
Elemento principal <Quota>
Elementos secundarios <DefaultConfig>

Si agregas el elemento <UseQuotaConfigInAPIProduct> a la política de cuotas, Apigee ignora los elementos secundarios <Allow>, <Interval> y <TimeUnit> de la <Quota>.

El elemento <UseQuotaConfigInAPIProduct> es solo un contenedor para la configuración predeterminada que defines con el elemento <DefaultConfig>, como se muestra en el siguiente ejemplo:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>...</DefaultConfig>
</UseQuotaConfigInAPIProduct>

Puedes usar el atributo stepName para hacer referencia a una política VerifyAPIKey o a una operación de política ValidateToken de la política OAuthv2 en el flujo.

En la siguiente tabla, se describen los atributos de <UseQuotaConfigInAPIProduct>:

Atributo Descripción Predeterminado Presence
stepName Identifica el nombre de la política de autenticación en el flujo. El destino puede ser una política VerifyAPIKey o una política OAuthv2. N/A Requeridos

Para obtener más información, consulta lo siguiente:

<DefaultConfig>

Contiene valores predeterminados para la cuota de un producto de API. Cuando defines un <DefaultConfig>, se requieren los tres elementos secundarios.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo Tipo complejo
Elemento principal <UseQuotaConfigInAPIProduct>
Elementos secundarios <Allow>
<Interval>
<TimeUnit>

Es posible definir estos valores en la operación del producto de API (ya sea con la IU o la API de API de Products y en la política de cuotas). Sin embargo, si lo haces, tendrá prioridad la configuración del producto de API y se ignorará la configuración de la política de cuotas.

La sintaxis de este elemento es la que se muestra a continuación:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>
    <Allow>allow_count</Allow>
    <Interval>interval</Interval>
    <TimeUnit>[minute|hour|day|week|month]</TimeUnit>
  </DefaultConfig>
</UseQuotaConfigInAPIProduct>

En el siguiente ejemplo, se especifica una cuota de 10,000 cada semana:

<DefaultConfig>
  <Allow>10000</Allow>
  <Interval>1</Interval>
  <TimeUnit>week</TimeUnit>
</DefaultConfig>

Para obtener más información, consulta lo siguiente:

<SharedName>

Identifica esta política de cuotas como compartida. Todas las políticas de cuotas en un proxy de API con el mismo valor <SharedName> comparten el mismo contador de cuota subyacente. Si este elemento está presente, los elementos <EnforceOnly> o <CountOnly>también deben estar presentes.

Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.

Valor predeterminado N/A
¿Es obligatorio? Opcional
Tipo String
Elemento principal <Quota>
Elementos secundarios Ninguno

<CountOnly>

Coloca una política de cuotas con este elemento configurado en true en un paso condicional en el flujo de respuesta ProxyEndpoint para aumentar el contador de cuota subyacente de manera condicional. Si este elemento está presente, los elementos <SharedName> y <EnforceOnly> también deben estar presentes.

Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.

Valor predeterminado falso
¿Es obligatorio? Opcional
Tipo Booleano
Elemento principal <Quota>
Elementos secundarios Ninguno

<EnforceOnly>

Coloca una política de cuotas con este elemento configurado como true en el flujo de solicitud de un proxy de API. Esta configuración permite que los recuentos de cuota se compartan para cualquier política de cuotas en el proxy de API con el mismo valor <SharedName>. Si este elemento está presente, los elementos <SharedName> y <CountOnly> también deben estar presentes.

Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.

Valor predeterminado falso
¿Es obligatorio? Opcional
Tipo Booleano
Elemento principal <Quota>
Elementos secundarios Ninguno

Variables de flujo

Las siguientes variables de flujo predefinidas se propagan automáticamente cuando se ejecuta una política de cuotas. Para obtener más información, consulta Referencia de variables de flujo.

Variables Tipo Permisos Descripción
ratelimit.{policy_name}.allowed.count Long Solo lectura Muestra el recuento de cuotas permitido.
ratelimit.{policy_name}.used.count Long Solo lectura Muestra la cuota actual que se usó en un intervalo de cuota.
ratelimit.{policy_name}.available.count Long Solo lectura Muestra el recuento de cuotas disponible en el intervalo de cuota.
ratelimit.{policy_name}.exceed.count Long Solo lectura Muestra 1 después de que se excede la cuota.
ratelimit.{policy_name}.total.exceed.count Long Solo lectura Muestra 1 después de que se excede la cuota.
ratelimit.{policy_name}.expiry.time Long Solo lectura

Muestra la hora UTC (en milisegundos), que determina cuándo vence la cuota y cuándo comienza el intervalo de cuota nuevo.

Cuando el tipo de política de cuotas es rollingwindow, este valor no es válido porque el intervalo de cuota nunca vence.
ratelimit.{policy_name}.identifier String Solo lectura Muestra la referencia del identificador (cliente) adjunto a la política.
ratelimit.{policy_name}.class String Solo lectura Muestra la clase asociada con el identificador del cliente.
ratelimit.{policy_name}.class.allowed.count Long Solo lectura Muestra el recuento de cuotas permitido en la clase
ratelimit.{policy_name}.class.used.count Long Solo lectura Muestra la cuota que se usa en una clase.
ratelimit.{policy_name}.class.available.count Long Solo lectura Muestra el recuento de cuotas disponible en la clase
ratelimit.{policy_name}.class.exceed.count Long Solo lectura Muestra el recuento de solicitudes que exceden el límite en la clase en el intervalo de cuota actual
ratelimit.{policy_name}.class.total.exceed.count Long Solo lectura Muestra el recuento total de solicitudes que exceden el límite en la clase en todos los intervalos de cuota, por lo que es la suma de class.exceed.count para todos los intervalos de cuota.
ratelimit.{policy_name}.failed Booleano Solo lectura

Indica si la política falló (verdadero o falso).

Referencia de errores

En esta sección, se describen los códigos de falla y los mensajes de error que se muestran, y las variables de falla que establece Apigee cuando esta política activa un error. Esta información es importante para saber si estás desarrollando reglas de fallas con el propósito de manejar fallas. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo solucionar fallas.

Errores de entorno de ejecución

Estos errores pueden producirse cuando se ejecuta la política.

Código de falla Estado de HTTP Causa Corregir
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 Ocurre si el elemento <Interval> no está definido dentro de la política Quota. Este elemento es obligatorio y se usa para especificar el intervalo de tiempo aplicable a la cuota. El intervalo de tiempo puede ser de minutos, horas, días, semanas o meses, según se defina con el elemento <TimeUnit>.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 Ocurre si el elemento <TimeUnit> no está definido dentro de la política Quota. Este elemento es obligatorio y se usa para especificar la unidad de tiempo aplicable a la cuota. El intervalo de tiempo puede ser en minutos, horas, días, semanas o meses.
policies.ratelimit.InvalidMessageWeight 500 Este error se produce si el valor del elemento <MessageWeight> que se especificó a través de una variable de flujo no es válido (un número que no es entero).
policies.ratelimit.QuotaViolation 500 Se superó el límite de la cuota. N/A

Errores en la implementación

Nombre del error Causa Corregir
InvalidQuotaInterval Si el intervalo de cuota especificado en el elemento <Interval> no es un número entero, fallará la implementación del proxy de la API. Por ejemplo, si el intervalo de cuota especificado es 0.1 en el elemento <Interval>, fallará la implementación del proxy de API.
InvalidQuotaTimeUnit Si la unidad de tiempo especificada en el elemento <TimeUnit> no es compatible, fallará la implementación del proxy de API. Las unidades de tiempo admitidas son minute, hour, day, week y month.
InvalidQuotaType Si el tipo de cuota especificado por el atributo type en el elemento <Quota> no es válido, fallará la implementación del proxy de la API. Los tipos de cuota admitidos son default, calendar, flexi y rollingwindow.
InvalidStartTime Si el formato del tiempo especificado en el elemento <StartTime> no es válido, fallará la implementación del proxy de la API. El formato válido es yyyy-MM-dd HH:mm:ss, que es el formato de fecha y hora ISO 8601. Por ejemplo, si la hora especificada en el elemento <StartTime> es 7-16-2017 12:00:00, fallará la implementación del proxy de API.
StartTimeNotSupported Si se especifica el elemento <StartTime> cuyo tipo de cuota no es calendar, fallará la implementación del proxy de API. El elemento <StartTime> solo es compatible con el tipo de cuota calendar. Por ejemplo, si el atributo type se establece en flexi o rolling window en el elemento <Quota>, fallará la implementación del proxy de la API.
InvalidTimeUnitForDistributedQuota Si el elemento <Distributed> se configura como true y el elemento <TimeUnit> se configura como second, fallará la implementación del proxy de la API. La unidad de tiempo second no es válida para una cuota distribuida.
InvalidSynchronizeIntervalForAsyncConfiguration Si el valor especificado para el elemento <SyncIntervalInSeconds> dentro del elemento <AsynchronousConfiguration> en una política de Quota es inferior a cero, fallará la implementación del proxy de la API.
InvalidAsynchronizeConfigurationForSynchronousQuota Si el valor del elemento <AsynchronousConfiguration> se establece en true en una política Quota, que también tiene una configuración asíncrona definida con el elemento <AsynchronousConfiguration>, la implementación del proxy de la API falla.

Variables con fallas

Estas variables se establecen cuando esta política activa un error. Para obtener más información, consulta Qué debes saber sobre los errores de la política.

Variables Donde Ejemplo
fault.name="fault_name" fault_name es el nombre de la falla, como se indica en la tabla de Errores del entorno de ejecución anterior. El nombre de la falla es la última parte del código de la falla. fault.name Matches "QuotaViolation"
ratelimit.policy_name.failed policy_name es el nombre especificado por el usuario de la política que generó la falla. ratelimit.QT-QuotaPolicy.failed = true

Ejemplo de respuesta de error

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Ejemplo de regla de falla

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

Esquemas

Temas relacionados

Política ResetQuota

Política SpikeArrest

Comparar políticas de cuota y de Spike Arrest