amazon-web-services - test - aws api gateway json schema

Obtenga mensajes de error detallados de AWS API Gateway Validator

Question

Fondo

Tengo una puerta de enlace API creada utilizando las definiciones de Swagger 2.0 con extensiones de la puerta de enlace API .

Anulé las respuestas predeterminadas de la puerta de enlace de la API, por ejemplo:

x-amazon-apigateway-gateway-responses:
  BAD_REQUEST_BODY:
    statusCode: 400
    responseTemplates:
      application/json: |
        {
          "error": {
            "code": 400,
            "stage": "$context.stage",
            "request": "$context.requestId",
            "message": "$context.error.message"
          }
        }

El $context en la carga útil anterior proviene de las variables de la puerta de enlace API .

Un ejemplo de recurso / método en mi API se parece a esto (siempre integraciones LAMBDA_PROXY ):

paths:
  /test:
    post:
      parameters:
        - in: body
          name: Test
          required: true
          schema:
          $ref: "#/definitions/Test"
      responses:
        201:
          description: Created
        400:
          description: Bad Request
        401:
          description: Unauthorized
        403:
          description: Forbidden
      x-amazon-apigateway-integration:
      uri: >-
        arn:aws:apigateway:${region}:lambda:path/2015-03-31/functions/${lambda}/invocations
      type: aws_proxy
      httpMethod: POST
      credentials: "${credentials}"
      passthroughBehavior: never

Con la correspondiente definición de carga útil de solicitud:

definitions:
  Test:
    type: object
    title: Test
    required:
      - date
    properties:
      date:
        type: string
        pattern: "^20[0-9]{2}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
        description: Date in YYYY-MM-DD Format

Y las extensiones del validador de solicitudes :

x-amazon-apigateway-request-validator: body
x-amazon-apigateway-request-validators:
  body:
    validateRequestBody: true
    validateRequestParameters: false

Problema

Cuando llamo a este punto final con una date faltante o no válida, siempre obtengo la misma respuesta:

{
    "error": {
        "code": 400,
        "stage": "latest",
        "request": "6b7a64f5-e7f0-11e7-845b-f53ceb4cb049",
        "message": "Invalid request body"
    }
}

Sin embargo, cuando lo pruebo a través de la consola de la puerta de enlace API sin la propiedad de date :

Request body does not match model schema for content type application/json: [
  object has missing required properties (["date"])
]

Y con una date inválida:

Request body does not match model schema for content type application/json: [
  ECMA 262 regex "^20[0-9]{2}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$" does not match input string "2017/12/25"
]

Pregunta

¿Cómo puedo acceder al mensaje de error detallado para poder enriquecer mi respuesta de error con un mensaje más descriptivo que el Invalid request body ? Sospecho que esto debe ser posible, quizás utilizando el mapeo de x-amazon-apigateway-gateway-responses , pero hasta ahora no he podido hacerlo.

Answer 1

(Desarrollador en API Gateway)

Desafortunadamente, esto no es compatible en este momento. Estamos trabajando activamente para solucionar este problema, pero no puedo proporcionarle ninguna línea de tiempo específica para cuando esto pueda ser compatible.

Answer 2

Dado que un desarrollador de API Gateway ha respondido la pregunta, todavía quiero agregar algunos consejos para usted, tal vez sea útil y ¡esa puede ser una respuesta aceptada!

Para su pregunta, de hecho, necesita activar los registros de Cloudwatch para la puerta de enlace de la API, con eso, puede obtener más registros de los que tenía anteriormente.

Avísame si incluyó los detalles para Request Validator

Este documento de aws: ¿Cómo habilito los registros de Amazon CloudWatch para las API que creé en la puerta de enlace API de Amazon? Da los pasos sobre cómo habilitarlo.

Pero prefiero ir con este documento API Gateway y Lambda Logs , que le dan a las capturas de pantalla un seguimiento fácil.

En su puerta de enlace api, debería ver que esto está habilitado.

Acceda a la puerta de enlace API varias veces, vaya a través del grupo de registro que se denomina como:

API-Gateway-Execution-Logs_{rest-api-id}/{stage_name}

Que tiene más detalles que la información que tiene como Invalid request body y otros, como {"message": "Internal server error"} . Es una característica muy útil, que me ahorra mucho tiempo en la resolución de problemas del servidor y la puerta de enlace API.

Answer 3

En este caso, dentro de la sección Respuestas de Gateway, vaya a:

Bad Request Body [400]

Change the value of the body mapping template to: 

{"message":$context.error.validationErrorString}

Salida Ex:

{
"message": "[instance value (/"us/") not found in enum (possible values: [/"usd/",/"eur/",/"gbp/",/"jpy/",/"aud/",/"chf/",/"cad/",/"nzd/"])]"
}

Answer 4

Esta no es una respuesta a su pregunta, sino una solución alternativa que hemos utilizado en nuestras aplicaciones que cumple el mismo propósito (validación de solicitudes).

Nuestra API sin servidor comenzó con la definición de todos nuestros puntos finales en la puerta de enlace de la API (completa con la documentación de Swagger). Con el tiempo, hemos agregado muchos más puntos finales (alrededor de más de 60 puntos finales que consisten en puntos finales REST heredados, puntos finales REST públicos y puntos finales GraphQL privados).

La gestión de este número de puntos finales a través de la puerta de enlace API resultó ser muy tediosa, y el tiempo de implementación tomó mucho tiempo (estamos usando serverless ).

Finalmente, decidimos reducirlo a tres aplicaciones "monolith" sin servidor. Dos puntos finales REST y un punto final GraphQL.

Básicamente, manejamos el enrutamiento dentro de nuestros controladores Lambda (y el enrutamiento no es necesario para GraphQL).

Para la validación de solicitudes, viene gratis con GraphQL (otra razón para amar GraphQL). En cuanto a nuestro controlador REST, usamos esquemas JSON y cualquier error de validación, podemos regresar fácilmente al cliente junto con un mensaje de error HTTP 400.