Transformación de solicitudes entrantes y respuestas salientes

Uso de la consola para agregar políticas de solicitudes de transformación de cabecera

Siga estos pasos para agregar políticas de solicitud 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ónDesde 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

2. Haga clic en Siguiente y especifique las opciones de autenticación en la página Autenticación.

   Para obtener más información sobre las opciones de autenticación, consulte Agregación de autenticación y autorización a despliegues de API.

3. Haga clic en Siguiente para introducir detalles de rutas individuales en el despliegue de API en la página Rutas.

4. En la página Rutas, seleccione la ruta para la que desea especificar las políticas de solicitud de transformación de cabecera.
5. Haga clic en Mostrar políticas de solicitud de ruta.
6. Haga clic en el botón Agregar junto a Transformaciones de cabecera para actualizar las cabeceras incluidas en una solicitud al gateway de API para la ruta actual.

7. Para limitar las cabeceras incluidas en una solicitud, especifique:

   • Acción: filtrar.
   • Tipo: Bloquear para eliminar de la solicitud las cabeceras que muestra explícitamente o Permitir que solo se permitan en la solicitud las cabeceras que muestra explícitamente (cualquier otra cabecera se elimina de la solicitud).
   • Nombres de cabecera: lista de cabeceras que se deben eliminar de la solicitud o permitir en la solicitud (según la configuración de Tipo). Los nombres especificados no son sensibles a mayúsculas/minúsculas y no se deben incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos filtrados según lo permitido). Por ejemplo, User-Agent.

8. Para cambiar el nombre de una cabecera incluida en una solicitud (manteniendo su valor original), especifique:

   • Acción: cambiar nombre.
   • Desde: el nombre original de la cabecera a la que le está cambiando el nombre. El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta. Por ejemplo, X-Username.
   • Para: el nombre nuevo de la cabecera a la que le va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas (se pueden ignorar las mayúsculas) y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, X-User-ID.

9. Para agregar una nueva cabecera a una solicitud (o para cambiar o retener los valores de una cabecera existente ya incluida en una solicitud), especifique:

   • Acción: definir.

   • Comportamiento: si la cabecera ya existe, especifique qué hacer con el valor existente de la cabecera:

     • Sobrescribir para sustituir el valor existente de la cabecera por el valor especificado.
     • Agregar para agregar el valor especificado al valor existente de la cabecera.
     • Omitir para mantener el valor existente de la cabecera.
   • Nombre: el nombre de la cabecera que se agregará a la solicitud (o para cambiar el valor). El nombre especificado no es sensible a mayúsculas/minúsculas (se pueden ignorar las mayúsculas) y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, X-Api-Key.
   • Valores: el valor de la nueva cabecera (o el valor que se va a sustituir o agregar al valor de una cabecera existente, según la configuración de Comportamiento). Puede especificar varios valores. El valor que especifique puede ser una cadena simple o puede incluir variables de contexto (excepto request.body) entre delimitadores ${...}. Por ejemplo, "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}".
10. Haga clic en Guardar cambios y, a continuación, haga clic en Siguiente para revisar los detalles introducidos para las rutas individuales.
11. Haga clic en Crear o en Guardar cambios para crear o actualizar el despliegue de API.
12. (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 políticas de solicitud de transformación de cabecera

Siga estos pasos para agregar políticas de solicitud de transformación de cabecera 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 una política de solicitud de transformación de cabecera 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 de despliegue de API básico 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. Inserte una sección requestPolicies después de la sección backend para la ruta a la que desea que se aplique la política de solicitud de transformación de cabecera. Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {}
       }
     ]
   }

3. Agregue una sección headerTransformations a la sección requestPolicies.

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations":{}
         }
       }
     ]
   }

4. Para limitar las cabeceras incluidas en una solicitud, especifique una política de solicitud de transformación de cabecera filterHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "filterHeaders": {
               "type": "<BLOCK|ALLOW>",
               "items": [
                 {
                   "name": "<header-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "type": "<BLOCK|ALLOW>" indica qué hacer con las cabeceras especificadas por "items":[{"name":"<header-name>"}]:
     • Utilice BLOCK para eliminar de la solicitud las cabeceras que muestra explícitamente.
     • Utilice ALLOW para permitir solo en la solicitud las cabeceras que muestra explícitamente (cualquier otra cabecera se elimina de la solicitud).
   • "name":"<header-name> es una cabecera que se debe eliminar de la solicitud o permitir en la solicitud (según la configuración de "type": "<BLOCK|ALLOW>"). El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, User-Agent.

   Puede eliminar y permitir hasta 50 cabeceras en una política de solicitud de transformación de cabecera filterHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "filterHeaders": {
               "type": "BLOCK",
               "items": [
                 {
                   "name": "User-Agent"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API elimina la cabecera User-Agent de todas las solicitudes entrantes.

5. Para cambiar el nombre de una cabecera incluida en una solicitud (manteniendo su valor original), especifique una política de solicitud de transformación de cabecera renameHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "renameHeaders": {
               "items": [
                 {
                   "from": "<original-name>",
                   "to": "<new-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "from": "<original-name>" es el nombre original de la cabecera a la que va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta. Por ejemplo, X-Username.
   • "to": "<new-name>" es el nuevo nombre de la cabecera a la que va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas (se pueden ignorar las mayúsculas) y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-User-ID.

   Puede cambiar el nombre de hasta 20 cabeceras en una política de solicitud de transformación de cabecera renameHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "renameHeaders": {
               "items": [
                 {
                   "from": "X-Username",
                   "to": "X-User-ID"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API cambia el nombre de cualquier cabecera X-Username a X-User-ID, manteniendo el valor original de la cabecera.

6. Para agregar una nueva cabecera a una solicitud (o para cambiar o retener los valores de una cabecera existente ya incluida en una solicitud), especifique una política de solicitud de transformación de cabecera setHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "setHeaders": {
               "items": [
                 {
                   "name": "<header-name>",
                   "values": ["<header-value>"],
                   "ifExists": "<OVERWRITE|APPEND|SKIP>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "name":"<header-name> es el nombre de la cabecera que se agregará a la solicitud (o para cambiar el valor). El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-Api-Key.
   • "values": ["<header-value>"] es el valor de la nueva cabecera (o el valor que se va a sustituir o agregar al valor de una cabecera existente, según el valor "ifExists": "<OVERWRITE|APPEND|SKIP>"). El valor que especifique puede ser una cadena simple o puede incluir variables de contexto (excepto request.body) entre delimitadores ${...}. Por ejemplo, "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".

     Puede especificar hasta 10 valores. Si especifica varios valores, el gateway de API agrega una cabecera para cada valor.

   • "ifExists": "<OVERWRITE|APPEND|SKIP>" indica qué hacer con el valor existente de la cabecera si la cabecera especificada por <header-name> ya existe:

     • Utilice OVERWRITE para sustituir el valor existente de la cabecera por el valor especificado.
     • Utilice APPEND para agregar el valor especificado al valor existente de la cabecera.
     • Utilice SKIP para mantener el valor existente de la cabecera.

     Si no se especifica, el valor por defecto es OVERWRITE.

   Puede agregar (o cambiar los valores de) hasta 20 cabeceras en una política de solicitud de transformación de cabecera setHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "headerTransformations": {
             "setHeaders": {
               "items": [
                 {
                   "name": "X-Api-Key",
                   "values": ["zyx987wvu654tsu321"],
                   "ifExists": "OVERWRITE"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API agrega la cabecera X-Api-Key:zyx987wvu654tsu321 a todas las solicitudes entrantes. Si una solicitud entrante ya tiene una cabecera X-Api-Key definida en un valor diferente, el gateway de API sustituye el valor existente por zyx987wvu654tsu321.

7. Guarde el archivo JSON que contiene la especificación de despliegue de API.

8. 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 existente.
   • 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

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

Uso de la consola para agregar políticas de solicitudes de transformación de parámetros de consulta

Para agregar políticas de solicitud de transformación de parámetros de consulta 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ónDesde 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

2. Haga clic en Siguiente y especifique las opciones de autenticación en la página Autenticación.

   Para obtener más información sobre las opciones de autenticación, consulte Agregación de autenticación y autorización a despliegues de API.

3. Haga clic en Siguiente para introducir detalles de rutas individuales en el despliegue de API en la página Rutas.

4. En la página Rutas, seleccione la ruta para la que desea especificar las políticas de solicitud de transformación de parámetros de consulta.
5. Haga clic en Mostrar políticas de solicitud de ruta.
6. Haga clic en el botón Agregar junto a Transformaciones de parámetros de consulta para actualizar los parámetros de consulta incluidos en una solicitud al gateway de API para la ruta actual.

7. Para limitar los parámetros de consulta incluidos en una solicitud, especifique:

   • Acción: filtrar.
   • Tipo: Bloquear para eliminar de la solicitud los parámetros de consulta que muestra explícitamente o Permitir para permitir en la solicitud solo los parámetros de consulta que muestra explícitamente (cualquier otro parámetro de consulta se elimina de la solicitud).
   • Nombres de parámetros de consulta: lista de parámetros de consulta que se deben eliminar de la solicitud o permitir en la solicitud (según el valor de Tipo). Los nombres que especifique son sensibles a mayúsculas/minúsculas y no se deben incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, User-Agent.

8. Para cambiar el nombre de un parámetro de consulta incluido en una solicitud (manteniendo su valor original), especifique:

   • Acción: cambiar nombre.
   • Desde: el nombre original del parámetro de consulta al que le va a cambiar el nombre. El nombre especificado es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta. Por ejemplo, X-Username.
   • Para: el nombre nuevo del parámetro de consulta al que le va a cambiar el nombre. El nombre especificado es sensible a mayúsculas/minúsculas (se respetan las mayúsculas) y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, X-User-ID.

9. Para agregar un nuevo parámetro de consulta a una solicitud (o para cambiar o retener los valores de un parámetro de consulta existente ya incluido en una solicitud), especifique:

   • Acción: definir.

   • Comportamiento: si el parámetro de consulta ya existe, especifique qué hacer con el valor existente del parámetro de consulta:

     • Sobrescribir para sustituir el valor existente del parámetro de consulta por el valor especificado.
     • Agregar para agregar el valor especificado al valor existente del parámetro de consulta.
     • Omitir para mantener el valor existente del parámetro de consulta.
   • Nombre de parámetro de consulta: el nombre del parámetro de consulta que se va a agregar a la solicitud (o para cambiar el valor). El nombre especificado es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, X-Api-Key.
   • Valores: valor del nuevo parámetro de consulta (o valor para sustituir o agregar al valor de un parámetro de consulta existente, según la configuración de Comportamiento). El valor que especifique puede ser una cadena simple o puede incluir variables de contexto entre delimitadores ${...}. Por ejemplo, "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}". Puede especificar varios valores.
10. Haga clic en Guardar cambios y, a continuación, haga clic en Siguiente para revisar los detalles introducidos para las rutas individuales.
11. Haga clic en Crear o en Guardar cambios para crear o actualizar el despliegue de API.
12. (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 políticas de solicitud de transformación de parámetros de consulta

Para agregar políticas de solicitud de transformación de parámetros de consulta 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 una política de solicitud de transformación de parámetros de consulta 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 de despliegue de API básico 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. Inserte una sección requestPolicies después de la sección backend para la ruta a la que desea aplicar la política de solicitud de transformación de parámetros de consulta. Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {}
       }
     ]
   }

3. Agregue una sección queryParameterTransformations a la sección requestPolicies.

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations":{}
         }
       }
     ]
   }

4. Para limitar los parámetros de consulta incluidos en una solicitud, especifique una política de solicitud de transformación de parámetros de consulta filterQueryParameters:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "filterQueryParameters": {
               "type": "<BLOCK|ALLOW>",
               "items": [
                 {
                   "name": "<query-parameter-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "type": "<BLOCK|ALLOW>" indica qué hacer con los parámetros de consulta especificados por "items":[{"name":"<query-parameter-name>"}]:
     • Utilice BLOCK para eliminar de la solicitud los parámetros de consulta que muestra explícitamente.
     • Utilice ALLOW para permitir en la solicitud solo los parámetros de consulta que muestra explícitamente (cualquier otro parámetro de consulta se elimina de la solicitud).
   • "name":"<query-parameter-name> es un parámetro de consulta que se debe eliminar de la solicitud o permitir en la solicitud (según la configuración de "type": "<BLOCK|ALLOW>"). El nombre especificado es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, User-Agent.

   Puede eliminar y permitir hasta 50 parámetros de consulta en una política de solicitud de transformación de parámetros de consulta filterQueryParameters.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "filterQueryParameters": {
               "type": "BLOCK",
               "items": [
                 {
                   "name": "User-Agent"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API elimina el parámetro de consulta User-Agent de todas las solicitudes entrantes.

5. Para cambiar el nombre de un parámetro de consulta incluido en una solicitud (manteniendo su valor original), especifique una política de solicitud de transformación de parámetros de consulta renameQueryParameters:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "renameQueryParameters": {
               "items": [
                 {
                   "from": "<original-name>",
                   "to": "<new-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "from": "<original-name>" es el nombre original del parámetro de consulta al que le va a cambiar el nombre. El nombre especificado es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta. Por ejemplo, X-Username.
   • "to": "<new-name>" es el nuevo nombre del parámetro de consulta al que le va a cambiar el nombre. El nombre especificado es sensible a mayúsculas/minúsculas (se respetan las mayúsculas) y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-User-ID.

   Puede cambiar el nombre de hasta 20 parámetros de consulta en una política de solicitud de transformación de parámetros de consulta renameQueryParameters.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "renameQueryParameters": {
               "items": [
                 {
                   "from": "X-Username",
                   "to": "X-User-ID"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API cambia el nombre de cualquier parámetro de consulta X-Username a X-User-ID, manteniendo al mismo tiempo el valor original del parámetro de consulta.

6. Para agregar un nuevo parámetro de consulta a una solicitud (o para cambiar o retener los valores de un parámetro de consulta existente ya incluido en una solicitud), especifique una política de solicitud de transformación de parámetros de consulta setQueryParameters:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "setQueryParameters": {
               "items": [
                 {
                   "name": "<query-parameter-name>",
                   "values": ["<query-parameter-value>"],
                   "ifExists": "<OVERWRITE|APPEND|SKIP>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "name": "<query-parameter-name>" es el nombre del parámetro de consulta que se agregará a la solicitud (o para cambiar el valor). El nombre especificado es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de solicitud de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-Api-Key.
   • "values": ["<query-parameter-value>"] es el valor del nuevo parámetro de consulta (o el valor que se va a sustituir o agregar al valor de un parámetro de consulta existente, según el valor "ifExists": "<OVERWRITE|APPEND|SKIP>"). El valor que especifique puede ser una cadena simple o puede incluir variables de contexto entre delimitadores ${...}. Por ejemplo, "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".

     Puede especificar hasta 10 valores. Si especifica varios valores, el gateway de API agrega un parámetro de consulta para cada valor.

   • "ifExists": "<OVERWRITE|APPEND|SKIP>" indica qué hacer con el valor existente del parámetro de consulta si el parámetro de consulta especificado por <query-parameter-name> ya existe:

     • Utilice OVERWRITE para sustituir el valor existente del parámetro de consulta por el valor especificado.
     • Utilice APPEND para agregar el valor especificado al valor existente del parámetro de consulta.
     • Utilice SKIP para mantener el valor existente del parámetro de consulta.

     Si no se especifica, el valor por defecto es OVERWRITE.

   Puede agregar hasta 20 parámetros de consulta (o cambiar sus valores) en una política de solicitud de transformación de parámetros de consulta setQueryParameters.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "requestPolicies": {
           "queryParameterTransformations": {
             "setQueryParameters": {
               "items": [
                 {
                   "name": "X-Api-Key",
                   "values": ["zyx987wvu654tsu321"],
                   "ifExists": "OVERWRITE"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API agrega el parámetro de consulta X-Api-Key:zyx987wvu654tsu321 a todas las solicitudes entrantes. Si una solicitud entrante ya tiene un parámetro de consulta X-Api-Key definido en un valor diferente, el gateway de API sustituye el valor existente por zyx987wvu654tsu321.

7. Guarde el archivo JSON que contiene la especificación de despliegue de API.

8. 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 existente.
   • 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

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

Uso de la consola para agregar políticas de respuesta de transformación de cabecera

Para agregar políticas de respuesta de transformación de cabecera 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ónDesde 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

2. Haga clic en Siguiente y especifique las opciones de autenticación en la página Autenticación.

   Para obtener más información sobre las opciones de autenticación, consulte Agregación de autenticación y autorización a despliegues de API.

3. Haga clic en Siguiente para introducir detalles de rutas individuales en el despliegue de API en la página Rutas.

4. En la página Rutas, seleccione la ruta para la que desea especificar políticas de respuesta de transformación de cabecera.
5. Haga clic en Mostrar políticas de respuesta de ruta.
6. Haga clic en el botón Agregar junto a Transformaciones de cabecera para actualizar las cabeceras incluidas en una respuesta desde el gateway de API para la ruta actual.

7. Para limitar las cabeceras incluidas en una respuesta, especifique:

   • Acción: filtrar.
   • Tipo: Bloquear para eliminar de la respuesta las cabeceras que muestra explícitamente o Permitir para permitir en la respuesta solo las cabeceras que muestra explícitamente (cualquier otra cabecera se elimina de la respuesta).
   • Nombres de cabecera: lista de cabeceras que se deben eliminar de la respuesta o permitir en la respuesta (según la configuración del Tipo). Los nombres que especifique no son sensibles a mayúsculas/minúsculas y no se deben incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, User-Agent.

8. Para cambiar el nombre de una cabecera incluida en una respuesta (manteniendo su valor original), especifique:

   • Acción: cambiar nombre.
   • Desde: el nombre original de la cabecera a la que le está cambiando el nombre. El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta. Por ejemplo, X-Username.
   • Para: el nombre nuevo de la cabecera a la que le va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas (se pueden ignorar las mayúsculas) y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-User-ID.

9. Para agregar una nueva cabecera a una respuesta (o para cambiar o retener los valores de una cabecera existente ya incluida en una respuesta), especifique:

   • Acción: definir.

   • Comportamiento: si la cabecera ya existe, especifique qué hacer con el valor existente de la cabecera:

     • Sobrescribir para sustituir el valor existente de la cabecera por el valor especificado.
     • Agregar para agregar el valor especificado al valor existente de la cabecera.
     • Omitir para mantener el valor existente de la cabecera.
   • Nombre: nombre de la cabecera que se va a agregar a la respuesta (o para cambiar el valor). El nombre que especifique no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos que filtra según lo permitido). Por ejemplo, X-Api-Key.
   • Valores: el valor de la nueva cabecera (o el valor que se va a sustituir o agregar al valor de una cabecera existente, según la configuración de Comportamiento). El valor que especifique puede ser una cadena simple o puede incluir variables de contexto entre delimitadores ${...}. Por ejemplo, "value": "zyx987wvu654tsu321". Puede especificar varios valores.
10. Haga clic en Guardar cambios y, a continuación, haga clic en Siguiente para revisar los detalles introducidos para las rutas individuales.
11. Haga clic en Crear o en Guardar cambios para crear o actualizar el despliegue de API.
12. (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 políticas de respuesta de transformación de cabecera

Para agregar políticas de respuesta de transformación de cabecera 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 una política de respuesta de transformación de cabecera 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 de despliegue de API básico 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. Inserte una sección responsePolicies después de la sección backend para la ruta a la que desea que se aplique la política de respuesta de transformación de cabecera. Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {}
       }
     ]
   }

3. Agregue una sección headerTransformations a la sección responsePolicies.

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations":{}
         }
       }
     ]
   }

4. Para limitar las cabeceras incluidas en una respuesta, especifique una política de respuesta de transformación de cabecera filterHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "filterHeaders": {
               "type": "<BLOCK|ALLOW>",
               "items": [
                 {
                   "name": "<header-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "type": "<BLOCK|ALLOW>" indica qué hacer con las cabeceras especificadas por "items":[{"name":"<header-name>"}]:
     • Utilice BLOCK para eliminar de la respuesta las cabeceras que muestra explícitamente.
     • Utilice ALLOW para permitir solo en la respuesta las cabeceras que muestra explícitamente (cualquier otra cabecera se elimina de la respuesta).
   • "name":"<header-name> es una cabecera para eliminar de la respuesta o permitir en la respuesta (según la configuración de "type": "<BLOCK|ALLOW>"). El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, User-Agent.

   Puede eliminar y permitir hasta 20 cabeceras en una política de respuesta de transformación de cabecera filterHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "filterHeaders": {
               "type": "BLOCK",
               "items": [
                 {
                   "name": "User-Agent"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API elimina la cabecera User-Agent de todas las respuestas salientes.

5. Para cambiar el nombre de una cabecera incluida en una respuesta (manteniendo su valor original), especifique una política de respuesta de transformación de cabecera renameHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "renameHeaders": {
               "items": [
                 {
                   "from": "<original-name>",
                   "to": "<new-name>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "from": "<original-name>" es el nombre original de la cabecera a la que va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta. Por ejemplo, X-Username.
   • "to": "<new-name>" es el nuevo nombre de la cabecera a la que va a cambiar de nombre. El nombre especificado no es sensible a mayúsculas/minúsculas (se pueden ignorar las mayúsculas) y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-User-ID.

   Puede cambiar el nombre de hasta 20 cabeceras en una política de respuesta de transformación de cabecera renameHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "renameHeaders": {
               "items": [
                 {
                   "from": "X-Username",
                   "to": "X-User-ID"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API cambia el nombre de cualquier cabecera X-Username a X-User-ID, manteniendo el valor original de la cabecera.

6. Para agregar una nueva cabecera a una respuesta (o para cambiar o retener los valores de una cabecera existente ya incluida en una respuesta), especifique una política de respuesta de transformación de cabecera setHeaders:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "setHeaders": {
               "items": [
                 {
                   "name": "<header-name>",
                   "values": ["<header-value>"],
                   "ifExists": "<OVERWRITE|APPEND|SKIP>"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   donde:

   • "name":"<header-name> es el nombre de la cabecera que se agregará a la respuesta (o para cambiar el valor). El nombre especificado no es sensible a mayúsculas/minúsculas y no se debe incluir en ninguna otra política de respuesta de transformación para la ruta (con la excepción de los elementos de las listas ALLOW). Por ejemplo, X-Api-Key.
   • "values": ["<header-value>"] es el valor de la nueva cabecera (o el valor que se va a sustituir o agregar al valor de una cabecera existente, según el valor "ifExists": "<OVERWRITE|APPEND|SKIP>"). El valor que especifique puede ser una cadena simple o puede incluir variables de contexto entre delimitadores ${...}. Por ejemplo, "values": "zyx987wvu654tsu321".

     Puede especificar hasta 10 valores. Si especifica varios valores, el gateway de API agrega una cabecera para cada valor.

   • "ifExists": "<OVERWRITE|APPEND|SKIP>" indica qué hacer con el valor existente de la cabecera si la cabecera especificada por <header-name> ya existe:

     • Utilice OVERWRITE para sustituir el valor existente de la cabecera por el valor especificado.
     • Utilice APPEND para agregar el valor especificado al valor existente de la cabecera.
     • Utilice SKIP para mantener el valor existente de la cabecera.

     Si no se especifica, el valor por defecto es OVERWRITE.

   Puede agregar (o cambiar los valores de) hasta 20 cabeceras en una política de respuesta de transformación de cabecera setHeaders.

   Por ejemplo:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         },
         "responsePolicies": {
           "headerTransformations": {
             "setHeaders": {
               "items": [
                 {
                   "name": "X-Api-Key",
                   "values": ["zyx987wvu654tsu321"],
                   "ifExists": "OVERWRITE"
                 }
               ]
             }
           }
         }
       }
     ]
   }

   En este ejemplo, el gateway de API agrega la cabecera X-Api-Key:zyx987wvu654tsu321 a todas las respuestas salientes. Si una respuesta saliente ya tiene una cabecera X-Api-Key definida en un valor diferente, el gateway de API sustituye el valor existente por zyx987wvu654tsu321.

7. Guarde el archivo JSON que contiene la especificación de despliegue de API.

8. 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 existente.
   • 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 a través de la creación de un despliegue de API y Actualización de un gateway de API o un despliegue de API.

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

Ejemplo 1: transformación de parámetros de cabecera en parámetros de consulta

En este ejemplo, supongamos que un backend HTTP existente solo maneja solicitudes que contienen parámetros de consulta, no parámetros de cabecera. Sin embargo, desea que el backend HTTP maneje solicitudes que incluyen parámetros de cabecera. Para ello, cree una especificación de despliegue de API que incluya una política de solicitud de transformación de parámetros de consulta para transferir el valor obtenido de una cabecera de solicitud al backend HTTP como parámetro de consulta.

        "requestPolicies": {
          "queryParameterTransformations":  {
            "setQueryParameters": {
              "items": [
                {
                  "name": "region",
                  "values": ["${request.headers[region]}"],
                  "ifExists": "OVERWRITE"
                }
              ]
            }
          }
        }

En este ejemplo, una solicitud como curl -H "region: west" https://<gateway-hostname>/marketing/weather se resuelve en https://api.weather.gov?region=west.

Ejemplo 2: transformación de una cabecera en otra

En este ejemplo, supongamos que un backend HTTP existente solo maneja solicitudes que contienen una cabecera concreta. Sin embargo, desea que el backend HTTP maneje solicitudes que incluyen una cabecera diferente. Para lograrlo, cree una especificación de despliegue de API que incluya una política de solicitud de transformación de cabecera para adoptar el valor obtenido de una cabecera de solicitud y transferirla al backend HTTP como una cabecera de solicitud diferente.

        "requestPolicies": {
          "headerTransformations": {
            "setHeaders": {
              "items": [
                {
                  "name": "region",
                  "values": ["${request.headers[locale]}"],
                  "ifExists": "OVERWRITE"
                }
              ]
            }
          }
        }

En este ejemplo, una solicitud como curl -H "locale: west" https://<gateway-hostname>/marketing/weather se resuelve en la solicitud curl -H "region: west" https://api.weather.gov.

Ejemplo 3: agregación de un parámetro de autenticación obtenido de un JWT como cabecera de solicitud

En este ejemplo, supongamos que un backend HTTP existente requiere que el valor de la reclamación sub en un token web JSON (JWT) validado se incluya en una solicitud como cabecera con el nombre JWT_SUBJECT. El servicio de gateway de API ha guardado el valor de la reclamación sub incluida en el JWT como parámetro de autenticación en la tabla request.auth.

Para incluir el valor sub en una cabecera denominada JWT_SUBJECT, cree una especificación de despliegue de API que incluya una política de solicitud de transformación de cabecera. La política de solicitud obtiene el valor sub de la tabla request.auth y lo transfiere al backend HTTP como valor de la cabecera JWT_SUBJECT.

        "requestPolicies": {
          "headerTransformations": {
            "setHeaders": {
              "items": [
                {
                  "name": "JWT_SUBJECT",
                  "values": ["${request.auth[sub]}"],
                  "ifExists": "OVERWRITE"
                }
              ]
            }
          }
        }

En este ejemplo, cuando una solicitud se ha validado correctamente, la cabecera JWT_SUBJECT se agrega a la solicitud transferida al backend HTTP.

Ejemplo 4: agregación de una clave obtenida de una función de autorizador como parámetro de consulta

En este ejemplo, supongamos que un backend HTTP existente requiere que las solicitudes incluyan un parámetro de consulta denominado access_key con fines de autenticación. Desea que el parámetro de consulta access_key tenga el valor de una clave denominada apiKey que ha devuelto una función de autorizador que ha validado correctamente la solicitud. El servicio de gateway de API ha guardado el valor apiKey como parámetro de autenticación en la tabla request.auth.

Para incluir el parámetro de consulta access_key en la solicitud, cree una especificación de despliegue de API que incluya una política de solicitud de transformación de parámetros de consulta. La política de solicitud obtiene el valor apiKey de la tabla request.auth y lo transfiere al backend HTTP como valor del parámetro de consulta access_key.

        "requestPolicies": {
          "queryParameterTransformations": {
            "setQueryParameters": {
              "items": [
                {
                  "name": "access_key",
                  "values": ["${request.auth[apiKey]}"],
                  "ifExists": "OVERWRITE"
                }
              ]
            }
          }
        }

En este ejemplo, el parámetro de consulta access_key se agrega a la solicitud transferida al backend HTTP, con el valor apiKey de la tabla request.auth. Una solicitud como https://<gateway-hostname>/marketing/weather se resuelve en una solicitud como https://api.weather.gov?access_key=fw5n9abi0ep

Ejemplo 5: agregación de un valor por defecto para un parámetro de consulta opcional

En este ejemplo, supongamos que un backend HTTP existente requiere que las solicitudes incluyan un parámetro de consulta denominado country. Sin embargo, el parámetro de consulta country es opcional y no lo incluyen algunas de las solicitudes de envío de clientes de API. Si una solicitud ya incluye un parámetro de consulta country y un valor, desea que ambos se transfieran tal como están al backend HTTP. Sin embargo, si una solicitud aún no incluye un parámetro de consulta country, desea agregar el parámetro de consulta country y un valor por defecto a la solicitud.

Para asegurarse de que cada solicitud incluye un parámetro de consulta country, cree una especificación de despliegue de API que incluya una política de solicitud de transformación de parámetros de consulta. La política de solicitud agrega el parámetro de consulta country y un valor por defecto a cualquier solicitud que aún no incluya el parámetro de consulta country.

        "requestPolicies": {
          "queryParameterTransformations": {
            "setQueryParameters": {
              "items": [
                {
                  "name": "country",
                  "values": ["usa"],
                  "ifExists": "SKIP"
                }
              ]
            }
          }
        }

En este ejemplo, una solicitud como https://<gateway-hostname>/marketing/weather se resuelve en https://api.weather.gov?country=usa. Una solicitud como https://<gateway-hostname>/marketing/weather?country=canada se resuelve en https://api.weather.gov?country=canada.