Documentation Oracle Cloud Infrastructure

Transformation des demandes entrantes et des réponses sortantes

Découvrez comment modifier les demandes entrantes et les réponses sortantes à destination et en provenance des services back-end à l'aide d'API Gateway.

Dans certaines situations, vous pouvez avoir besoin qu'une passerelle d'API modifie les demandes entrantes avant de les envoyer aux services back-end. De même, vous pouvez utiliser la passerelle d'API pour modifier les réponses renvoyées par les services back-end. Par exemple :

  • Les services back-end peuvent nécessiter que les demandes contiennent un ensemble spécifique d'en-têtes HTTP (par exemple, Accept-Language et Accept-Encoding). Afin de masquer ces détails d'implémentation pour les consommateurs d'API et les clients d'API, vous pouvez ajouter les en-têtes requis à l'aide de votre passerelle d'API.
  • Les serveurs Web incluent souvent des informations de version complètes dans les en-têtes de réponse. Pour des raisons de sécurité, vous pouvez choisir de dissimuler la pile de technologie sous-jacente pour les consommateurs d'API et les clients d'API. Vous pouvez utiliser votre passerelle d'API pour enlever les en-têtes de serveur des réponses.
  • Les services back-end peuvent inclure des informations sensibles dans une réponse. Vous pouvez utiliser votre passerelle d'API pour enlever ces informations.

Une passerelle d'API vous permet d'effectuer les opérations suivantes :

  • Ajouter, enlever et modifier des en-têtes dans les demandes et les réponses.
  • Ajouter, enlever et modifier des paramètres de requête dans les demandes.
  • Réécrire les URL de demande au format public dans un format interne, notamment pour prendre en charge les applications héritées et les migrations.

Vous pouvez utiliser les stratégies de demande et de réponse pour transformer les en-têtes et les paramètres de requête des demandes entrantes, ainsi que les en-têtes des réponses sortantes (reportez-vous à Ajout de stratégies de demande et de réponse aux spécifications de déploiement d'API).

Vous pouvez inclure des variables de contexte dans les stratégies de demande et de réponse de transformation d'en-tête et de paramètre de requête. L'ajout de variables de contexte permet de modifier les en-têtes et les paramètres de requête avec les valeurs d'autres en-têtes, paramètres de requête, paramètres de chemin et paramètres d'authentification. Les valeurs des variables de contexte sont extraites à partir de la demande ou de la réponse d'origine, et ne sont pas mises à jour ultérieurement lorsque la passerelle d'API utilise une stratégie de transformation pour évaluer une demande ou une réponse. Pour plus d'informations sur les variables de contexte, reportez-vous à Ajout de variables de contexte aux stratégies et aux définitions de back-end HTTP.

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

Notez que vous ne pouvez pas utiliser de stratégies de transformation d'en-tête pour transformer certains en-têtes de demande et de réponse protégés. Reportez-vous à la section Protected Request Headers and Response Headers.

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

  • utilisant la console,
  • modifiant un fichier JSON.

Ajout de stratégies de demande de transformation d'en-tête

Vous pouvez ajouter des stratégies 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. Reportez-vous à la section Protected Request Headers and Response Headers.

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

Pour ajouter des stratégies de demande de transformation d'en-tête à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :

  1. Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

    Pour plus d'informations, reportez-vous à 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.

  2. Sélectionnez Suivant et indiquez les options d'authentification sur la page Authentification.

    Pour plus d'informations sur les options d'authentification, reportez-vous à Ajout de l'authentification et de l'autorisation aux déploiements d'API.

  3. Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.

  4. Sur la page Routages, sélectionnez le routage pour lequel spécifier des stratégies de demande de transformation d'en-tête.
  5. Sélectionnez Afficher les stratégies de demande de routage.
  6. Sélectionnez le bouton Ajouter en regard de Transformations d'en-tête afin de mettre à jour les en-têtes inclus dans une demande adressée à la passerelle d'API pour le routage en cours.

  7. Pour limiter les en-têtes inclus dans une demande, renseignez les paramètres suivants :

    • Action : filtrer.
    • Type : sélectionnez Bloquer pour enlever les en-têtes explicitement indiqués de la demande ou Autoriser pour autoriser uniquement les en-têtes explicitement définis dans la demande (tous les autres en-têtes sont enlevés de la demande).
    • Noms d'en-tête : liste des en-têtes à enlever de la demande ou à autoriser dans la demande (en fonction du paramètre Type). Les noms que vous indiquez ne font pas la distinction entre les majuscules et les minuscules, et ne doivent être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, User-Agent.

  8. Pour modifier le nom d'un en-tête inclus dans une demande (tout en conservant sa valeur initiale), renseignez les paramètres suivants :

    • Action : renommer.
    • De : nom d'origine de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage. Par exemple, X-Username.
    • A : nouveau nom de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-User-ID.

  9. 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), renseignez les paramètres suivants :

    • Action : définir.

    • Comportement : si l'en-tête existe déjà, indiquez le traitement à appliquer à la valeur existante de l'en-tête :

      • Ecraser, pour remplacer la valeur existante de l'en-tête par la valeur que vous indiquez.
      • Ajouter à la fin, pour ajouter la valeur que vous indiquez à la fin de 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 dont vous voulez modifier la valeur). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-Api-Key.
    • Valeurs : valeur du nouvel en-tête (ou valeur destinée à remplacer la valeur d'un en-tête existant ou à y être ajoutée en fonction du paramètre Comportement). Vous pouvez indiquer plusieurs valeurs. La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte (à l'exception de request.body) placées entre les délimiteurs ${...}. Par exemple, "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}".
  10. Sélectionnez Enregistrer les modifications, puis Suivant afin de vérifier les détails saisis pour les routages.
  11. Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
  12. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

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

Pour ajouter des stratégies de demande de transformation d'en-tête à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

  1. A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle ajouter des stratégies de demande de transformation d'en-tête, ou créez une spécification de déploiement d'API (reportez-vous à 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 fonction simple sans serveur Hello World dans OCI Functions en tant que back-end unique :

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

  2. Insérez une section requestPolicies après la section backend du routage auquel la stratégie de demande de transformation d'en-tête doit être appliquée. Par exemple :

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

  3. 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":{}
      }
    }
  ]
}

  4. Pour limiter les en-têtes inclus dans une demande, indiquez une stratégie 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 le traitement à appliquer aux en-têtes indiqués par "items":[{"name":"<header-name>"}] :
      • Utilisez BLOCK pour enlever les en-têtes explicitement indiqués de la demande.
      • Utilisez ALLOW pour autoriser uniquement les en-têtes explicitement indiqués dans la demande (tous les autres en-têtes sont enlevés de la demande).
    • "name":"<header-name> est un en-tête à enlever de la demande ou à autoriser dans celle-ci (en fonction du paramètre "type": "<BLOCK|ALLOW>"). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, User-Agent.

    Vous pouvez enlever ou autoriser jusqu'à 50 en-têtes dans une stratégie 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 enlève l'en-tête User-Agent de toutes les demandes entrantes.

  5. Pour modifier le nom d'un en-tête inclus dans une demande (tout en conservant sa valeur initiale), spécifiez une stratégie 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 d'origine de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage. Par exemple, X-Username.
    • "to": "<new-name>" est le nouveau nom de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-User-ID.

    Vous pouvez renommer jusqu'à 20 en-têtes dans une stratégie 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 n'importe quel en-tête X-Username en X-User-ID, tout en conservant sa valeur d'origine.

  6. 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 stratégie 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 dont vous voulez modifier la valeur). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-Api-Key.
    • "values": ["<header-value>"] correspond à la valeur du nouvel en-tête (ou à la valeur destinée à remplacer la valeur d'un en-tête existant ou à y être ajoutée à la fin en fonction du paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte (à l'exception de request.body) placées entre les séparateurs ${...}. Par exemple, "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".

      Vous pouvez indiquer jusqu'à 10 valeurs. Si vous indiquez plusieurs valeurs, la passerelle d'API ajoute un en-tête pour chacune d'elles.

    • "ifExists": "<OVERWRITE|APPEND|SKIP>" indique le traitement à appliquer à la valeur existante de l'en-tête si l'en-tête indiqué par <header-name> existe déjà :

      • Utilisez OVERWRITE pour remplacer la valeur existante de l'en-tête par la valeur indiquée.
      • Utilisez APPEND pour ajouter la valeur indiquée à la fin de la valeur existante de l'en-tête.
      • Utilisez SKIP pour conserver la valeur existante de l'en-tête.

      Si aucune option n'est indiquée, l'option par défaut est OVERWRITE.

    Vous pouvez ajouter jusqu'à 20 en-têtes (ou en modifier les valeurs) dans une stratégie 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 un en-tête X-Api-Key est déjà défini sur une autre valeur dans une demande entrante, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.

  7. Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.

  8. Utilisez 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 Télécharger une API existante,
    • spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.

    Pour plus d'informations, reportez-vous à 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.

  9. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Ajout de stratégies de demande de transformation de paramètre de requête

Vous pouvez ajouter des stratégies de demande de transformation de paramètre de requête 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 stratégies de demande de transformation de paramètre de requête

Pour ajouter des stratégies de demande de transformation de paramètre de requête à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :

  1. Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

    Pour plus d'informations, reportez-vous à 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.

  2. Sélectionnez Suivant et indiquez les options d'authentification sur la page Authentification.

    Pour plus d'informations sur les options d'authentification, reportez-vous à Ajout de l'authentification et de l'autorisation aux déploiements d'API.

  3. Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.

  4. Sur la page Routages, sélectionnez le routage pour lequel spécifier des stratégies de demande de transformation de paramètre de requête.
  5. Sélectionnez Afficher les stratégies de demande de routage.
  6. Sélectionnez le bouton Ajouter en regard de Transformations de paramètre de requête afin de mettre à jour les paramètres de requête inclus dans une demande adressée à la passerelle d'API pour le routage en cours.

  7. Pour limiter les paramètres de requête inclus dans une demande, renseignez les paramètres suivants :

    • Action : filtrer.
    • Type : sélectionnez Bloquer pour enlever les paramètres de requête explicitement indiqués de la demande ou Autoriser pour autoriser uniquement les paramètres de requête explicitement définis dans la demande (tous les autres paramètres de requête sont enlevés de la demande).
    • Noms de paramètre de requête : liste des paramètres de requête à enlever de la demande ou à autoriser dans la demande (en fonction du paramètre Type). Les noms que vous indiquez font la distinction entre les majuscules et les minuscules et ne doivent être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, User-Agent.

  8. Pour modifier le nom d'un paramètre de requête inclus dans une demande (tout en conservant sa valeur initiale), renseignez les paramètres suivants :

    • Action : renommer.
    • De : nom d'origine du paramètre de requête que vous renommez. Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage. Par exemple, X-Username.
    • A : nouveau nom du paramètre de requête que vous renommez. Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-User-ID.

  9. Pour ajouter un nouveau paramètre de requête à une demande (ou pour modifier ou conserver les valeurs d'un paramètre de requête existant déjà inclus dans une demande), renseignez les paramètres suivants :

    • Action : définir.

    • Comportement : si le paramètre de requête existe déjà, indiquez le traitement à appliquer à la valeur existante du paramètre de requête :

      • Ecraser, pour remplacer la valeur existante du paramètre de requête par la valeur que vous indiquez.
      • Ajouter à la fin, pour ajouter la valeur que vous indiquez à la fin de la valeur existante du paramètre de requête.
      • Ignorer, pour conserver la valeur existante du paramètre de requête.
    • Nom : nom du paramètre de requête à ajouter à la demande (ou dont vous voulez modifier la valeur). Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-Api-Key.
    • Valeurs : valeur du nouveau paramètre de requête (ou valeur destinée à remplacer la valeur d'un paramètre de requête existant ou à y être ajoutée à la fin en fonction du paramètre Comportement). La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte placées entre les délimiteurs ${...}. Par exemple, "value": "zyx987wvu654tsu321", "value": "${request.path[region]}", "value": "${request.headers[opc-request-id]}". Vous pouvez indiquer plusieurs valeurs.
  10. Sélectionnez Enregistrer les modifications, puis Suivant afin de vérifier les détails saisis pour les routages.
  11. Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
  12. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des stratégies de demande de transformation de paramètre de requête

Pour ajouter des stratégies de demande de transformation de paramètre de requête à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

  1. A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle vous voulez ajouter la stratégie de demande de transformation de paramètre de requête. Vous pouvez également créer une spécification de déploiement d'API (reportez-vous à 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 fonction simple sans serveur Hello World dans OCI Functions en tant que back-end unique :

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

  2. Insérez une section requestPolicies après la section backend du routage auquel la stratégie de demande de transformation de paramètre de requête doit être appliquée. Par exemple :

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

  3. 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":{}
      }
    }
  ]
}

  4. Pour limiter les paramètres de requête inclus dans une demande, indiquez une stratégie de demande de transformation de paramètre de requête 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>"
              }
            ]
          }
        }
      }
    }
  ]
}

    où :

    • "type": "<BLOCK|ALLOW>" indique le traitement à appliquer aux paramètres de requête indiqués par "items":[{"name":"<query-parameter-name>"}] :
      • Utilisez BLOCK pour enlever les paramètres de requête explicitement indiqués de la demande.
      • Utilisez ALLOW pour autoriser uniquement les paramètres de requête explicitement indiqués dans la demande (tous les autres paramètres de requête sont enlevés de la demande).
    • "name":"<query-parameter-name> est un paramètre de requête à enlever de la demande ou à autoriser dans celle-ci (en fonction du paramètre "type": "<BLOCK|ALLOW>"). Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, User-Agent.

    Vous pouvez enlever ou autoriser jusqu'à 50 paramètres de requête dans une stratégie de demande de transformation de paramètre de requête 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 enlève le paramètre de requête User-Agent de toutes les demandes entrantes.

  5. Pour modifier le nom d'un paramètre de requête inclus dans une demande (tout en conservant sa valeur initiale), spécifiez une stratégie de demande de transformation de paramètre de requête 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 d'origine du paramètre de requête que vous renommez. Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage. Par exemple, X-Username.
    • "to": "<new-name>" est le nouveau nom du paramètre de requête que vous renommez. Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-User-ID.

    Vous pouvez renommer jusqu'à 20 paramètres de requête dans une stratégie de demande de transformation de paramètre de requête 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 n'importe quel paramètre de requête X-Username en X-User-ID, tout en conservant sa valeur d'origine.

  6. Pour ajouter un nouveau paramètre de requête à une demande (ou pour modifier ou conserver les valeurs d'un paramètre de requête existant déjà inclus dans une demande), spécifiez une stratégie de demande de transformation de paramètre de requête 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 de requête à ajouter à la demande (ou dont vous voulez modifier la valeur). Le nom que vous indiquez fait la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de demande de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-Api-Key.
    • "values": ["<query-parameter-value>"] correspond à la valeur du nouveau paramètre de requête (ou à la valeur destinée à remplacer la valeur d'un paramètre de requête existant ou à y être ajoutée à la fin en fonction du paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte placées entre les délimiteurs ${...}. Par exemple, "values": "zyx987wvu654tsu321", "values": "${request.path[region]}", "values": "${request.headers[opc-request-id]}".

      Vous pouvez indiquer jusqu'à 10 valeurs. Si vous indiquez plusieurs valeurs, la passerelle d'API ajoute un paramètre de requête pour chacune d'elles.

    • "ifExists": "<OVERWRITE|APPEND|SKIP>" indique le traitement à appliquer à la valeur existante du paramètre de requête si le paramètre de requête indiqué par <query-parameter-name> existe déjà :

      • Utilisez OVERWRITE pour remplacer la valeur existante du paramètre de requête par la valeur indiquée.
      • Utilisez APPEND pour ajouter la valeur indiquée à la fin de la valeur existante du paramètre de requête.
      • Utilisez SKIP pour conserver la valeur existante du paramètre de requête.

      Si aucune option n'est indiquée, l'option par défaut est OVERWRITE.

    Vous pouvez ajouter jusqu'à 20 paramètres de requête (ou en modifier les valeurs) dans une stratégie de demande de transformation de paramètre de requête 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 de requête X-Api-Key:zyx987wvu654tsu321 à toutes les demandes entrantes. Si un paramètre de requête X-Api-Key est déjà défini sur une autre valeur dans une demande entrante, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.

  7. Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.

  8. Utilisez 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 Télécharger une API existante,
    • spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.

    Pour plus d'informations, reportez-vous à 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.

  9. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

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

Vous pouvez ajouter des stratégies 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 stratégies de transformation d'en-tête pour transformer certains en-têtes de réponse protégés. Reportez-vous à la section Protected Request Headers and Response Headers.

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

Pour ajouter des stratégies de réponse de transformation d'en-tête à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :

  1. Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

    Pour plus d'informations, reportez-vous à 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.

  2. Sélectionnez Suivant et indiquez les options d'authentification sur la page Authentification.

    Pour plus d'informations sur les options d'authentification, reportez-vous à Ajout de l'authentification et de l'autorisation aux déploiements d'API.

  3. Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.

  4. Sur la page Routages, sélectionnez le routage pour lequel spécifier des stratégies de réponse de transformation d'en-tête.
  5. Sélectionnez Afficher les stratégies de réponse de routage.
  6. Sélectionnez le bouton Ajouter en regard de Transformations d'en-tête afin de mettre à jour les en-têtes inclus dans une réponse provenant de la passerelle d'API pour le routage en cours.

  7. Pour limiter les en-têtes inclus dans une réponse, renseignez les paramètres suivants :

    • Action : filtrer.
    • Type : sélectionnez Bloquer pour enlever les en-têtes explicitement indiqués de la réponse ou Autoriser pour autoriser uniquement les en-têtes explicitement définis dans la réponse (tous les autres en-têtes sont enlevés de la réponse).
    • Noms d'en-tête : liste des en-têtes à enlever de la réponse ou à autoriser dans la réponse (en fonction du paramètre Type). Les noms que vous indiquez ne font pas la distinction entre les majuscules et les minuscules, et ne doivent être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, User-Agent.

  8. Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), renseignez les paramètres suivants :

    • Action : renommer.
    • De : nom d'origine de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage. Par exemple, X-Username.
    • A : nouveau nom de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-User-ID.

  9. 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), renseignez les paramètres suivants :

    • Action : définir.

    • Comportement : si l'en-tête existe déjà, indiquez le traitement à appliquer à la valeur existante de l'en-tête :

      • Ecraser, pour remplacer la valeur existante de l'en-tête par la valeur que vous indiquez.
      • Ajouter à la fin, pour ajouter la valeur que vous indiquez à la fin de 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 dont vous voulez modifier la valeur). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-Api-Key.
    • Valeurs : valeur du nouvel en-tête (ou valeur destinée à remplacer la valeur d'un en-tête existant ou à y être ajoutée en fonction du paramètre Comportement). La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte placées entre les délimiteurs ${...}. Par exemple, "value": "zyx987wvu654tsu321". Vous pouvez indiquer plusieurs valeurs.
  10. Sélectionnez Enregistrer les modifications, puis Suivant afin de vérifier les détails saisis pour les routages.
  11. Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
  12. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

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

Pour ajouter des stratégies de réponse de transformation d'en-tête à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

  1. A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle ajouter des stratégies de réponse de transformation d'en-tête, ou créez une spécification de déploiement d'API (reportez-vous à 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 fonction simple sans serveur Hello World dans OCI Functions en tant que back-end unique :

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

  2. Insérez une section responsePolicies après la section backend du routage auquel la stratégie de réponse de transformation d'en-tête doit être appliquée. Par exemple :

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

  3. 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":{}
      }
    }
  ]
}

  4. Pour limiter les en-têtes inclus dans une réponse, indiquez une stratégie 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 le traitement à appliquer aux en-têtes indiqués par "items":[{"name":"<header-name>"}] :
      • Utilisez BLOCK pour enlever les en-têtes explicitement indiqués de la réponse.
      • Utilisez ALLOW pour autoriser uniquement les en-têtes explicitement indiqués dans la réponse (tous les autres en-têtes sont enlevés de la réponse).
    • "name":"<header-name> est un en-tête à enlever de la réponse ou à autoriser dans celle-ci (en fonction du paramètre "type": "<BLOCK|ALLOW>"). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, User-Agent.

    Vous pouvez enlever ou autoriser jusqu'à 20 en-têtes dans une stratégie 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 enlève l'en-tête User-Agent de toutes les réponses sortantes.

  5. Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), spécifiez une stratégie 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 d'origine de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage. Par exemple, X-Username.
    • "to": "<new-name>" est le nouveau nom de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-User-ID.

    Vous pouvez renommer jusqu'à 20 en-têtes dans une stratégie 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 n'importe quel en-tête X-Username en X-User-ID, tout en conservant sa valeur d'origine.

  6. 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 stratégie 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 dont vous voulez modifier la valeur). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-Api-Key.
    • "values": ["<header-value>"] correspond à la valeur du nouvel en-tête (ou à la valeur destinée à remplacer la valeur d'un en-tête existant ou à y être ajoutée à la fin en fonction du paramètre "ifExists": "<OVERWRITE|APPEND|SKIP>"). La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte placées entre les délimiteurs ${...}. Par exemple, "values": "zyx987wvu654tsu321".

      Vous pouvez indiquer jusqu'à 10 valeurs. Si vous indiquez plusieurs valeurs, la passerelle d'API ajoute un en-tête pour chacune d'elles.

    • "ifExists": "<OVERWRITE|APPEND|SKIP>" indique le traitement à appliquer à la valeur existante de l'en-tête si l'en-tête indiqué par <header-name> existe déjà :

      • Utilisez OVERWRITE pour remplacer la valeur existante de l'en-tête par la valeur indiquée.
      • Utilisez APPEND pour ajouter la valeur indiquée à la fin de la valeur existante de l'en-tête.
      • Utilisez SKIP pour conserver la valeur existante de l'en-tête.

      Si aucune option n'est indiquée, l'option par défaut est OVERWRITE.

    Vous pouvez ajouter jusqu'à 20 en-têtes (ou en modifier les valeurs) dans une stratégie 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 un en-tête X-Api-Key est déjà défini sur une autre valeur dans une réponse sortante, la passerelle d'API remplace la valeur existante par zyx987wvu654tsu321.

  7. Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.

  8. Utilisez 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 Télécharger une API existante,
    • spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.

    Pour plus d'informations, reportez-vous à 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.

  9. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Exemples

Les exemples de cette section utilisent 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": {}
}

Ces exemples s'appliquent 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 de requête

Dans cet exemple, supposons qu'un back-end HTTP existant traite uniquement les demandes contenant des paramètres de requête, et non des paramètres d'en-tête. Toutefois, vous voulez que ce back-end HTTP gère les demandes qui comportent des paramètres d'en-tête. Pour ce faire, vous créez une spécification de déploiement d'API qui inclut une stratégie de demande de transformation de paramètre de requête afin de transmettre la valeur obtenue à partir d'un en-tête de demande vers le back-end HTTP en tant que paramètre de requête.

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

Dans cet exemple, une demande 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 autre en-tête

Dans cet exemple, supposons qu'un back-end HTTP existant ne traite que les demandes contenant un en-tête particulier. Toutefois, vous voulez que ce back-end HTTP gère les demandes qui comportent un autre en-tête. Pour ce faire, vous créez une spécification de déploiement d'API qui inclut une stratégie de demande de transformation d'en-tête afin de transmettre la valeur obtenue à partir d'un en-tête de demande vers le back-end HTTP en tant qu'autre en-tête de demande.

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

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

Exemple 3 : ajout d'un paramètre d'authentification obtenu à partir d'un jeton JWT en tant qu'en-tête de demande

Dans cet exemple, supposons qu'un back-end HTTP existant exige que la valeur de la demande sub dans un jeton Web JSON (JWT) validé soit incluse dans une demande en tant qu'en-tête portant le nom JWT_SUBJECT. Le service API Gateway a enregistré la valeur de la demande sub incluse dans le jeton 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 stratégie de demande de transformation d'en-tête. La stratégie de demande obtient la valeur sub de la table request.auth et la transmet au back-end 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 au back-end HTTP.

Exemple 4 : ajout d'une clé obtenue à partir d'une fonction d'autorisation en tant que paramètre de requête

Dans cet exemple, supposons qu'un back-end HTTP existant exige que les demandes incluent un paramètre de requête nommé access_key à des fins d'authentification. Vous souhaitez que le paramètre de requête access_key porte la valeur d'une clé nommée apiKey qui a été renvoyée par une fonction d'autorisation ayant validé la demande. Le service API Gateway a enregistré la valeur apiKey en tant que paramètre d'authentification dans la table request.auth.

Pour inclure le paramètre de requête access_key dans la demande, créez une spécification de déploiement d'API qui inclut une stratégie de demande de transformation de paramètre de requête. La stratégie de demande obtient la valeur apiKey de la table request.auth et la transmet au back-end HTTP en tant que valeur du paramètre de requête access_key.

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

Dans cet exemple, le paramètre de requête access_key est ajouté à la demande transmise au back-end HTTP avec la valeur apiKey de la table request.auth. Une demande https://<gateway-hostname>/marketing/weather est alors résolue en demande https://api.weather.gov?access_key=fw5n9abi0ep.

Exemple 5 : ajout d'une valeur par défaut pour un paramètre de requête facultatif

Dans cet exemple, supposons qu'un back-end HTTP existant exige que les demandes incluent un paramètre de requête nommé country. Toutefois, le paramètre de requête country est facultatif et n'est pas inclus par certains clients d'API à l'origine des demandes. Si une demande inclut déjà un paramètre de requête country et une valeur, vous pouvez transmettre ces éléments tels quels au back-end HTTP. Toutefois, si une demande n'inclut pas déjà le paramètre de requête country, vous pouvez ajouter le paramètre de requête country avec une valeur par défaut à la demande.

Pour vous assurer que chaque demande comprend un paramètre de requête country, vous créez une spécification de déploiement d'API qui inclut une stratégie de demande de transformation de paramètre de requête. La stratégie de demande ajoute le paramètre de requête country avec une valeur par défaut aux demandes qui ne comportent pas déjà le paramètre de requête country.

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

Dans cet exemple, une demande https://<gateway-hostname>/marketing/weather est résolue en https://api.weather.gov?country=usa. Une demande 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 de stratégies 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 non applicable Oui
access-control-allow-headers non applicable Oui
méthodes-autorisation-accès non applicable Oui
access-control-allow-origin non applicable Oui
access-control-expose-headers non applicable Oui
accès-contrôle-max-age non applicable Oui
boucle CDN Oui non applicable
connexion Oui Oui
content-length Oui Oui
cookie Oui non applicable
sauf Oui Oui
keep-alive Oui Oui
OPC-demande-ID Oui Oui
origine Oui non applicable
Authentification par proxy non applicable Oui
autorisation de proxy Oui non applicable
Pins de clé publique non applicable Oui
nouvelle tentative après non applicable Oui
strict-transport-sécurité non applicable Oui
te Oui Oui
remorques non applicable Oui
codage de transfert Oui Oui
mettre à niveau Oui Oui
Options de type x-content non applicable Oui
x-forwarded-for Oui non applicable
Options x-frame non applicable Oui
x-real-ip Oui non applicable
protection x-xss non applicable Oui