Anterior

Siguientes

Configuración de una directiva de almacenamiento en caché

Completado

Un rendimiento óptimo de la API es esencial para la mayoría de las organizaciones. Mediante el uso de una caché de respuestas compiladas en Azure API Management, puede reducir el tiempo que tarda una API en responder a las llamadas.

Supongamos que la API de juegos de mesa necesita proporcionar respuestas más rápidas a las solicitudes. Por ejemplo, los usuarios solicitan con frecuencia los precios de varios tamaños de tableros de juegos. Las directivas de API Management pueden acelerar las respuestas mediante la configuración de una caché de respuestas preparadas. Cuando se recibe una solicitud de un usuario, API Management comprueba si ya hay una respuesta adecuada en caché. Si existe, esa respuesta se puede enviar al usuario sin tener que volver a compilarla desde el origen de datos.

Aquí obtendrá información sobre cómo configurar una caché de este tipo.

Cómo controlar la caché de API Management

Para configurar una caché, use una directiva de salida denominada cache-store para almacenar las respuestas. Emplee también una directiva de entrada denominada cache-lookup para comprobar si hay una respuesta almacenada en caché para la solicitud actual. Puede ver estas dos directivas en el ejemplo siguiente:

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store duration="60" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

También es posible almacenar los valores individuales en la caché en lugar de almacenar una respuesta completa. Use la directiva cache-store-value para agregar el valor, con una clave de identificación. Recupere el valor de la caché mediante la directiva cache-lookup-value. Si quiere eliminar un valor antes de que expire, use la directiva cache-remove-value:

<policies>
    <inbound>
        <cache-lookup-value key="12345"
            default-value="$0.00"
            variable-name="boardPrice"
            caching-type="internal" />
        <base />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store-value key="12345"
            value="$3.60"
            duration="3600"
            caching-type="internal" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

Uso de etiquetas de variación (vary-by)

Es importante garantizar que, si proporciona una respuesta desde la caché, esta sea pertinente para la solicitud original. Sin embargo, también quiere usar la caché tanto como sea posible. Por ejemplo, supongamos que la API de administración de las existencias de juegos de mesa ha recibido una solicitud Get a la dirección URL siguiente y que el resultado se ha almacenado en caché:

http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=1128

Esta solicitud está pensada para comprobar las existencias de un producto con el número de pieza 3416. El id. de cliente lo usa una directiva diferente y no altera la respuesta. Las solicitudes posteriores para el mismo número de pieza se pueden responder desde la caché, siempre y cuando el registro no haya expirado. Por ahora todo está claro.

Ahora supongamos que otro cliente solicita el mismo producto:

http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=5238

De forma predeterminada, la respuesta no puede proporcionarse desde la caché, dado que el identificador del cliente es diferente.

Sin embargo, los desarrolladores señalarán que el identificador de cliente no modifica la respuesta. Sería más eficaz que las solicitudes de diferentes clientes relativas a un mismo producto pudieran devolverse desde la caché. Los clientes seguirían viendo la información correcta.

Para modificar este comportamiento predeterminado, use el elemento vary-by-query-parameter dentro de la directiva <cache-lookup>:

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal">
            <vary-by-query-parameter>partnumber</vary-by-query-parameter>
        </cache-lookup>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store duration="60" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

Con esta directiva, la caché almacenará y separará las respuestas de cada producto, porque tienen números de pieza diferentes. La caché no almacenará respuestas independientes para cada cliente, porque ese parámetro de consulta no aparece.

De forma predeterminada, Azure API Management no examina los encabezados HTTP para determinar si una respuesta almacenada en caché es adecuada para una solicitud en particular. Si un encabezado puede modificar de forma significativa una respuesta, utilice la etiqueta <vary-by-header>. Trabaje con el equipo de desarrolladores para comprender cómo utiliza cada API los encabezados y los parámetros de consulta para que pueda decidir qué etiquetas de variación (vary-by) se van a usar en la directiva.

Dentro de la etiqueta <cache-lookup>, también encontramos el atributo vary-by-developer, que es obligatorio y debe establecerse en false (falso) de manera predeterminada. Cuando este atributo se establece en true, API Management examina la clave de suscripción proporcionada con cada solicitud. Proporciona una respuesta de la caché si la solicitud original tenía la misma clave de suscripción. Establezca este atributo en true cuando cada usuario deba ver una respuesta diferente para una misma dirección URL. Si cada grupo de usuarios debe ver una respuesta diferente para una misma dirección URL, establezca el atributo vary-by-developer-group en true.

Uso de una caché externa

Las instancias de API Management normalmente tienen una caché interna, que se usa para almacenar las respuestas preparadas a las solicitudes. Sin embargo, si lo prefiere, puede usar una caché externa compatible con Redis en su lugar. Un sistema de caché externa que puede usar es el servicio Azure Redis Cache.

Es posible que decida usar una caché externa por los siguientes motivos:

• Quiere evitar que la caché se borre al actualizar el servicio API Management.
• Quiere tener un mayor control sobre la configuración de la caché de lo que permite la caché interna.
• Quiere almacenar en caché más datos de los que se pueden almacenar en la caché interna.

Otra razón para configurar una caché externa es que quiere usar el almacenamiento en caché con el plan de tarifa de consumo. Este plan emplea los principios del diseño de entidad de seguridad sin servidor y debe usarse con las API web sin servidor. Por este motivo, no tiene caché interna. Si quiere usar el almacenamiento en caché con una instancia de API Management en el plan de consumo, deberá usar una caché externa.

Continuar