Serverless: Les événements APIG forcent désormais les modèles json et form-urlencoded

Créé le 1 sept. 2016  ·  3Commentaires  ·  Source: serverless/serverless

Ceci est une proposition de fonctionnalité

La description

Lors de la définition des événements http APIG, le code force désormais la création de mappages à la fois pour application/json ainsi que pour application/x-www-form-urlencoded . Bien que vous puissiez remplacer le modèle, il n'y a aucun moyen d' exclure ces mappages (c'est-à-dire que je souhaite uniquement autoriser les requêtes json sur un point de terminaison)

Ce changement a été récemment introduit via ce commit dans lib/plugins/aws/deploy/compile/events/apiGateway/lib/methods.js :

const integrationRequestTemplates = {
  'application/json': DEFAULT_JSON_REQUEST_TEMPLATE,
  'application/x-www-form-urlencoded': DEFAULT_FORM_URL_ENCODED_REQUEST_TEMPLATE,
};

Bien que je pense qu'il est incroyablement utile d'avoir ces 2 options (et modèles prédéfinis), je pense qu'il serait préférable de permettre à l'utilisateur d'inclure éventuellement uniquement les modèles qu'il souhaite.

Quelque chose comme ce qui suit peut avoir du sens :

functions:
  create:
    handler: posts.create
    events:
      - http:
          method: get
          path: whatever
          request:
            template:
              text/xhtml: { "stage" : "$context.stage" }   # add additional template
              application/json: { "httpMethod" : "$context.httpMethod" }  # add mapping and override default template
              application/x-www-form-urlencoded: true    # add mapping and use default template 

Avec le problème ouvert actuel (# 1168) autour du comportement de transmission APIG et un PR en attente (# 1992) pour le résoudre, cela devient plus important pour pouvoir restreindre complètement les méthodes aux types de contenu souhaités.

Commentaire le plus utile

J'aime vraiment l'idée de la fonctionnalité pour pouvoir vraiment verrouiller les modèles par défaut, mais à mon humble avis, cela devrait se produire pour l'ensemble du service.

Mon hypothèse est que si vous souhaitez verrouiller complètement les modèles par défaut, vous souhaiterez le faire dans toutes les méthodes de votre service. Donc je pense que je préférerais quelque chose comme

provider:
  apigateway:
    default-request-templates: false

Sinon, vous auriez à dupliquer la configuration comme un fou (ce qui est déjà nécessaire, par exemple lorsque vous souhaitez définir des modèles séparés pour plusieurs fonctions, mais à mon humble avis, ce n'est pas un problème car vous n'en avez besoin que pour les événements qui ont des données de demande.

Mais je ne suis pas encore sûr :D. @serverless/vip des réflexions à ce sujet, en particulier @HyperBrain ?

Tous les 3 commentaires

J'aime vraiment l'idée de la fonctionnalité pour pouvoir vraiment verrouiller les modèles par défaut, mais à mon humble avis, cela devrait se produire pour l'ensemble du service.

Mon hypothèse est que si vous souhaitez verrouiller complètement les modèles par défaut, vous souhaiterez le faire dans toutes les méthodes de votre service. Donc je pense que je préférerais quelque chose comme

provider:
  apigateway:
    default-request-templates: false

Sinon, vous auriez à dupliquer la configuration comme un fou (ce qui est déjà nécessaire, par exemple lorsque vous souhaitez définir des modèles séparés pour plusieurs fonctions, mais à mon humble avis, ce n'est pas un problème car vous n'en avez besoin que pour les événements qui ont des données de demande.

Mais je ne suis pas encore sûr :D. @serverless/vip des réflexions à ce sujet, en particulier @HyperBrain ?

Cela devrait être possible avec ceci maintenant : https://serverless.com/framework/docs/providers/aws/events/apigateway#custom -request-templates

@flomotlik Comment les modèles personnalisés répondent-ils au cas d'utilisation de l'OP application/x-www-form-urlencoded par défaut, sans avoir besoin de créer un modèle personnalisé pour application/json ?

Cette page vous a été utile?
0 / 5 - 0 notes