Transformation des demandes entrantes et des réponses sortantes

Découvrez comment modifier les demandes entrantes et les réponses sortantes envoyées vers et depuis les services dorsaux avec la passerelle d'API.

Il y a souvent des situations où vous voulez qu'une passerelle d'API modifie les demandes entrantes avant de les envoyer aux services dorsaux. De même, il est possible que vous vouliez que la passerelle d'API modifie les réponses retournées par les services dorsaux. Par exemple :

Les services dorsaux peuvent nécessiter que les demandes incluent un jeu particulier d'en-têtes HTTP (par exemple, Accept-Language et Accept-Encoding). Pour masquer ces détails de mise en oeuvre auprès des consommateurs de l'API, vous pouvez utiliser la passerelle d'API afin d'ajouter les en-têtes requis.
Les serveurs Web incluent souvent des informations complètes sur la version dans les en-têtes de réponse. Pour des raisons de sécurité, vous pouvez empêcher les consommateurs de l'API de connaître la pile technologique sous-jacente. Vous pouvez utiliser la passerelle d'API pour supprimer les en-têtes de serveur des réponses.
Les services dorsaux peuvent inclure des informations sensibles dans une réponse. Vous pouvez utiliser la passerelle d'API pour supprimer ces informations.

À l'aide d'une passerelle d'API, vous pouvez effectuer les opérations suivantes :

Ajouter, supprimer et modifier des en-têtes dans les demandes et les réponses.
Ajouter, supprimer et modifier des paramètres d'interrogation dans les demandes.
Réécrire les URL de demande d'un format public à un format interne, peut-être pour prendre en charge les applications existantes et les migrations.

Vous utilisez des politiques de demande et de réponse pour transformer les en-têtes et les paramètres d'interrogation des demandes entrantes, ainsi que les en-têtes des réponses sortantes (voir Ajout de politiques de demande et de politiques de réponse aux spécifications de déploiement d'API).

Vous pouvez inclure des variables de contexte dans les politiques de demande et de réponse de transformation d'en-tête et de paramètre d'interrogation. L'inclusion de variables de contexte vous permet de modifier les en-têtes et les paramètres d'interrogation avec les valeurs d'autres en-têtes, paramètres d'interrogation, paramètres de chemin et paramètres d'authentification. Notez que les valeurs des variable de contexte sont extraites de la demande ou de la réponse initiale et ne sont pas mises à jour ultérieurement, car la passerelle d'API utilise une politique de transformation pour évaluer une demande ou une réponse. Pour plus d'informations sur les variables de contexte, voir Ajout de variables de contexte aux politiques et aux définitions d'élément dorsal HTTP.

Si une politique de demande ou de réponse de transformation d'en-tête ou de paramètre d'interrogation résulte en un en-tête ou un paramètre d'interrogation non valide, la politique de transformation est ignorée.

Notez que vous ne pouvez pas utiliser de politiques de transformation d'en-tête pour transformer certains en-têtes de demande et de réponse protégés. Voir En-têtes de demande protégée et en-têtes de réponse.

Vous pouvez ajouter des politiques de demande et de réponse de transformation d'en-tête et de paramètre d'interrogation à une spécification de déploiement d'API en :

En utilisant la console.
En modifiant un fichier JSON.

Ajout de politiques de demande de transformation d'en-tête

Vous pouvez ajouter des politiques de demande de transformation d'en-tête aux spécifications de déploiement d'API à l'aide de la console ou en modifiant un fichier JSON.

Notez que vous ne pouvez pas utiliser de stratégies de transformation d'en-tête pour transformer certains en-têtes de demande protégés. Voir En-têtes de demande protégée et en-têtes de réponse.

Utilisation de la console pour ajouter des politiques de demande de transformation d'en-tête

Pour ajouter des politiques de demande de transformation d'en-tête à une spécification de déploiement d'API à l'aide de la console :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
Sélectionnez Suivant et spécifiez les options d'authentification dans la page Authentification.

Pour plus d'informations sur les options d'authentification, voir Ajout de l'authentification et de l'autorisation aux déploiements d'API.
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la page Routes, sélectionnez la route pour laquelle vous souhaitez spécifier des politiques de demande de transformation d'en-tête.
Sélectionnez Afficher les politiques de demande de routage.
Sélectionnez le bouton Ajouter à côté de Transformations d'en-tête pour mettre à jour les en-têtes inclus dans une demande à la passerelle d'API pour la route courante.
Pour limiter les en-têtes inclus dans une demande, spécifiez les données suivantes :
- Action : Filtrer.
- Type : Bloquer pour supprimer de la demande les en-têtes que vous listez explicitement ou Autoriser pour autoriser uniquement dans la demande les en-têtes que vous listez explicitement (tous les autres en-têtes sont supprimés de la demande).
- Noms d'en-tête : Liste des en-têtes à supprimer ou à autoriser pour la demande (selon le paramètre Type). Les noms que vous spécifiez ne sont pas sensibles à la casse et ne doivent pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple User-Agent.
Pour modifier le nom d'un en-tête inclus dans une demande (tout en conservant sa valeur initiale), spécifiez les données suivantes :
- Action : Renommer.
- De : Nom initial de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route. Par exemple X-Username.
- À : Nouveau nom de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-User-ID.
Pour ajouter un nouvel en-tête à une demande (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une demande), spécifiez les données suivantes :
- Action : Définir.
- Comportement : Si l'en-tête existe déjà, spécifiez ce qu'il faut faire avec la valeur existante de l'en-tête :
  - Remplacer, pour remplacer la valeur existante de l'en-tête par la valeur que vous spécifiez.
  - Ajouter, pour ajouter la valeur que vous spécifiez à la valeur existante de l'en-tête.
  - Ignorer, pour conserver la valeur existante de l'en-tête.
- Nom : Nom de l'en-tête à ajouter à la demande (ou pour en modifier la valeur). Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-Api-Key.
- Valeurs : Valeur du nouvel en-tête (ou valeur à remplacer ou à ajouter à la valeur d'un en-tête existant, selon le paramètre Comportement). Vous pouvez spécifier plusieurs valeurs. La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte (à l'exception de request.body) entourées des délimiteurs ${...}. Par exemple "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}".
Sélectionnez Enregistrer les modifications, puis Suivant pour vérifier les détails que vous avez entrés pour chaque route.
Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des politiques de demande de transformation d'en-tête

Pour ajouter des politiques de demande de transformation d'en-tête à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter des politiques de demande de transformation d'en-tête ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Insérez une section requestPolicies après la section backend pour la route à laquelle vous voulez appliquer la politique de demande de transformation d'en-tête. Par exemple :

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

Ajoutez une section headerTransformations à la section requestPolicies.

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

Pour limiter les en-têtes inclus dans une demande, spécifiez une politique de demande de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "type": "<BLOCK|ALLOW>" indique ce qu'il faut faire avec les en-têtes spécifiés par "items":[{"name":"<header-name>"}] :
  - Utilisez BLOCK pour supprimer de la demande les en-têtes que vous listez explicitement.
  - Utilisez ALLOW pour autoriser uniquement dans la demande les en-têtes que vous listez explicitement (tous les autres en-têtes sont supprimés de la demande).
- "name": "<header-name> est un en-tête à supprimer ou à autoriser pour la demande (selon le paramètre "type":" <BLOCK|ALLOW>"). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple User-Agent.
Vous pouvez supprimer et autoriser jusqu'à 50 en-têtes dans une politique de demande de transformation d'en-tête filterHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API supprime l'en-tête User-Agent de toutes les demandes entrantes.
Pour modifier le nom d'un en-tête inclus dans une demande (tout en conservant sa valeur initiale), spécifiez une politique de demande de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "from": "<original-name>" est le nom initial de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route. Par exemple X-Username.
- "to": "<new-name>" est le nouveau nom de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-User-ID.
Vous pouvez renommer jusqu'à 20 en-têtes dans une politique de demande de transformation d'en-tête renameHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API renomme tous les en-têtes X-Username à X-User-ID, tout en conservant la valeur initiale de l'en-tête.
Pour ajouter un nouvel en-tête à une demande (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une demande), spécifiez une politique de demande de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "name":"<header-name> est le nom de l'en-tête à ajouter à la demande (ou pour en modifier la valeur). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-Api-Key.
- "valeurs": ["<header-value>"] est la valeur du nouvel en-tête (ou la valeur à remplacer ou à ajouter à la valeur d'un en-tête existant, selon le paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte (à l'exception de request.body) entourées des délimiteurs ${...}. Par exemple "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".
  Vous pouvez spécifier jusqu'à 10 valeurs. Si vous spécifiez plusieurs valeurs, la passerelle d'API ajoute un en-tête pour chaque valeur.
- "ifExiste": "<OVERWRITE|APPEND|SKIP>" indique ce qu'il faut faire avec la valeur existante de l'en-tête si l'en-tête spécifié par <header-name> existe déjà :
  - Utilisez OVERWRITE pour remplacer la valeur existante de l'en-tête par la valeur que vous spécifiez.
  - Utilisez APPEND pour ajouter la valeur que vous spécifiez à la valeur existante de l'en-tête.
  - Utilisez SKIP pour conserver la valeur existante de l'en-tête.
  Si elle n'est pas spécifiée, la valeur par défaut est OVERWRITE.
Vous pouvez ajouter (ou modifier) jusqu'à 20 en-têtes dans une politique de demande de transformation d'en-tête setHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API ajoute l'en-tête X-Api-Key:zyx987wvu654tsu321 à toutes les demandes entrantes. Si l'en-tête X-Api-Key d'une demande entrante est déjà réglé à une valeur différente, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
Utilisez comme suit la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API :
- En spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Ajout de politiques de demande de transformation de paramètre d'interrogation

Vous pouvez ajouter des politiques de demande de transformation de paramètre d'interrogation aux spécifications de déploiement d'API à l'aide de la console ou en modifiant un fichier JSON.

Utilisation de la console pour ajouter des politiques de demande de transformation de paramètre d'interrogation

Pour ajouter des politiques de demande de transformation de paramètre d'interrogation à une spécification de déploiement d'API à l'aide de la console :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
Sélectionnez Suivant et spécifiez les options d'authentification dans la page Authentification.

Pour plus d'informations sur les options d'authentification, voir Ajout de l'authentification et de l'autorisation aux déploiements d'API.
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la page Routes, sélectionnez la route pour laquelle vous souhaitez spécifier des politiques de demande de transformation de paramètre d'interrogation.
Sélectionnez Afficher les politiques de demande de routage.
Sélectionnez le bouton Ajouter à côté de Transformations de paramètre d'interrogation pour mettre à jour les paramètres d'interrogation inclus dans une demande à la passerelle d'API pour la route courante.
Pour limiter les paramètres d'interrogation inclus dans une demande, spécifiez les données suivantes :
- Action : Filtrer.
- Type : Bloquer pour supprimer de la demande les paramètres d'interrogation que vous listez explicitement ou Autoriser pour autoriser uniquement dans la demande les paramètres d'interrogation que vous listez explicitement (tous les autres paramètres d'interrogation sont supprimés de la demande).
- Noms de paramètres d'interrogation : Liste des paramètres d'interrogation à supprimer ou à autoriser pour la demande (selon le paramètre Type). Les noms que vous spécifiez sont sensibles à la casse et ne doivent pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple User-Agent.
Pour modifier le nom d'un paramètre d'interrogation inclus dans une demande (tout en conservant sa valeur initiale), spécifiez les données suivantes :
- Action : Renommer.
- De : Nom initial du paramètre d'interrogation que vous renommez. Le nom que vous spécifiez est sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route. Par exemple X-Username.
- À : Nouveau nom du paramètre d'interrogation que vous renommez. Le nom que vous spécifiez est sensible à la casse (la capitalisation est respectée) et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-User-ID.
Pour ajouter un nouveau paramètre d'interrogation à une demande (ou pour modifier ou conserver les valeurs d'un paramètre d'interrogation existant déjà inclus dans une demande), spécifiez les données suivantes :
- Action : Définir.
- Comportement : Si le paramètre d'interrogation existe déjà, spécifiez ce qu'il faut faire avec la valeur existante du paramètre d'interrogation :
  - Remplacer, pour remplacer la valeur existante du paramètre d'interrogation par la valeur que vous spécifiez.
  - Ajouter, pour ajouter la valeur que vous spécifiez à la valeur existante du paramètre d'interrogation.
  - Ignorer, pour conserver la valeur existante du paramètre d'interrogation.
- Nom de paramètre d'interrogation : Nom du paramètre d'interrogation à ajouter à la demande (ou pour en modifier la valeur). Le nom que vous spécifiez est sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-Api-Key.
- Valeurs : Valeur du nouveau paramètre d'interrogation (ou valeur à remplacer ou à ajouter à la valeur d'un paramètre d'interrogation existant, selon le paramètre Comportement). La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte entourées des délimiteurs ${...}. Par exemple "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}". Vous pouvez spécifier plusieurs valeurs.
Sélectionnez Enregistrer les modifications, puis Suivant pour vérifier les détails que vous avez entrés pour chaque route.
Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des politiques de demande de transformation de paramètre d'interrogation

Pour ajouter des politiques de demande de transformation de paramètre d'interrogation à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter des politiques de demande de transformation de paramètre d'interrogation ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Insérez une section requestPolicies après la section backend pour la route à laquelle vous voulez appliquer la politique de demande de transformation de paramètre d'interrogation. Par exemple :

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

Ajoutez une section queryParameterTransformations à la section requestPolicies.

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

Pour limiter les paramètres d'interrogation inclus dans une demande, spécifiez une politique de demande de transformation de paramètres d'interrogationfilterQueryParameters :
```
{
  "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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "type": "<BLOCK|ALLOW>" indique ce qu'il faut faire avec les paramètres d'interrogation spécifiés par "items":[{"name":"<query-parameter-name>"}] :
  - Utilisez BLOCK pour supprimer de la demande les paramètres d'interrogation que vous listez explicitement.
  - Utilisez ALLOW pour autoriser uniquement dans la demande les paramètres d'interrogation que vous listez explicitement (tous les autres paramètres d'interrogation sont supprimés de la demande).
- "name": "<query-parameter-name> est un paramètre d'interrogation à supprimer ou à autoriser pour la demande (selon le paramètre "type":" <BLOCK|ALLOW>"). Le nom que vous spécifiez est sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple User-Agent.
Vous pouvez supprimer et autoriser jusqu'à 50 paramètres d'interrogation dans une politique de demande de transformation de paramètre d'interrogation filterQueryParameters.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API supprime le paramètre d'interrogation User-Agent de toutes les demandes entrantes.
Pour modifier le nom d'un paramètre d'interrogation inclus dans une demande (tout en conservant sa valeur initiale), spécifiez une politique de demande de transformation de paramètre d'interrogation 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "from": "<original-name>" est le nom initial du paramètre d'interrogation que vous renommez. Le nom que vous spécifiez est sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route. Par exemple X-Username.
- "to": "<new-name>" est le nouveau nom du paramètre d'interrogation que vous renommez. Le nom que vous spécifiez est sensible à la casse (la capitalisation est respectée) et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-User-ID.
Vous pouvez renommer jusqu'à 20 paramètres d'interrogation dans une politique de demande de transformation de paramètre d'interrogation renameQueryParameters.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API renomme tous les paramètres d'interrogation X-Username à X-User-ID, tout en conservant la valeur initiale du paramètre d'interrogation.
Pour ajouter un nouveau paramètre d'interrogation à une demande (ou pour modifier ou conserver les valeurs d'un paramètre d'interrogation existant déjà inclus dans une demande), spécifiez une politique de demande de transformation de paramètre d'interrogation 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "name": "<query-parameter-name>" est le nom du paramètre d'interrogation à ajouter à la demande (ou pour en modifier la valeur). Le nom que vous spécifiez est sensible à la casse et ne doit pas être inclus dans d'autres politiques de demande de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-Api-Key.
- "values": ["<query-parameter-value>"] est la valeur du nouveau paramètre d'interrogation (ou la valeur à remplacer ou à ajouter à la valeur d'un paramètre d'interrogation existant, selon le paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte entourées des délimiteurs ${...}. Par exemple "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".
  Vous pouvez spécifier jusqu'à 10 valeurs. Si vous spécifiez plusieurs valeurs, la passerelle d'API ajoute un paramètre d'interrogation pour chaque valeur.
- "ifExiste": "<OVERWRITE|APPEND|SKIP>" indique ce qu'il faut faire de la valeur existante du paramètre d'interrogation si le paramètre d'interrogation spécifié par <query-parameter-name> existe déjà :
  - Utilisez OVERWRITE pour remplacer la valeur existante du paramètre d'interrogation par la valeur que vous spécifiez.
  - Utilisez APPEND pour ajouter la valeur que vous spécifiez à la valeur existante du paramètre d'interrogation.
  - Utilisez SKIP pour conserver la valeur existante du paramètre d'interrogation.
  Si elle n'est pas spécifiée, la valeur par défaut est OVERWRITE.
Vous pouvez ajouter (ou modifier) jusqu'à 20 paramètres d'interrogation dans une politique de demande de transformation de paramètre d'interrogation setQueryParameters.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API ajoute le paramètre d'interrogation X-Api-Key:zyx987wvu654tsu321 à toutes les demandes entrantes. Si le paramètre d'interrogation X-Api-Key d'une demande entrante est déjà réglé à une valeur différente, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
Utilisez comme suit la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API :
- En spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Ajout de politiques de réponse de transformation d'en-tête

Vous pouvez ajouter des politiques de réponse de transformation d'en-tête aux spécifications de déploiement d'API à l'aide de la console ou en modifiant un fichier JSON.

Notez que vous ne pouvez pas utiliser de politiques de transformation d'en-tête pour transformer certains en-têtes de réponse protégés. Voir En-têtes de demande protégée et en-têtes de réponse.

Utilisation de la console pour ajouter des politiques de réponse de transformation d'en-tête

Pour ajouter des politiques de réponse de transformation d'en-tête à une spécification de déploiement d'API à l'aide de la console :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
Sélectionnez Suivant et spécifiez les options d'authentification dans la page Authentification.

Pour plus d'informations sur les options d'authentification, voir Ajout de l'authentification et de l'autorisation aux déploiements d'API.
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la page Routes, sélectionnez la route pour laquelle vous voulez spécifier des politiques de réponse de transformation d'en-tête.
Sélectionnez Afficher les politiques de réponse de routage.
Sélectionnez le bouton Ajouter à côté de Transformations d'en-tête pour mettre à jour les en-têtes inclus dans une réponse à partir de la passerelle d'API pour la route courante.
Pour limiter les en-têtes inclus dans une réponse, spécifiez les données suivantes :
- Action : Filtrer.
- Type : Bloquer pour supprimer de la réponse les en-têtes que vous listez explicitement ou Autoriser pour autoriser uniquement dans la réponse les en-têtes que vous listez explicitement (tous les autres en-têtes sont supprimés de la réponse).
- Noms d'en-tête : Liste des en-têtes à supprimer ou à autoriser pour la réponse (selon le paramètre Type). Les noms que vous spécifiez ne sont pas sensibles à la casse et ne doivent pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple User-Agent.
Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), spécifiez les données suivantes :
- Action : Renommer.
- De : Nom initial de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route. Par exemple X-Username.
- À : Nouveau nom de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-User-ID.
Pour ajouter un nouvel en-tête à une réponse (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une réponse), spécifiez les données suivantes :
- Action : Définir.
- Comportement : Si l'en-tête existe déjà, spécifiez ce qu'il faut faire avec la valeur existante de l'en-tête :
  - Remplacer, pour remplacer la valeur existante de l'en-tête par la valeur que vous spécifiez.
  - Ajouter, pour ajouter la valeur que vous spécifiez à la valeur existante de l'en-tête.
  - Ignorer, pour conserver la valeur existante de l'en-tête.
- Nom : Nom de l'en-tête à ajouter à la réponse (ou pour en modifier la valeur). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-Api-Key.
- Valeurs : Valeur du nouvel en-tête (ou valeur à remplacer ou à ajouter à la valeur d'un en-tête existant, selon le paramètre Comportement). La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte entourées des délimiteurs ${...}. Par exemple "value": "zyx987wvu654tsu321". Vous pouvez spécifier plusieurs valeurs.
Sélectionnez Enregistrer les modifications, puis Suivant pour vérifier les détails que vous avez entrés pour chaque route.
Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des politiques de réponse de transformation d'en-tête

Pour ajouter des politiques de réponse de transformation d'en-tête à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter des politiques de réponse de transformation d'en-tête ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Insérez une section responsePolicies après la section backend pour la route à laquelle vous voulez appliquer la politique de réponse de transformation d'en-tête. Par exemple :

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

Ajoutez une section headerTransformations à la section responsePolicies.

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

Pour limiter les en-têtes inclus dans une réponse, spécifiez une politique de réponse de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "type": "<BLOCK|ALLOW>" indique ce qu'il faut faire avec les en-têtes spécifiés par "items":[{"name":"<header-name>"}] :
  - Utilisez BLOCK pour supprimer de la réponse les en-têtes que vous listez explicitement.
  - Utilisez ALLOW pour autoriser uniquement dans la réponse les en-têtes que vous listez explicitement (tous les autres en-têtes sont supprimés de la réponse).
- "name": "<header-name> est un en-tête à supprimer ou à autoriser pour la réponse (selon le paramètre "type":" <BLOCK|ALLOW>"). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple User-Agent.
Vous pouvez supprimer et autoriser jusqu'à 20 en-têtes dans une politique de réponse de transformation d'en-tête filterHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API supprime l'en-tête User-Agent de toutes les réponses sortantes.
Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), spécifiez une politique de réponse de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "from": "<original-name>" est le nom initial de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route. Par exemple X-Username.
- "to": "<new-name>" est le nouveau nom de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-User-ID.
Vous pouvez renommer jusqu'à 20 en-têtes dans une politique de réponse de transformation d'en-tête renameHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API renomme tous les en-têtes X-Username à X-User-ID, tout en conservant la valeur initiale de l'en-tête.
Pour ajouter un nouvel en-tête à une réponse (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une réponse), spécifiez une politique de réponse de transformation d'en-tête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}
```
où :
- "name":"<header-name> est le nom de l'en-tête à ajouter à la réponse (ou pour en modifier la valeur). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-Api-Key.
- "valeurs": ["<header-value>"] est la valeur du nouvel en-tête (ou la valeur à remplacer ou à ajouter à la valeur d'un en-tête existant, selon le paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte entourées des délimiteurs ${...}. Par exemple "values": "zyx987wvu654tsu321".
  Vous pouvez spécifier jusqu'à 10 valeurs. Si vous spécifiez plusieurs valeurs, la passerelle d'API ajoute un en-tête pour chaque valeur.
- "ifExiste": "<OVERWRITE|APPEND|SKIP>" indique ce qu'il faut faire avec la valeur existante de l'en-tête si l'en-tête spécifié par <header-name> existe déjà :
  - Utilisez OVERWRITE pour remplacer la valeur existante de l'en-tête par la valeur que vous spécifiez.
  - Utilisez APPEND pour ajouter la valeur que vous spécifiez à la valeur existante de l'en-tête.
  - Utilisez SKIP pour conserver la valeur existante de l'en-tête.
  Si elle n'est pas spécifiée, la valeur par défaut est OVERWRITE.
Vous pouvez ajouter (ou modifier) jusqu'à 20 en-têtes dans une politique de réponse de transformation d'en-tête setHeaders.

Par exemple :
```
{
  "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"
              }
            ]
          }
        }
      }
    }
  ]
}
```
Dans cet exemple, la passerelle d'API ajoute l'en-tête X-Api-Key:zyx987wvu654tsu321 à toutes les réponses sortantes. Si l'en-tête X-Api-Key d'une réponse sortante est déjà réglé à une valeur différente, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
Utilisez comme suit la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API :
- En spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Exemples

Les exemples de cette section supposent la définition de déploiement d'API et la spécification de déploiement d'API de base suivantes dans un fichier JSON :

{
  "displayName": "Marketing Deployment",
  "gatewayId": "ocid1.apigateway.oc1..aaaaaaaab______hga",
  "compartmentId": "ocid1.compartment.oc1..aaaaaaaa7______ysq",
  "pathPrefix": "/marketing",
  "specification": {
    "routes": [
      {
        "path": "/weather",
        "methods": ["GET"],
        "backend": {
          "type": "HTTP_BACKEND",
          "url": "https://api.weather.gov"
        },
        "requestPolicies": {}
      }
    ]
  },
  "freeformTags": {},
  "definedTags": {}
}

Notez que ces exemples s'appliquent également lorsque vous définissez une spécification de déploiement d'API à l'aide des boîtes de dialogue de la console.

Exemple 1: Transformation des paramètres d'en-tête en paramètres d'interrogation

Dans cet exemple, supposons qu'un élément dorsal HTTP existant traite uniquement les demandes contenant des paramètres d'interrogation et non des paramètres d'en-tête. Cependant, vous voulez que l'élément dorsal HTTP traite les demandes qui incluent des paramètres d'en-tête. Pour ce faire, vous créez une spécification de déploiement d'API qui inclut une politique de demande de transformation de paramètre d'interrogation pour transmettre la valeur obtenue à partir d'un en-tête de demande à l'élément dorsal HTTP en tant que paramètre d'interrogation.

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

Dans cet exemple, une demande comme curl -H "region: west" https://<gateway-hostname>/marketing/weather est résolue en https://api.weather.gov?region=west.

Exemple 2: Transformation d'un en-tête en un en-tête différent

Dans cet exemple, supposons qu'un élément dorsal HTTP existant traite uniquement les demandes contenant un en-tête particulier. Cependant, vous voulez que l'élément dorsal HTTP traite les demandes qui incluent un en-tête différent. Pour ce faire, vous créez une spécification de déploiement d'API qui inclut une politique de demande de transformation d'en-tête pour prendre la valeur obtenue à partir d'un en-tête de demande et la transmettre à l'élément dorsal HTTP en tant qu'en-tête de demande différent.

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

Dans cet exemple, une demande comme curl -H "locale: ouest" https://<gateway-hostname>/marketing/weather est résolue en la demande curl -H "region: ouest" https://api.weather.gov.

Exemple 3: Ajout d'un paramètre d'authentification obtenu à partir d'un jeton Web JSON (JWT) comme en-tête de demande

Dans cet exemple, supposons qu'un élément dorsal HTTP existant nécessite que la valeur de la revendication sub d'un jeton Web JSON (JWT) validé soit incluse dans une demande en tant qu'en-tête portant le nom JWT_SUBJECT. Le service de passerelle d'API a enregistré la valeur de la revendication sub incluse dans le jeton Web JSON (JWT) en tant que paramètre d'authentification dans la table request.auth.

Pour inclure la valeur sub dans un en-tête nommé JWT_SUBJECT, vous créez une spécification de déploiement d'API qui inclut une politique de demande de transformation d'en-tête. La politique de demande obtient la valeur sub à partir de la table request.auth et la transmet à l'élément dorsal HTTP en tant que valeur de l'en-tête JWT_SUBJECT.

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

Dans cet exemple, lorsqu'une demande est validée, l'en-tête JWT_SUBJECT est ajouté à la demande transmise à l'élément dorsal HTTP.

Exemple 4: Ajout d'une clé obtenue à partir d'une fonction d'autorisation comme paramètre d'interrogation

Dans cet exemple, supposons qu'un élément dorsal HTTP existant nécessite que les demandes incluent un paramètre d'interrogation nommé access_key à des fins d'authentification. Vous voulez que le paramètre d'interrogation access_key ait la valeur d'une clé nommée apiKey, retournée par une fonction d'autorisation qui a validé la demande. Le service de passerelle d'API a enregistré la valeur apiKey en tant que paramètre d'authentification dans la table request.auth.

Pour inclure le paramètre d'interrogation access_key dans la demande, vous créez une spécification de déploiement d'API qui inclut une politique de demande de transformation de paramètre d'interrogation. La politique de demande obtient la valeur apiKey à partir de la table request.auth et la transmet à l'élément dorsal HTTP en tant que valeur du paramètre d'interrogation access_key.

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

Dans cet exemple, le paramètre d'interrogation access_key est ajouté à la demande transmise à l'élément dorsal HTTP, avec la valeur apiKey de la table request.auth. Une demande comme https://<gateway-hostname>/marketing/weather est résolue en une demande comme https://api.weather.gov?access_key=fw5n9abi0ep

Exemple 5: Ajout d'une valeur par défaut pour un paramètre d'interrogation facultatif

Dans cet exemple, supposons qu'un élément dorsal HTTP existant nécessite que les demandes incluent un paramètre d'interrogation nommé country. Cependant, le paramètre d'interrogation country est facultatif et n'est pas inclus dans certains clients d'API envoyant des demandes. Si une demande inclut déjà un paramètre d'interrogation country et une valeur, vous voulez que les deux soient transmis tels quels à l'élément dorsal HTTP. Toutefois, si une demande n'inclut pas déjà de paramètre d'interrogation country, vous voulez que le paramètre d'interrogation country et une valeur par défaut soient ajoutés à la demande.

Pour vous assurer que chaque demande comprend un paramètre d'interrogation country, vous créez une spécification de déploiement d'API incluant une politique de demande de transformation de paramètre d'interrogation. La politique de demande ajoute le paramètre d'interrogation country et une valeur par défaut à toutes les demandes qui n'incluent pas déjà le paramètre d'interrogation country.

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

Dans cet exemple, une demande comme https://<gateway-hostname>/marketing/weather est résolue en https://api.weather.gov?country=usa. Une demande comme https://<gateway-hostname>/marketing/weather?country=canada est résolue en https://api.weather.gov?country=canada.

En-têtes de demande et de réponse protégés

Vous ne pouvez pas utiliser des politiques de transformation d'en-tête pour transformer certains en-têtes de demande et de réponse protégés, comme suit :


En-tête	Protégé en tant qu'en-tête de demande	Protégé en tant qu'en-tête de réponse
access-control-allow-credentials	ne s'applique pas	Oui
access-control-allow-en-têtes	ne s'applique pas	Oui
access-control-allow-méthodes	ne s'applique pas	Oui
access-control-allow-origin	ne s'applique pas	Oui
en-têtes access-control-expose-	ne s'applique pas	Oui
access-control-max-age	ne s'applique pas	Oui
boucle cdn	Oui	ne s'applique pas
connexion	Oui	Oui
longueur du contenu	Oui	Oui
cookie	Oui	ne s'applique pas
sauf	Oui	Oui
keep-alive	Oui	Oui
opc-request-id	Oui	Oui
origine	Oui	ne s'applique pas
authentification par mandataire	ne s'applique pas	Oui
Autorisation par mandataire	Oui	ne s'applique pas
broches-clés publiques	ne s'applique pas	Oui
réessayer après	ne s'applique pas	Oui
sécurité de transport stricte	ne s'applique pas	Oui
t	Oui	Oui
remorques	ne s'applique pas	Oui
transfert-encodage	Oui	Oui
améliorer	Oui	Oui
x-content-type-options	ne s'applique pas	Oui
x-forwarded-pour	Oui	ne s'applique pas
x-frame-options	ne s'applique pas	Oui
x-real-ip	Oui	ne s'applique pas
protection x-xss	ne s'applique pas	Oui

Documentation sur Oracle Cloud Infrastructure