Almacenamiento en caché de respuestas para mejorar el rendimiento

Descubra cómo utilizar las políticas de solicitud y respuesta de almacenamiento en caché de respuesta para reducir el número de solicitudes enviadas a servicios de backend con API Gateway.

Normalmente, querrá evitar colocar una carga innecesaria en los servicios de backend para mejorar el rendimiento y reducir los costos. Una forma de reducir esa carga es almacenar en caché las respuestas a las solicitudes en caso de que las respuestas se puedan volver a utilizar posteriormente. Si se reciben solicitudes similares, se pueden satisfacer recuperando datos de una caché de respuesta en lugar de enviar la solicitud al servicio de backend.

El servicio de gateway de API se puede integrar con un servidor de caché externo al que ya tiene acceso, como un servidor Redis o KeyDB. Puede configurar gateways de API gestionados por el servicio de gateway de API para:

  • Almacene los datos en el servidor de caché que ha devuelto un servicio de backend en respuesta a una solicitud original.
  • Recupere los datos almacenados anteriormente del servidor de caché en respuesta a una solicitud posterior similar a la solicitud original, sin enviar la solicitud posterior al servicio de backend.

Para configurar un gateway de API para el almacenamiento en caché de respuesta:

Puede configurar el almacenamiento en caché de respuestas:

  • uso de la consola
  • edición de un archivo JSON

¿Cómo Funciona el Almacenamiento en Caché de Respuesta?

Cuando ha activado un gateway de API para el almacenamiento en caché de respuesta, el gateway de API analiza las solicitudes de los clientes de API en rutas que tienen políticas de almacenamiento en caché de respuesta. El gateway de API intenta hacer coincidir una nueva solicitud con solicitudes similares anteriores para las que las respuestas ya están almacenadas en el servidor de caché. El gateway de API almacena las respuestas en el servidor de caché para las solicitudes GET, HEAD y OPTIONS, siempre que las respuestas tengan un código de estado HTTP 200, 204, 301 o 410. Tenga en cuenta que el gateway de API utiliza las políticas de respuesta y solicitud de almacenamiento en caché de respuesta que configure e ignora las cabeceras de control de caché (si existen) en la solicitud o la respuesta.

Para identificar de forma única las respuestas en el servidor de caché, el gateway de API utiliza claves de caché derivadas de las solicitudes GET, HEAD y OPTIONS que han provocado las respuestas. Por defecto, una clave de caché consta de:

  • la URL de la solicitud que ha provocado la respuesta (excluyendo cualquier parámetro de consulta en la URL)
  • el método HTTP (uno de los métodos GET, HEAD u OPTIONS)
  • el OCID del despliegue de API que ha recibido la solicitud

Para que las respuestas almacenadas en caché coincidan más estrechamente con solicitudes concretas, puede personalizar opcionalmente las claves de caché agregando los valores de una o más variables de contexto de la solicitud a la clave de caché (consulte Notas sobre la Personalización de Claves de Caché).

Lo que sucede a continuación depende de si el gateway de API puede hacer coincidir la nueva solicitud GET, HEAD u OPTIONS con una respuesta de una solicitud similar anterior:

  • Si el gateway de API encuentra una clave de caché coincidente en el servidor de caché, el gateway de API recupera los datos de respuesta correspondientes del servidor de caché y los envía al cliente de API como respuesta.
  • Si el gateway de API no encuentra una clave de caché coincidente en el servidor de caché, el gateway de API reenvía la solicitud al servicio de backend. Cuando el servicio de backend devuelve una respuesta, el gateway de API envía la respuesta al cliente de API y también almacena la respuesta en el servidor de caché con una nueva clave de caché.
El gateway de API agrega una cabecera adicional a las respuestas a las solicitudes GET, HEAD y OPTIONS a las rutas que tienen políticas de caché de respuesta. La cabecera de respuesta adicional, X-Cache-Status, indica si la respuesta se ha recuperado del servidor de caché de la siguiente manera:
  • X-Cache-Status: HIT indica que se ha encontrado una clave de caché coincidente en el servidor de caché, por lo que la respuesta se ha recuperado del servidor de caché.
  • X-Cache-Status: MISS indica que no se ha encontrado ninguna clave de caché coincidente en el servidor de caché, por lo que la respuesta procede del servicio de backend.
  • X-Cache-Status: BYPASS indica que el servidor de caché no se ha comprobado, por lo que la respuesta procede del servicio de backend. Los motivos por los que no se comprueba el servidor de caché incluyen problemas para comunicarse con el servidor de caché y valores de configuración que impiden que se recuperen respuestas para solicitudes específicas del servidor de caché.

Consejo: si no desea que las respuestas contengan la cabecera X-Cache-Status adicional, utilice una política de respuesta de transformación de cabecera para eliminarla (consulte Adición de políticas de respuesta de transformación de cabecera).

Notas sobre la seguridad y el almacenamiento en caché de respuesta

Para asegurarse de que los datos del servidor de caché se almacenan y se accede de forma segura:

  • Puede configurar el gateway de API para autenticarse con el servidor de caché mediante credenciales guardadas como secreto en un almacén del servicio Vault.
  • Puede especificar si desea configurar una conexión segura a través de TLS (anteriormente SSL) entre el gateway de API y un servidor de caché con TLS activado, y si desea verificar los certificados TLS. Tenga en cuenta que solo se verifican actualmente los certificados firmados por las autoridades de certificación públicas.
  • Puede especificar un tiempo de caducidad para asegurarse de que los datos almacenados en caché no se almacenan durante un período demasiado largo y que los datos anticuados no se devuelven desde el servidor de caché en respuesta a una solicitud posterior.
  • Puede limitar las URL de solicitud que coinciden con las claves de caché personalizando las claves de caché para incluir uno o más parámetros presentes en las URL de solicitud (consulte Notas sobre la Personalización de Claves de Caché).
  • Puede especificar que no almacene en caché respuestas para solicitudes que incluyen credenciales (consulte Notas sobre el almacenamiento en caché de respuestas para solicitudes que contienen credenciales (almacenamiento en caché privado)).

Tenga en cuenta que es su responsabilidad asegurarse de que el propio servidor de caché esté configurado correctamente para proteger los datos almacenados en él. En concreto, Oracle recomienda no volver a utilizar un servidor de caché existente. En su lugar, Oracle recomienda configurar un nuevo servidor de caché únicamente para el almacenamiento en caché de respuesta de gateway de API y restringir el acceso al servidor de caché a solo gateways de API.

Notas sobre el Almacenamiento en Caché de Respuestas para Solicitudes que Contienen Credenciales (Almacenamiento en Caché Privado)

Las solicitudes pueden incluir cabeceras de autorización que contienen las credenciales para autenticar un cliente de API con un servicio de backend. Las credenciales normalmente proporcionan acceso a los datos que son privados para una persona u organización. Por ejemplo, se puede utilizar una cabecera de autorización de solicitud que contenga un token de autenticación para obtener una respuesta que contenga información de cuenta bancaria. La existencia de cabeceras de autorización en una solicitud es una indicación de que la respuesta puede ser de naturaleza confidencial y solo compartirla con los que pueden verla.

Del mismo modo, si ha utilizado funciones de autorizador para la autenticación y autorización, una política de autenticación identifica una cabecera o un parámetro de consulta en una solicitud que contiene un token de acceso (consulte Transferencia de tokens a funciones de autorizador para agregar autenticación y autorización a despliegues de API). La existencia en una solicitud del parámetro de cabecera o consulta identificado en una política de autenticación también es una indicación de que la respuesta puede ser de naturaleza confidencial y solo compartirse con aquellos a los que se les permite verla.

El almacenamiento en caché de respuestas para solicitudes que contienen cabeceras de autorización o que contienen una cabecera o un parámetro de consulta identificado en una política de autenticación se denomina "almacenamiento en caché privado". Aunque el almacenamiento en caché privado puede acelerar las respuestas a solicitudes similares en el futuro, tiene el potencial de comprometer la seguridad de los datos. Por lo tanto, para evitar infracciones de seguridad, el almacenamiento en caché privado está desactivado por defecto. Sin embargo, ruta por ruta, puede activar el almacenamiento en caché privado.

Si decide activar el almacenamiento en caché privado, le recomendamos que personalice la clave de caché para aislar las respuestas, de modo que cada respuesta solo se devuelva a los que pueden verla. Por ejemplo:

  • Agregue el valor de la cabecera de autorización de solicitud o el valor de la cabecera o el parámetro de consulta identificados en una política de autenticación a la clave de caché como variable de contexto de una tabla de contexto.
  • Si ha utilizado funciones de autorizador o JWT para la autenticación y autorización, agregue el valor de una variable de contexto que identifique el principal de solicitud (como sub o principalId) a la clave de caché de la tabla de contexto request.auth. Consulte Agregación de autenticación y autorización a despliegues de API.

Una respuesta almacenada en caché con un valor en su clave de caché para una variable de contexto solo se devolverá en respuesta a una solicitud que tenga un valor coincidente.

Es su responsabilidad especificar una adición de clave de caché que proporcione un aislamiento suficiente entre las respuestas almacenadas en caché. Consulte Notas sobre la Personalización de Claves de Caché.

Notas sobre la Personalización de Claves de Caché

Las respuestas almacenadas en el servidor de caché se identifican de forma única mediante una clave de caché. Por defecto, una clave de caché se deriva de la URL de la solicitud que ha provocado la respuesta (excluyendo cualquier variable de contexto presente en la solicitud), el método HTTP y el OCID del despliegue de API. Para que las respuestas almacenadas en caché coincidan más estrechamente con solicitudes concretas, puede personalizar opcionalmente las claves de caché agregando los valores de una o más variables de contexto de la solicitud a la clave de caché. Si decide activar el almacenamiento en caché privado para solicitudes que contienen cabeceras de autorización o que contienen una cabecera o un parámetro de consulta identificado en una política de autenticación, le recomendamos que agregue sus valores como variables de contexto a la clave de caché.

Para especificar los valores de variable de contexto que se van a agregar a la clave de caché, utilice el formato <context-table-name>.[<key>], donde:

  • <context-table-name> puede ser request.query, request.headers o request.auth
  • <key> es uno de los siguientes elementos:
    • nombre de parámetro de consulta incluido en la solicitud para la API
    • nombre de cabecera incluido en la solicitud para la API
    • un nombre de parámetro de autenticación devuelto por una función de autorizador o contenido en un token JWT
    • el campo de cabecera Host de la solicitud a la API

Por ejemplo:

  • Para agregar el valor de la variable de contexto X-Username a una clave de caché cuando se incluye en una cabecera de solicitud, especifique request.headers[X-Username] como adición de clave de caché.
  • Para agregar el principal de solicitud (la persona o aplicación que envía la solicitud) a una clave de caché cuando se incluye como reclamación sub en un token de JWT, especifique request.auth[sub] como adición de clave de caché.
  • Para agregar el valor de la cabecera Authorization a una clave de caché, especifique request.headers[Authorization] como adición de clave de caché.
  • Para agregar el valor de un token de acceso devuelto por una función de autorizador y contenido en una cabecera denominada X-Custom-Auth a una clave de caché, especifique request.headers[X-Custom-Auth] como adición de clave de caché.
  • Para agregar el valor del campo de cabecera Host incluido en la solicitud a una clave de caché, especifique request.host.

Para obtener más información sobre las variables de contexto, consulte Agregación de variables de contexto a políticas y definiciones de backend HTTP.

Requisitos para la caché de respuesta

Antes de activar el almacenamiento en caché de respuesta para un gateway de API:

  • Un servidor de caché que implementa el protocolo RESP (como Redis o KeyDB) debe haber sido configurado y debe estar disponible.
  • La subred del gateway de API debe poder acceder al servidor de caché.
  • El servidor de caché debe estar alojado en un único host de servidor de caché y no distribuido entre varias instancias de un cluster.
  • Ya debe haber almacenado las credenciales para autenticarse con el servidor de caché como secreto en un almacén del servicio Vault (consulte Creación de un secreto en un almacén) y debe conocer el OCID y el número de versión del secreto. Al especificar el contenido del secreto, utilice el formato {"username":"<cache-server-username>", "password":"<cache-server-password>"}. Tenga en cuenta que la especificación de un nombre de usuario es opcional. Por ejemplo:
    {"password":"<cache-server-password>"}
  • Ya debe haber configurado una política para otorgar gateways de API en un grupo dinámico permiso para acceder al secreto en el servicio Vault que contiene las credenciales para autenticarse con el servidor de caché (consulte Creación de una política para otorgar a los gateways de API acceso a las credenciales almacenadas como secretos en el servicio Vault).

Activación del almacenamiento en caché de respuesta en un gateway de API

Puede activar el almacenamiento en caché de respuesta en un gateway de API mediante la consola o editando un archivo JSON.

Uso de la consola para activar y configurar el almacenamiento en caché de respuesta

Para activar y configurar el almacenamiento en caché de respuesta para un gateway de API mediante la consola:

  1. Cree o actualice un gateway de API mediante la consola.

    Para obtener más información, consulte Creación de un gateway de API y Actualización de un gateway de API.

  2. En la sección Opciones avanzadas del cuadro de diálogo Crear gateway, seleccione el botón Activar junto a Almacenamiento en caché de respuesta y:

    1. Especifique las opciones de Cache Server, de la siguiente manera:
      • Host: nombre de host del servidor de caché. Por ejemplo, "cache.example.com".
      • Número de Puerto: Número de puerto del servidor de caché. Por ejemplo, 6379.
    2. Especifique las opciones de Credenciales del Servidor de Caché de la siguiente forma:
      • Almacén: nombre del almacén en el servicio Vault que contiene las credenciales para conectarse al servidor de caché.
      • Secreto de almacén: nombre del secreto en el almacén especificado que contiene las credenciales para conectarse al servidor de caché.
      • Número de versión del secreto de almacén: versión del secreto que se va a utilizar.
    3. Especifique las opciones de Conexión de Servidor de Caché de la siguiente forma:
      • Usar SSL/TLS en solicitudes: indica si el servidor de caché está activado para TLS y, por lo tanto, si se debe configurar una conexión segura entre el gateway de API y el servidor de caché mediante TLS (anteriormente SSL).
      • Verificar certificado SSL/TLS: indica si el gateway de API verifica el certificado TLS (anteriormente SSL) del servidor de caché. Tenga en cuenta que solo se verifican actualmente los certificados firmados por autoridades de certificación públicas.
      • Timeout de Conexión: Tiempo de espera antes de abandonar un intento de conexión al servidor de caché, en milisegundos. Si el gateway de API no se puede conectar al servidor de caché en este momento, el gateway de API no recupera datos almacenados previamente en caché del servidor de caché y no escribe nuevos datos en el servidor de caché para una posible reutilización futura.
      • Timeout de Lectura: Tiempo de espera antes de abandonar un intento de lectura de datos del servidor de caché, en milisegundos. Si el gateway de API no puede recuperar datos del servidor de caché en este momento, el gateway de API envía una solicitud al servicio de backend en su lugar.
      • Timeout de Envío: Tiempo de espera antes de abandonar un intento de escritura de datos en el servidor de caché, en milisegundos. Si el gateway de API no puede enviar datos al servidor de caché en este momento, no se almacena en caché una respuesta para una posible reutilización futura.
  3. Seleccione Crear o Guardar cambios para crear o actualizar el gateway de API.

Uso de la CLI y un archivo JSON para activar y configurar el almacenamiento en caché de respuestas

Para activar y configurar el almacenamiento en caché de respuesta para un gateway de API mediante la CLI y un archivo JSON:

  1. Con su editor de JSON preferido, cree un archivo de configuración de caché con el formato:

    {
      "type" : "EXTERNAL_RESP_CACHE",
      "servers" : [
        {
          "host" : "<cache-server-hostname>",
          "port" : <port-number>
        }
      ],
      "authenticationSecretId" : "<secret-ocid>",
      "authenticationSecretVersionNumber" : <secret-version-number>,
      "isSSLEnabled" : <true|false>,
      "isSSLVerifyDisabled" : <true|false>,
      "connectTimeoutInMs" : <milliseconds>,
      "readTimeoutInMs" : <milliseconds>,
      "readTimeoutInMs" : <milliseconds>
    }
    donde:
    • "type" : "EXTERNAL_RESP_CACHE" indica que se debe activar el almacenamiento en caché de respuesta. Si no se define, el valor por defecto es "type" : "NONE", lo que indica que el almacenamiento en caché de respuesta está desactivado.
    • "host" : "<cache-server-hostname>" es el nombre de host del servidor de caché. Por ejemplo, "host" : "cache.example.com".
    • "port" : <port-number> es el número de puerto del servidor de caché. Por ejemplo, "port" : 6379.
    • "authenticationSecretId" : "<secret-ocid>" es el OCID del secreto definido en un almacén del servicio Vault que contiene las credenciales para conectarse al servidor de caché. Por ejemplo, "authenticationSecretId" : "ocid.oc1.sms.secret.aaaaaa______gbdn"
    • "authenticationSecretVersionNumber" : <secret-version-number> es la versión del secreto que se va a utilizar. Por ejemplo, "authenticationSecretVersionNumber" : 1
    • "isSSLEnabled" : <true|false> indica si el servidor de caché está activado para TLS y, por lo tanto, si se debe configurar una conexión segura entre el gateway de API y el servidor de caché a través de TLS (anteriormente SSL). Si no se define, el valor por defecto es false
    • "isSSLVerifyDisabled" : <true|false> indica si el gateway de API verifica el certificado TLS (anteriormente SSL) del servidor de caché. Tenga en cuenta que solo se verifican actualmente los certificados firmados por las autoridades de certificación públicas. Si no se define, el valor por defecto es false
    • "connectTimeoutInMs" : <milliseconds> indica cuánto tiempo se debe esperar antes de abandonar un intento de conexión al servidor de caché, en milisegundos. Si el gateway de API no se puede conectar al servidor de caché en este momento, el gateway de API no recupera los datos almacenados en caché anteriormente del servidor de caché y no escribe nuevos datos en el servidor de caché para su posible reutilización futura. Si no se define, el valor por defecto es 1000. Por ejemplo, "connectTimeoutInMs" : 1500
    • "readTimeoutInMs" : <milliseconds> indica cuánto tiempo se debe esperar antes de abandonar un intento de lectura de datos del servidor de caché, en milisegundos. Si el gateway de API no puede recuperar datos del servidor de caché en este momento, el gateway de API envía una solicitud al servicio de backend en su lugar. Si no se define, el valor por defecto es 1000. Por ejemplo, "readTimeoutInMs" : 250
    • "sendTimeoutInMs" : <milliseconds> indica cuánto tiempo se debe esperar antes de abandonar un intento de escritura de datos en el servidor de caché, en milisegundos. Si el gateway de API no puede enviar datos al servidor de caché en este momento, las respuestas no se almacenan en caché para su posible reutilización futura. Si no se define, el valor por defecto es 1000. Por ejemplo, "sendTimeoutInMs" : 1250

    Por ejemplo:

    {
      "type" : "EXTERNAL_RESP_CACHE",
      "servers" : [
        {
          "host" : "cache.example.com",
          "port" : 6379
        }
      ],
      "authenticationSecretId" : "ocid.oc1.sms.secret.aaaaaa______gbdn",
      "authenticationSecretVersionNumber" : 1,
      "isSSLEnabled" : true,
      "isSSLVerifyDisabled" : false,
      "connectTimeoutInMs" : 1000,
      "readTimeoutInMs" : 250,
      "sendTimeoutInMs" : 1000
    }
  2. Guarde el archivo de configuración de caché con el nombre que desee. Por ejemplo, resp-cache-config.json
  3. Utilice el archivo de configuración de caché al crear o actualizar un gateway de API mediante la CLI:
    • Para crear un nuevo gateway de API con el almacenamiento en caché de respuesta activado, siga las instrucciones de la CLI en Creación de un gateway de API y defina el parámetro --response-cache-details en el nombre y la ubicación del archivo de configuración de caché. Por ejemplo:
      oci api-gateway gateway create --display-name "Hello World Gateway" --compartment-id ocid1.compartment.oc1..aaaaaaaa7______ysq --endpoint-type "PRIVATE" --subnet-id ocid1.subnet.oc1.iad.aaaaaaaaz______rca --response-cache-details file:///etc/caches/resp-cache-config.json
    • Para actualizar un gateway de API existente para activar el almacenamiento en caché de respuesta o cambiar los valores de almacenamiento en caché de respuesta, siga las instrucciones de la CLI en Actualización de un gateway de API y defina el parámetro --response-cache-details en el nombre y la ubicación del archivo de configuración de caché. Por ejemplo:
      oci api-gateway gateway update --gateway-id ocid1.apigateway.oc1..aaaaaaaab______hga --response-cache-details file:///etc/caches/resp-cache-config.json

Agregar solicitudes de almacenamiento en caché de respuesta y políticas de respuesta

Puede agregar políticas de solicitud y respuesta de almacenamiento en caché de respuesta a las especificaciones de despliegue de API a través de la consola o editando un archivo JSON. Tenga en cuenta que debe activar el almacenamiento en caché de respuesta en un gateway de API para que se apliquen las políticas de solicitud y respuesta.

Uso de la consola para agregar solicitudes de caché de respuesta y políticas de respuesta

Para agregar políticas de solicitud y políticas de respuesta de almacenamiento en caché de respuesta a una especificación de despliegue de API mediante la consola:

  1. Cree o actualice un despliegue de API con la consola, seleccione la opción Desde cero e introduzca los detalles en la página Información básica.

    Para obtener más información, consulte Despliegue de una API en un gateway de API mediante la creación de un despliegue de API y Actualización de un gateway de API.

  2. Seleccione Siguiente para introducir detalles de rutas individuales en el despliegue de API en la página Rutas y seleccione Almacenamiento en Caché de Respuesta.

  3. Seleccione la opción Almacenamiento en Caché para esta Ruta y especifique las opciones de almacenamiento en caché de respuesta que se aplican a esta ruta concreta:
    • TTL (tiempo de actividad) para respuestas en caché en segundos: tiempo durante el que los datos en caché están disponibles en el servidor de caché para esta ruta concreta.
    • Altas de Clave de Caché: una o más variables de contexto que agregar a la clave de caché por defecto para asociar más estrechamente una respuesta almacenada en caché a una solicitud concreta. Por ejemplo, request.headers[X-Username]. Puede seleccionar de una lista de variables de contexto de uso común o introducir una variable de contexto de su elección. No preceda a la variable de contexto con un símbolo $ ni la incluya entre corchetes (como haría si estuviera agregando la variable de contexto a una URL en una especificación de despliegue de API en un archivo JSON). Para obtener más información, consulte Notas sobre la personalización de claves de caché.
  4. Si desea almacenar en caché las respuestas de las solicitudes que contienen una cabecera de autorización o que contienen un parámetro de cabecera o consulta identificado en una política de autenticación, seleccione la opción Respuestas de Caché con Cabeceras de Autorización.

    Tenga en cuenta que el almacenamiento en caché de respuestas para dichas solicitudes puede comprometer la seguridad de los datos. Para obtener más información, consulte Notas sobre el almacenamiento en caché de respuestas para solicitudes que contienen credenciales (almacenamiento en caché privado).

  5. Seleccione Siguiente para revisar los detalles introducidos para el despliegue de API.
  6. Seleccione Crear o Guardar cambios para crear o actualizar el despliegue de API.
  7. (Opcional) Confirme que la API se ha desplegado correctamente llamándola. Para ello, consulte Llamada a una API desplegada en un gateway de API.

Edición de un archivo JSON para agregar solicitudes de caché de respuesta y políticas de respuesta

Para agregar el almacenamiento en caché de respuesta a una ruta determinada, debe agregar una política de solicitud y una política de respuesta.

Para agregar la solicitud de almacenamiento en caché de respuesta y la política de respuesta a una especificación de despliegue de API en un archivo JSON:

  1. Con su editor de JSON preferido, edite la especificación de despliegue de API existente a la que desea agregar el almacenamiento en caché de respuesta o cree una nueva especificación de despliegue de API (consulte Creación de una especificación de despliegue de API).

    Por ejemplo, la siguiente especificación básica de despliegue de API define una función sencilla de Hello World sin servidor en OCI Functions como un único backend:

    {
      "routes": [
        {
          "path": "/hello",
          "methods": ["GET"],
          "backend": {
            "type": "ORACLE_FUNCTIONS_BACKEND",
            "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
          }
        }
      ]
    }
  2. Para especificar la solicitud de almacenamiento en caché de respuesta y la política de respuesta que se aplica a una ruta individual:

    1. Introduzca una sección requestPolicies y una sección responsePolicies después de la sección de backend para la ruta a la que desea aplicar la política. Por ejemplo:

      {
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {},
            "responsePolicies": {}
          }
        ]
      }
    2. Agregue la siguiente política de solicitud responseCacheLookup a la nueva sección requestPolicies para aplicarla a la ruta:
      {
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {
              "responseCacheLookup": {
                "type": "SIMPLE_LOOKUP_POLICY",
                "isEnabled": true,
                "isPrivateCachingEnabled": <true|false>,
                "cacheKeyAdditions": [<list-of-context-variables>]
              }
            },
            "responsePolicies": {}
          }
        ]
      }

      donde:

      • "type": "SIMPLE_LOOKUP_POLICY" es el tipo de almacenamiento en caché de respuesta que se va a implantar. Actualmente sólo está soportada "SIMPLE_LOOKUP_POLICY".
      • "isEnabled": true indica que el almacenamiento en caché de respuesta está activado para la ruta. Si desea desactivar temporalmente el almacenamiento en caché de respuesta, defina "isEnabled": false. Si no se especifica, el valor por defecto es true.
      • "isPrivateCachingEnabled": <true|false> indica si se deben almacenar en caché las respuestas de las solicitudes que contienen una cabecera de autorización o que contienen una cabecera o un parámetro de consulta identificado en una política de autenticación. Tenga en cuenta que el almacenamiento en caché de respuestas para dichas solicitudes puede comprometer la seguridad de los datos. Si no se especifica, el valor por defecto es false, lo que indica que las respuestas para dichas solicitudes no se almacenan en caché. Para obtener más información, consulte Notas sobre el almacenamiento en caché de respuestas para solicitudes que contienen credenciales (almacenamiento en caché privado).
      • "cacheKeyAdditions": [<list-of-context-variables>] es una lista opcional separada por comas de variables de contexto que se agregarán a la clave de caché por defecto para asociar más estrechamente una respuesta almacenada en caché a una solicitud concreta. Por ejemplo, "cacheKeyAdditions": ["request.headers[Accept]"]. No anteponga un símbolo $ a la variable de contexto ni la incluya entre corchetes (como lo haría si estuviera agregando la variable de contexto a una URL en una especificación de despliegue de API en un archivo JSON). Para obtener más información, consulte Notas sobre la Personalización de Claves de Caché.
    3. Agregue la siguiente política de respuesta responseCacheStorage a la nueva sección responsePolicies para aplicarla a la ruta:
      {
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {
              "responseCacheLookup": {
                "type": "SIMPLE_LOOKUP_POLICY",
                "isEnabled": true,
                "isPrivateCachingEnabled": false,
                "cacheKeyAdditions": ["request.headers[Accept]"]
              }
            },
            "responsePolicies": {
              "responseCacheStorage": {
                "type": "FIXED_TTL_STORE_POLICY",
                "timeToLiveInSeconds": <seconds>
              }
            }
          }
        ]
      }

      donde:

      • "type": "FIXED_TTL_STORE_POLICY" es el tipo de caché de respuesta en la que se almacenan las respuestas. Actualmente sólo está soportada "FIXED_TTL_STORE_POLICY".
      • "timeToLiveInSeconds": <seconds> especifica el tiempo que los datos almacenados en caché están disponibles en el servidor de caché para esta ruta concreta. Por ejemplo, "timeToLiveInSeconds": 300

    Por ejemplo:

    {
      "routes": [
        {
          "path": "/hello",
          "methods": ["GET"],
          "backend": {
            "type": "ORACLE_FUNCTIONS_BACKEND",
            "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
          },
          "requestPolicies": {
            "responseCacheLookup": {
              "type": "SIMPLE_LOOKUP_POLICY",
              "isEnabled": true,
              "isPrivateCachingEnabled": false,
              "cacheKeyAdditions": ["request.headers[Accept]"]
            }
          },
          "responsePolicies": {
            "responseCacheStorage": {
              "type":"FIXED_TTL_STORE_POLICY",
              "timeToLiveInSeconds": 300
            }
          }
        }
      ]
    }
  3. Guarde el archivo JSON que contiene la especificación de despliegue de API.
  4. Utilice la especificación de despliegue de API al crear o actualizar un despliegue de API de las siguientes formas:

    • Especificando el archivo JSON en la consola al seleccionar la opción Cargar API.
    • Especificando el archivo JSON en una solicitud para la API REST de gateway de API.

    Para obtener más información, consulte Despliegue de una API en un gateway de API mediante la creación de un despliegue de API y Actualización de un gateway de API.

  5. (Opcional) Confirme que la API se ha desplegado correctamente llamándola. Para ello, consulte Llamada a una API desplegada en un gateway de API.