Amazon API Gateway

Amazon API Gateway
Guía para desarrolladores

Amazon API Gateway Guía para desarrolladores
Amazon API Gateway: Guía para desarrolladores

Copyright © 2017 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner
that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not
owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by
Amazon.
Table of Contents
¿Qué es Amazon API Gateway? .......................................................................................................... 1
Gateway hasta la nube de AWS y más allá .................................................................................... 1
Parte de la infraestructura sin servidor de AWS ...................................................................... 2
Experiencias del desarrollador ...................................................................................................... 2
Creación y administración de una API de API Gateway ............................................................ 3
Llamada a una API de API Gateway ..................................................................................... 3
Ventajas de API Gateway ............................................................................................................ 3
Conceptos de API Gateway ......................................................................................................... 4
Introducción ....................................................................................................................................... 6
Prepararse para usar API Gateway ............................................................................................... 6
Suscribirse en AWS ............................................................................................................ 6
Crear un usuario, grupo o rol de IAM en su cuenta de AWS ...................................................... 7
Conceder permisos a usuarios de IAM para tener acceso a los servicios de control y ejecución
de API Gateway ................................................................................................................. 7
Paso siguiente ................................................................................................................... 8
Cree una API para exponer un punto de enlace HTTP ..................................................................... 8
Crear una API a partir de un ejemplo .................................................................................... 9
Crear la API paso a paso .................................................................................................. 16
Asignar parámetros de solicitudes ....................................................................................... 25
Asignar la carga de respuesta ............................................................................................ 33
Crear una API para exponer una función Lambda .......................................................................... 45
Paso 1: Requisitos previos ................................................................................................. 46
Paso 2: Crear una API ...................................................................................................... 46
Paso 3: Crear un recurso ................................................................................................... 46
Paso 4: Crear funciones Lambda ........................................................................................ 46
Paso 5: Crear y probar un método GET ............................................................................... 50
Paso 6: Crear y probar un método POST ............................................................................. 51
Paso 7: Implementar la API ................................................................................................ 52
Paso 8: Probar la API ....................................................................................................... 52
Paso 9: Eliminación .......................................................................................................... 53
Pasos siguientes ............................................................................................................... 54
Crear una API como un proxy HTTP o Lambda ............................................................................. 54
Creación y prueba de una API con integración de proxy HTTP ................................................ 54
Crear una API con la integración de proxy Lambda a través de un Recurso de proxy ................... 59
Crear un servicio de proxy de AWS ............................................................................................. 67
Requisitos previos ............................................................................................................. 68
Paso 1: Crear el recurso .................................................................................................... 68
Paso 2: Crear el método GET ............................................................................................ 68
Paso 3: Crear el rol de ejecución del proxy de servicio de AWS ............................................... 69
Paso 4: Especificar la configuración del método y probar el método .......................................... 70
Paso 5: Implementar la API ................................................................................................ 71
Paso 6: Probar la API ....................................................................................................... 71
Paso 7: Eliminación .......................................................................................................... 72
Crear una API .................................................................................................................................. 73
Crear una API sencilla ............................................................................................................... 73
Crear una API mediante la consola de API Gateway .............................................................. 74
Crear una API mediante el SDK de API Gateway para AWS ................................................... 74
Crear una API con la API REST de API Gateway .................................................................. 74
Crear una API con comandos de la AWS CLI ....................................................................... 79
Crear una API importando definiciones de Swagger ............................................................... 81
Configurar un método y una integración ....................................................................................... 83
Antes de configurar métodos e integraciones ........................................................................ 83
Configurar una solicitud de integración ................................................................................. 83
Configurar una solicitud de método ..................................................................................... 85
iii
Configuración de mapeo de datos entre método e integración .................................................. 87

Tratamiento de errores de Lambda en API Gateway .............................................................. 89
Habilitar la compatibilidad con cargas binarias ....................................................................... 94
Configurar una integración simulada para un método ............................................................ 112
Configuración de la integración del proxy ............................................................................ 115
Después de configurar métodos e integraciones .................................................................. 123
Crear modelos y plantillas de asignación para las cargas de solicitud y respuesta .............................. 123
Modelos ......................................................................................................................... 124
Plantillas de asignación .................................................................................................... 127
Tareas de modelos y plantillas de asignación ...................................................................... 129
Crear un modelo ............................................................................................................. 130
Ver una lista de modelos ................................................................................................. 130
Eliminar un modelo ......................................................................................................... 131
Ejemplo de fotos ............................................................................................................. 131
Ejemplo de artículo periodístico ......................................................................................... 134
Ejemplo de factura de ventas ............................................................................................ 138
Ejemplo de registro de empleado ...................................................................................... 142
Asignación de datos de solicitud y respuesta .............................................................................. 147
Asignar datos de solicitud de método a parámetros de solicitud de integración .......................... 147
Asignar datos de respuesta de integración a encabezados de respuesta de método ................... 149
Asignar cargas de solicitud y respuesta entre método e integración ......................................... 149
Comportamiento del acceso directo a la integración ............................................................. 150
Asignar datos de solicitud de método para personalizar recursos de gateway ............................ 151
Funciones y variables integradas en la plantilla de asignación ........................................................ 158
Acceso a la variable $context ........................................................................................... 158
Acceso a la variable $input ............................................................................................... 161
Acceso a la variable $stageVariables ................................................................................. 164
Acceso a la variable $util ................................................................................................. 164
Habilitar la validación básica de solicitudes para una API .............................................................. 165
Descripción general de la validación básica de solicitudes en API Gateway .............................. 166
Configurar la validación básica de solicitudes en API Gateway ............................................... 166
Probar la validación básica de solicitudes en API Gateway .................................................... 171
Definiciones de Swagger de una API de ejemplo con la validación básica de solicitudes ............. 174
Documentar una API ............................................................................................................... 177
Representación de la documentación de la API en API Gateway ............................................ 177
Documentar una API mediante la consola de API Gateway ................................................... 185
Documentar una API mediante la API REST de API Gateway ............................................... 193
Publicar la documentación de API ..................................................................................... 209
Importar la documentación de API ..................................................................................... 214
Controlar el acceso a la documentación de la API ................................................................ 216
Importar una API ..................................................................................................................... 217
Usar Import API para crear una nueva API ......................................................................... 217
Usar Import API para actualizar una API existente ............................................................... 218
basePath de Swagger ...................................................................................................... 219
Errores durante la importación .......................................................................................... 220
Advertencias durante la importación ................................................................................... 221
Controlar el acceso ................................................................................................................. 221
Usar permisos de IAM ..................................................................................................... 221
Habilitar CORS para un recurso ........................................................................................ 235
Usar autorizadores personalizados .................................................................................... 239
Usar conjuntos de usuarios de Amazon Cognito .................................................................. 252
Usar certificados SSL del lado cliente ................................................................................ 256
Entidades de certificación compatibles para las integraciones HTTP y Proxy HTTP .................... 260
Usar planes de uso de API Gateway ................................................................................. 280
Mantener una API ................................................................................................................... 291
Ver una lista de API ........................................................................................................ 291
Eliminar una API ............................................................................................................. 292
iv
Eliminar un recurso ......................................................................................................... 292

Ver una lista de métodos ................................................................................................. 293
Eliminar un método ......................................................................................................... 293
Implementar una API ....................................................................................................................... 294
Implementar una API desde la consola ...................................................................................... 295
Implementar una API en una etapa .................................................................................... 295
Actualizar la configuración de etapas de una implementación ................................................. 295
Establecer variables de etapa para la implementación .......................................................... 296
Asociación de una etapa a una implementación diferente ...................................................... 296
Administrar una etapa .............................................................................................................. 296
Asociar una implementación existente con una nueva etapa .................................................. 296
Actualizar la configuración de etapas ................................................................................. 297
Eliminar una etapa .......................................................................................................... 299
Optimizar el desempeño de la API ............................................................................................ 299
Limitar las solicitudes de la API ......................................................................................... 300
Habilitar el almacenamiento en caché de la API .................................................................. 301
Configurar variables de etapa ................................................................................................... 307
Casos de uso ................................................................................................................. 307
Ejemplos ........................................................................................................................ 307
Establecer variables de etapa ........................................................................................... 308
Usar variables de etapa ................................................................................................... 310
Referencia de variables de etapa ...................................................................................... 316
Exportar una API .................................................................................................................... 317
Solicitar la exportación de una API .................................................................................... 317
Descargar la definición de Swagger de la API en JSON ........................................................ 317
Descargar la definición de Swagger de la API en YAML ........................................................ 318
Descargar la definición de Swagger de la API con extensiones Postman en JSON ..................... 318
Descargar la definición de Swagger de la API con integración de API Gateway en YAML ............ 318
Exportar la API mediante la consola de API Gateway ........................................................... 318
Generar el SDK de una API ..................................................................................................... 319
Generar los SDK para una API mediante la consola de API Gateway ...................................... 319
Función Lambda de calculadora sencilla ............................................................................. 321
API de calculadora sencilla en API Gateway ....................................................................... 322
Definición de Swagger de la API de calculadora sencilla ....................................................... 327
Configurar un nombre de dominio personalizado .......................................................................... 332
Preparar certificados en AWS Certificate Manager ............................................................... 334
Configurar un nombre de dominio personalizado para una API de API Gateway ........................ 336
Registrar la creación del nombre de dominio personalizado en CloudTrail ................................ 339
Configurar la asignación de ruta base de una API con un nombre de dominio personalizado
como su nombre de host ................................................................................................. 340
Rotar un certificado importado en ACM .............................................................................. 341
Llamar a la API con nombres de dominio personalizados ...................................................... 342
Vender su API como SaaS ....................................................................................................... 343
Inicializar la integración de AWS Marketplace con API Gateway ............................................. 343
Administrar la suscripción de clientes a planes de uso .......................................................... 344
Llamar a una API ............................................................................................................................ 347
Obtener la URL Invoke de una API en la consola de API Gateway .................................................. 348
Usar la consola para probar un método ...................................................................................... 348
Requisitos previos ........................................................................................................... 349
Probar un método con la consola de API Gateway ............................................................... 349
Usar Postman para llamar a una API ......................................................................................... 349
Utilice un SDK de Java generado por API Gateway ...................................................................... 350
Usar un SDK de Android generado por API Gateway ................................................................... 353
Usar un SDK de JavaScript generado por API Gateway ................................................................ 355
Usar un SDK de iOS generado por API Gateway en Objective-C o Swift .......................................... 356
Usar el SDK de iOS generado (Objective-C) para llamar a una API ......................................... 357
Usar un SDK de iOS generado (Swift) para llamar a la API ................................................... 361
v
Rastrear las llamadas a la API con CloudWatch .......................................................................... 366

Registrar llamadas de administración de la API con CloudTrail ............................................... 366
Monitorizar API execution con Amazon CloudWatch ............................................................. 368
Extensiones de Swagger .................................................................................................................. 373
x-amazon-apigateway-any-method ............................................................................................ 374
Ejemplo de x-amazon-apigateway-any-method ..................................................................... 374
x-amazon-apigateway-authorizer ............................................................................................ 374
Ejemplos de x-amazon-apigateway-authorizer ...................................................................... 375
x-amazon-apigateway-authtype ................................................................................................ 378
Ejemplo de x-amazon-apigateway-authtype ......................................................................... 378
x-amazon-apigateway-binary-media-type ..................................................................................... 378
Ejemplo de x-amazon-apigateway-binary-media-types ........................................................... 378
x-amazon-apigateway-documentation ......................................................................................... 378
Ejemplo de x-amazon-apigateway-documentation ................................................................. 379
x-amazon-apigateway-gateway-responses ................................................................................... 379
Ejemplo de x-amazon-apigateway-gateway-responses .......................................................... 380
x-amazon-apigateway-gateway-responses.gatewayResponse ......................................................... 380
Ejemplo de x-amazon-apigateway-gateway-responses.gatewayResponse ................................ 381
x-amazon-apigateway-gateway-responses.responseParameters ..................................................... 381
Ejemplo de x-amazon-apigateway-gateway-responses.repsonseParameters ............................. 381
x-amazon-apigateway-gateway-responses.responseTemplates ....................................................... 382
Ejemplo de x-amazon-apigateway-gateway-responses.responseTemplates ............................... 382
x-amazon-apigateway-integration ........................................................................................... 382
Ejemplo de x-amazon-apigateway-integration ...................................................................... 384
x-amazon-apigateway-integration.requestTemplates ...................................................................... 385
Ejemplo de x-amazon-apigateway-integration.requestTemplates ............................................. 386
x-amazon-apigateway-integration.requestParameters .................................................................... 386
x-amazon-apigateway-integration.requestParameters Ejemplo .......................................... 386
x-amazon-apigateway-integration.responses ................................................................................ 387
x-amazon-apigateway-integration.responses Ejemplo ....................................................... 388
x-amazon-apigateway-integration.response .................................................................................. 388
x-amazon-apigateway-integration.response Ejemplo ........................................................ 389
x-amazon-apigateway-integration.responseTemplates ................................................................... 389
Ejemplo de x-amazon-apigateway-integration.responseTemplate ............................................ 390
x-amazon-apigateway-integration.responseParameters .................................................................. 390
x-amazon-apigateway-integration.responseParameters Ejemplo ........................................ 390
x-amazon-apigateway-request-validator ....................................................................................... 391
x-amazon-apigateway-request-validator Ejemplo ............................................................. 391
x-amazon-apigateway-request-validators ..................................................................................... 391
x-amazon-apigateway-request-validators Ejemplo ............................................................ 392
x-amazon-apigateway-request-validators.requestValidator .............................................................. 392
x-amazon-apigateway-request-validators.requestValidator Ejemplo ................................. 393
Ejemplos y tutoriales ....................................................................................................................... 394
Crear una API para funciones Lambda ....................................................................................... 394
Configurar un rol y una política de IAM para que una API invoque funciones Lambda ................. 396
Crear una función Lambda en el backend ........................................................................... 397
Crear recursos de API para la función Lambda .................................................................... 398
Crear un método GET con parámetros de consulta para llamar a la función Lambda ................. 399
Crear un método POST con una carga JSON para llamar a la función Lambda ........................ 402
Crear un método GET con parámetros de ruta para llamar a la función Lambda ....................... 405
Definiciones de Swagger de una API de ejemplo para una función Lambda .............................. 409
Crear una API como un proxy de Amazon S3 ............................................................................. 413
Configurar permisos de IAM para que la API invoque acciones de Amazon S3 .......................... 414
Crear recursos de API para representar recursos de Amazon S3 ............................................ 415
Exponer un método de API para mostrar los buckets de Amazon S3 del intermediario ................ 416
Exponer métodos de API para tener acceso a un bucket de Amazon S3 .................................. 422
Exponer métodos de API para tener acceso a un objeto de Amazon S3 en un bucket ................. 425
vi
Llamar a la API mediante un cliente API REST ................................................................... 428

Definiciones de Swagger de una API de ejemplo como un proxy de Amazon S3 ........................ 430
Crear una API como un proxy de Amazon Kinesis ....................................................................... 439
Crear un rol y una política de IAM para que la API tenga acceso a Kinesis ............................... 440
Empezar a crear una API como un proxy de Kinesis ............................................................ 442
Mostrar flujos en Kinesis .................................................................................................. 442
Crear, describir y eliminar un flujo en Kinesis ...................................................................... 447
Obtener registros y añadir registros a un flujo de Kinesis ...................................................... 452
Definiciones de Swagger de una API de ejemplo como un proxy de Kinesis .............................. 463
API REST de API Gateway .............................................................................................................. 470
Límites, precios y problemas conocidos .............................................................................................. 471
Límites de API Gateway ........................................................................................................... 471
Límites de API Gateway para configurar y ejecutar una API ................................................... 471
Límites de API Gateway para crear, implementar y administrar una API ................................... 472
Precios de API Gateway .......................................................................................................... 473
Problemas conocidos ............................................................................................................... 474
Historial de revisión ......................................................................................................................... 476
AWS Glossary ................................................................................................................................ 481
vii
Gateway hasta la nube de AWS y más allá
¿Qué es Amazon API Gateway?
Amazon API Gateway es un servicio de AWS que permite a los desarrolladores crear, publicar, mantener,
monitorizar y proteger API a cualquier escala. Puede crear API que accedan a AWS o a otros servicios
web, así como los datos almacenados en la nube de AWS.
Temas
• Gateway hasta la nube de AWS y más allá (p. 1)
• Experiencias del desarrollador (p. 2)
• Ventajas de API Gateway (p. 3)
• Conceptos de Amazon API Gateway (p. 4)
Gateway hasta la nube de AWS y más allá

API Gateway puede considerarse un backplane en la nube para conectar los servicios de AWS públicos
o privados y otros sitios web. Proporciona interfaces de programación de aplicaciones (API RESTful)
coherentes para que las aplicaciones móviles y web accedan a los servicios de AWS.
En el siguiente diagrama se muestra la arquitectura de API Gateway.
1
Parte de la infraestructura sin servidor de AWS
En la práctica, API Gateway le permite crear, configurar y alojar una API RESTful para permitir que las
aplicaciones accedan a la nube de AWS. Por ejemplo, una aplicación que utiliza API Gateway puede
cargar la información de gastos e ingresos anuales de un usuario a Amazon S3 o que Amazon DynamoDB,
procese los datos de AWS Lambdapara computar el impuesto adeudado y enviar una declaración de
impuestos a través del sitio web del IRS.
Tal y como se muestra en el diagrama de arquitectura, una aplicación (o cliente) obtiene acceso mediante
programación a los servicios de AWS, o a un sitio web en Internet, a través de una o varias API, alojadas
en API Gateway. La aplicación está en frontend de la API. Los servicios y sitios web de AWS integrados se
encuentran en el backend de la API.
Gracias a Amazon API Gateway, puede ofrecer a los usuarios una experiencia de desarrollador integrada y
coherente a la hora de crear aplicaciones de AWS basadas en la nube.
Parte de la infraestructura sin servidor de AWS

Junto con AWS Lambda, API Gateway es la parte de la infraestructura sin servidor de AWS orientada a la
aplicación. Para que una aplicación llame a los servicios de AWS disponibles públicamente, puede utilizar
Lambda para interactuar con los servicios necesarios y exponer las funciones Lambda a través de los
métodos de API de API Gateway. AWS Lambda ejecuta el código en una infraestructura informática de
alta disponibilidad. Realiza todos los procesos de ejecución y administración que necesitan los recursos
informáticos. Para habilitar las aplicaciones sin servidor, API Gateway es compatible con las integraciones
de proxy optimizadas (p. 115) con puntos de enlace AWS Lambda y HTTP.
Experiencias del desarrollador

Existen dos tipos de desarrolladores que utilizan API Gateway: de aplicaciones y de API. El desarrollador
de aplicaciones diseña una aplicación funcional que llame a los servicios de AWS a través de API
Gateway. El desarrollador de API crea e implementa una API para habilitar la funcionalidad necesaria en
API Gateway. El desarrollador de API debe ser un usuario de IAM en la cuenta de AWS que posee la API.
2
Creación y administración de una API de API Gateway
El desarrollador de aplicaciones no necesita tener una cuenta de AWS, siempre que la API no requiera
permisos de IAM.
Creación y administración de una API de API Gateway

Para crear, configurar e implementar una API, un desarrollador de API trabaja con el componente del
servicio de API Gateway denominado apigateway. Cada API incluye un conjunto de recursos y métodos.
Un recurso es una entidad lógica a la que una aplicación puede acceder a través de una ruta de recursos.
Por ejemplo, /incomes es la ruta del recurso que representa los ingresos del usuario de la aplicación. Un
recurso puede tener una o varias operaciones, las cuales definen los verbos HTTP correspondientes, por
ejemplo, GET, POST PUT, PATCH y DELETE. Una combinación de una ruta de recurso y una operación
identifica un método de la API. Por ejemplo, el método POST /incomes añade una ganancia devengada por
el intermediario y el método GET /expenses consulta los gastos en los que ha incurrido el intermediario.
Un método se corresponde con una solicitud de la API REST enviada por el usuario de la API y la
respuesta correspondiente devuelta al usuario. La aplicación no necesita saber dónde se almacenan y
de dónde se obtienen los datos solicitados. La API se conecta con el backend mediante la solicitud de
integración o la respuesta de integración.
Por ejemplo, con DynamoDB como backend, el desarrollador de la API configura la solicitud de integración
para reenviar la solicitud del método de entrada al backend elegido. La configuración incluye las
especificaciones de acción de DynamoDB adecuadas y los roles y políticas de IAM necesarios, así como
la transformación de los datos de entrada correcta. El backend devuelve el resultado a API Gateway
como una respuesta de integración. Para dirigir la respuesta de integración a una respuesta de método
adecuada (de un determinado código de estado HTTP) al cliente, puede configurar la respuesta de
integración para que mapee los parámetros de respuesta necesarios desde la integración del método. A
continuación, si fuera necesario, convierta el formato de los datos de salida del backend al del frontend.
API Gateway le permite definir un esquema o modelo de carga para facilitar la configuración de la plantilla
de mapeo de cuerpo.
Como desarrollador de API, puede crear y administrar una API mediante la consola de administración
de API Gateway tal y como se describe en Introducción (p. 6)o llamando a la API REST de API
Gateway (p. 470). Existen varias maneras de llamar a esta API. Incluyen el uso de la interfaz de línea de
comandos (CLI) de AWS o un SDK de AWS. También puede utilizar un cliente de API REST, por ejemplo,
Postman, para realizar llamadas al API sin procesar. Además, puede habilitar la creación de la API con
plantillas de AWS CloudFormation o Extensiones de API Gateway para Swagger (p. 373). Para obtener
una lista de las regiones en las que API Gateway está disponible, así como de los puntos de enlace del
servicio de control asociados, consulte Regiones y puntos de enlace.
Llamada a una API de API Gateway

Un desarrollador de aplicaciones trabaja con el componente de servicio de API Gateway, denominado
execute-api, para invocar una API que se ha creado o implementado en API Gateway. La API creada
expone las entidades de programación subyacentes. Existen varias maneras de llamar a dicha API. Puede
utilizar la consola de API Gateway para probar a invocar la API. Puede utilizar un cliente de API REST, por
ejemplo, Curl o Postman, o un SDK generado por API Gateway para que la API invoque la API.
Tenga en cuenta las diferencias entre los componentes de servicio apigateway y execute-api de API
Gateway. Haga referencia al nombre del componente de servicio correspondiente al seleccionar uno, por
ejemplo, la configuración de políticas de permisos de IAM para crear o llamar a una API.
Ventajas de API Gateway

API Gateway le ayuda a proporcionar backends de aplicaciones móviles y web robustos, seguros y
escalables. API Gateway le permite conectar de forma segura aplicaciones web y móviles a la lógica
3
Conceptos de API Gateway
empresarial alojada en las API de AWS Lambda incluidas en Amazon EC2 u otros servicios web
disponibles públicamente alojados dentro o fuera de AWS. Gracias a API Gateway, puede crear y utilizar
las API de servicios de backend. Por ejemplo, no es necesario desarrollar y mantener una infraestructura
que administre la autorización y el control del acceso, la administración del tráfico, la monitorización y los
análisis, la administración de las versiones y la generación de kits de desarrollo de software (SDK).
API Gateway se ha diseñado para los desarrolladores de aplicaciones web y móviles que desean
proporcionar un acceso seguro y de confianza a las API de backend desde aplicaciones móviles,
aplicaciones web y aplicaciones de servidor creadas internamente o por el ecosistema de terceros. La
lógica empresarial incluida en las API puede proporcionarse mediante un punto de enlace disponible
públicamente al que llamen los proxies de API Gateway o puede ejecutarse en su totalidad como una
función de Lambda.
Conceptos de Amazon API Gateway

API Gateway
AWS es un servicio de API Gateway que admite lo siguiente:

1. Crear, implementar y administrar una interfaz de programación de aplicaciones (API) RESTful para
exponer los puntos de enlace HTTP del backend, funciones AWS Lambda u otros servicios de
AWS.
2. invocar los métodos de API expuestos a través de los puntos de enlace HTTP del frontend.
API de API Gateway
Una colección de recursos y métodos que se integran con puntos de enlace HTTP del backend,
funciones Lambda u otros servicios de AWS. La colección se puede implementar en una o más fases.
Los métodos de la API se invocan a través de puntos de enlace HTTP del frontend que puede asociar
a un nombre de dominio personalizado registrado. Los permisos para invocar un método se conceden
mediante roles y políticas de IAM o autorizadores personalizados de API Gateway. Una API puede
presentar un certificado para que el backend lo autentique. Normalmente, los recursos de la API están
organizados en un árbol de recursos de acuerdo con la lógica de la aplicación. Cada recurso de la API
puede exponer uno o varios métodos de la API que deben tener verbos HTTP únicos admitidos por
API Gateway.
Desarrollador o propietario de la API
Una cuenta de AWS que posee una implementación de API Gateway (por ejemplo, un proveedor de
servicios que también es compatible con el acceso mediante programación).
Desarrollador de aplicaciones o desarrollador cliente
Un creador de aplicaciones que puede tener o no una cuenta de AWS y que interactúa con la API
implementada por el desarrollador de API. Un desarrollador de aplicaciones se puede representar
mediante una clave de API.
Usuario de la aplicación, usuario final o punto de enlace cliente.
Una entidad que utiliza la aplicación desarrollada por un desarrollador de aplicaciones. La entidad
interactúa con las API en Amazon API Gateway. Un usuario de la aplicación se puede representar
mediante una identidad de Amazon Cognito o un token de portador.
Clave de API
Una cadena alfanumérica generada API Gateway en nombre de un propietario de la API o importados
de un recurso externo, por ejemplo, un archivo CSV. La cadena se utiliza para identificar a un
desarrollador de aplicaciones de la API. Un propietario de la API puede utilizar claves de API para
permitir o denegar el acceso a determinadas API en función de las aplicaciones en uso.
4
Conceptos de API Gateway
Implementación y etapa de API
Una implementación de la API es una snapshot de un punto en el tiempo de los recursos y métodos
de la API de API Gateway. Para que un cliente pueda invocar una implementación, esta debe
asociarse a una o varias fases. Una etapa es una referencia lógica a un estado del ciclo de vida de la
API (por ejemplo, 'dev', 'prod', 'beta', 'v2'). El identificador de una etapa de API se compone de un ID y
un nombre de etapa de API.
Solicitud de método
La interfaz pública de un método de API en API Gateway que define los parámetros y el cuerpo que
un desarrollador de aplicaciones debe enviar en las solicitudes para acceder al backend a través de la
API.
Solicitud de integración
Una interfaz interna de API Gateway que define cómo API Gateway mapea los parámetros y el cuerpo
de una solicitud de método en los formatos requeridos por el backend.
Respuesta de integración
Una interfaz interna de API Gateway que define cómo API Gateway asigna datos. La respuesta de
integración incluye los códigos de estado, encabezados y carga que se reciben del backend en los
formatos definidos por un desarrollador de aplicaciones.
Respuesta de método
La interfaz pública de una API que define los códigos de estado, los encabezados y los modelos de
cuerpo que un desarrollador de aplicaciones debería esperar de API Gateway.
Integración de proxy
Una configuración de integración de API Gateway simplificada. Puede configurar una integración
de proxy como un tipo de integración de proxy HTTP o como un tipo de integración de proxy de
Lambda. En el caso de la integración de proxy HTTP, API Gateway transmite toda la solicitud y la
respuesta entre el frontend y el backend HTTP. En el caso de la integración de proxy Lambda, API
Gateway envía toda la solicitud como una entrada a la función Lambda del backend. A continuación,
API Gateway transforma el resultado de la función Lambda en una respuesta HTTP del frontend. La
integración de proxy se utiliza normalmente con un recurso de proxy, que se representa mediante una
variable de ruta expansiva (por ejemplo, {proxy+}) combinada con un método catch-all ANY.
Plantilla de asignación
Scripts, expresados en VTL (Velocity Template Language), para transformar un cuerpo de solicitud
del formato de datos del frontend en el formato de datos del backend o para transformar un cuerpo de
solicitud del formato de datos del backend en el formato de datos del frontend. Las plantillas de mapeo
se especifican en la solicitud de integración o en la respuesta de integración. Pueden hacer referencia
a datos disponibles en tiempo de ejecución como contexto y variables de fase. Una transformación de
identidad se conoce como "acceso directo" (o passthrough) y consiste en transmitir una carga tal cual
está del cliente al backend en el caso de una solicitud y desde el backend al cliente si se trata de una
respuesta.
Modelo
Esquema de datos que especifica la estructura de datos de una solicitud o carga de respuesta. Es
necesario para generar un SDK con establecimiento inflexible de tipos de una API. También se utiliza
para validar la carga. Un modelo es cómodo para generar una plantilla de mapeo de muestra para
iniciar la creación de una plantilla de mapeo de producción. Aunque es útil, no se requiere para crear
una plantilla de asignación.
Plan de uso
Un plan de uso ofrece a los clientes de la de API seleccionada acceso a una o más API
implementadas. Puede utilizar un plan de uso para configurar la limitación controlada y los límites de
cuota que se ejecutarán en claves de API de cliente individual.
5
Prepararse para usar API Gateway
Introducción a Amazon API Gateway

Los siguientes tutoriales incluyen ejercicios prácticos, en los que se utiliza la consola API Gateway, que le
ayudarán a obtener información sobre API Gateway.
Temas
• Prepararse para usar Amazon API Gateway (p. 6)
• Cree una API de API Gateway para exponer un punto de enlace HTTP (p. 8)
• Crear una API para exponer una función Lambda (p. 45)
• Crear una API de API Gateway como un proxy HTTP o Lambda (p. 54)
• Crear un servicio de proxy de AWS para Amazon SNS (p. 67)
Prepararse para usar Amazon API Gateway

Antes de utilizar API Gateway por primera vez, debe haber configurado una cuenta de AWS. Para crear,
configurar e implementar una API en API Gateway, debe tener la política de IAM adecuada aprovisionada
con derechos de acceso al servicio de control de API Gateway. Para permitir que sus clientes de la API
invoquen la API en API Gateway, debe configurar la política de IAM adecuada para permitir a los clientes
llamar al servicio de ejecución de API Gateway. Para permitir que API Gateway invoque un servicio de
AWS en el backend, API Gateway debe tener permisos para asumir los roles necesarios para llamar al
servicio de AWS del backend. Cuando se configura una API de API Gateway para utilizar roles y políticas
de AWS IAM para controlar el acceso de los clientes, el cliente debe firmar las solicitudes de la API de API
Gateway con Signature Version 4.
Es importante que conozca estos temas para usar API Gateway, y que siga los tutoriales y las
instrucciones que se presentan aquí. En esta sección se proporciona una breve explicación o una
referencia rápida a estos temas.
Temas
• Suscribirse en AWS (p. 6)
• Crear un usuario, grupo o rol de IAM en su cuenta de AWS (p. 7)
• Conceder permisos a usuarios de IAM para tener acceso a los servicios de control y ejecución de API
Gateway (p. 7)
• Paso siguiente (p. 8)
Suscribirse en AWS
Si no dispone de una cuenta de AWS, utilice el siguiente procedimiento para crearla.
6
Crear un usuario, grupo o rol de IAM en su cuenta de AWS
Para inscribirse en AWS
1. Abra https://aws.amazon.com/ y elija Create an AWS Account.

2. Siga las instrucciones en línea.
Crear un usuario, grupo o rol de IAM en su cuenta de

AWS
Como práctica de seguridad recomendada, debe evitar usar su cuenta raíz de AWS para tener acceso a
API Gateway. En su lugar, cree un nuevo usuario de AWS Identity and Access Management (IAM) o utilice
uno existente en su cuenta de AWS y, a continuación, obtenga acceso a API Gateway con las credenciales
de ese usuario de IAM.
Para administrar el acceso de un usuario, puede crear un usuario de IAM y conceder al usuario permisos
de acceso a API Gateway. Para crear un nuevo usuario de IAM, consulte Creating an IAM User.
Para administrar el acceso de un grupo de usuarios, puede crear un grupo de IAM, conceder al grupo
permisos de acceso a API Gateway y después añadir uno o varios usuarios de IAM al grupo. Para crear un
grupo de IAM, consulte Creating IAM Groups.
Para delegar el acceso a usuarios, aplicaciones o servicios específicos, puede crear un rol de IAM, añadir
los usuarios o grupos especificados al rol y conceder a los usuarios o grupos permisos de acceso a API
Gateway. Para crear un rol de IAM, consulte Creating IAM Roles.
Cuando configure su API, deberá especificar el ARN de un rol de IAM para controlar el acceso a los
métodos de la API. Asegúrese de que dispone del ARN cuando cree una API.
Conceder permisos a usuarios de IAM para tener

acceso a los servicios de control y ejecución de API
Gateway
En AWS, los permisos de acceso se establecen como políticas. Una política creada por AWS es una
política administrada y una creada por un usuario es una política integrada.
Para el servicio de control de API Gateway, la política administrada de AmazonAPIGatewayAdministrator

(arn:aws:iam::aws:policy/AmazonAPIGatewayAdministrator) concede acceso total para crear,
configurar e implementar una API en API Gateway:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": "arn:aws:apigateway:*::/*"
}
]
}
Para conceder los permisos establecidos a un usuario, asocie la política al usuario o a un grupo que
contenga al usuario. Para asociar una política, consulte Attaching Managed Policies.
7
Paso siguiente
Al asociar la política anterior a un usuario de IAM se proporciona al usuario acceso a todas las acciones
y recursos del servicio de control de API Gateway asociados con la cuenta de AWS. Para obtener
información sobre cómo restringir a los usuarios de IAM a un conjunto limitado de acciones y recursos del
servicio de control de API Gateway, consulte Usar permisos de IAM (p. 221).
Para el servicio de ejecución de API Gateway, la política administrada

de AmazonAPIGatewayInvokeFullAccess ( arn:aws:iam::aws:policy/
AmazonAPIGatewayInvokeFullAccess) proporciona acceso completo para invocar una API en API
Gateway:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": "arn:aws:execute-api:*:*:*"
}
]
}
Al asociar la política anterior a un usuario de IAM se proporciona al usuario acceso a todas las acciones
y recursos del servicio de ejecución de API Gateway asociados con la cuenta de AWS. Para obtener
información sobre cómo restringir a los usuarios de IAM a un conjunto limitado de acciones y recursos del
servicio de ejecución de API Gateway, consulte Usar permisos de IAM (p. 221).
Para conceder los permisos establecidos a un usuario, asocie la política al usuario o a un grupo que
contenga al usuario. Para asociar una política, consulte Attaching Managed Policies.
En esta documentación, usaremos políticas administradas, siempre que sea posible. Para crear y utilizar
políticas integradas, consulte Working with Inline Policies.
Note
Para completar los pasos anteriores, debe tener permiso para crear la política de IAM y asociarla
al usuario de IAM que desee.
Paso siguiente
Ahora está listo para empezar a utilizar API Gateway. Consulte Crear una API de API Gateway a partir de
un ejemplo (p. 9).
Cree una API de API Gateway para exponer un

punto de enlace HTTP
Puede crear una API en la consola de Amazon API Gateway desde el principio. Fundamentalmente, usará
la consola como un estudio de diseño de la API para definir el ámbito de las características de API, para
probar su comportamiento, para crear la API y para implementar la API en etapas.
Temas
• Crear una API de API Gateway a partir de un ejemplo (p. 9)
• Crear la API paso a paso (p. 16)
• Asignar parámetros de solicitudes para una API de API Gateway (p. 25)
• Asignar la carga de respuesta (p. 33)
8
Crear una API a partir de un ejemplo
Crear una API de API Gateway a partir de un ejemplo

La consola de Amazon API Gateway ofrece ahora una opción para que pueda crear una API de API
Gateway a partir de un ejemplo, con consejos útiles proporcionados durante todo el proceso. Si es
la primera vez que utiliza API Gateway, es posible que esta opción le sirva como una herramienta de
aprendizaje. Los siguientes pasos le guían por el proceso de crear y probar la API de ejemplo mediante
esta opción de creación a partir de un ejemplo.
1. Aplique alguna de las siguientes acciones:
a. En el caso de la primera API de la cuenta, elija Get Started en la página de bienvenida de la

consola de API Gateway.
Si se muestra un cuadro de diálogo modal que contiene sugerencias en una etapa del proceso,
elija OK para cerrar el cuadro de diálogo modal y continuar.
b. Para la siguiente API, elija Create API en la página de inicio APIs de API Gateway:
2. En Create new API, seleccione Examples API y, a continuación, elija Import para crear la API de
ejemplo. Para la primera API, la consola de API Gateway comenzará con esta opción de forma
predeterminada.
Puede desplazarse por la definición de Swagger para obtener información detallada sobre esta API de
ejemplo antes de elegir Import.
3. La API recién creada se muestra de la siguiente forma:
9
El panel Resources muestra la estructura de la API creada como un árbol de nodos. Los métodos de
API definidos en cada recurso son los extremos del árbol. Cuando se selecciona un recurso, todos sus
métodos se muestran en el panel Methods situado a la derecha. Debajo de cada método hay un breve
resumen del método, incluidos sus requisitos de URL de punto de enlace, tipo de autorización y clave
de API.
4. Para ver los detalles de un método, para modificar su configuración o para probar la invocación del
método, elija el nombre del método en la lista de métodos o en el árbol de recursos. A continuación,
elegimos el POST /pets método como ejemplo:
El panel resultante Method Execution presenta una vista lógica de la estructura del método (POST /
pets) elegida y los comportamientos: Method Request y Method Response son la interfaz de la API
10
con el frontend de la API (un cliente), mientras que Integration Request e Integration Response son
la interfaz de la API con el backend (http://petstore-demo-endpoint.execute-api.com/pets).
Un cliente utiliza la API para obtener acceso a una característica del backend a través de Method
Request. API Gateway traduce la solicitud del cliente, si fuera necesario, a un formato aceptable por
el backend en Integration Request antes de reenviar la solicitud entrante al backend. La solicitud
transformada se conoce como la solicitud de integración. Del mismo modo, el backend devuelve la
respuesta a API Gateway en Integration Response. A continuación, API Gateway la dirige a Method
Response antes de enviarla al cliente. De nuevo, si fuera necesario, API Gateway puede mapear los
datos de la respuesta del backend a un formulario previsto por el cliente.
En el caso del método POST de recurso de API, la carga de la solicitud del método puede transmitirse
a través de la solicitud de integración sin modificación si la carga de la solicitud de método está en el
mismo formato que la carga de la solicitud de integración.
La solicitud del método GET / usa el tipo de integración MOCK y no está vinculada a ningún punto de
enlace de backend real. La Integration Response correspondiente está configurada para devolver
una página HTML estática. Cuando se llama al método, API Gateway simplemente acepta la solicitud
e inmediatamente devuelve la respuesta a la integración configurada al cliente a través de Method
Response. Puede utilizar la integración simulada para probar una API sin requerir un punto de enlace
del backend. También puede utilizarla para servir una respuesta local generada partir de una plantilla
de mapeo de cuerpo de respuesta.
Como desarrollador de la API, puede controlar los comportamientos de las interacciones del frontend
de la API mediante la configuración de la solicitud de método y una respuesta de método. Puede
controlar los comportamientos de las interacciones del backend de la API mediante la configuración
de la solicitud de integración y la respuesta de integración. Estos comportamientos implican mapeos
de datos entre un método y su integración correspondiente. Explicaremos cómo configurar un método
en Cree una API de API Gateway para exponer un punto de enlace HTTP (p. 8). Por el momento,
nos centraremos en probar la API para proporcionar una experiencia de usuario completa.
5. Elija Test en Client (tal y como se muestra en la imagen anterior) para comenzar la prueba. Por
ejemplo, para probar el método POST /pets, escriba la siguiente carga {"type": "dog","price":
249.99} en Request Body antes de elegir el botón Test.
11
12
La entrada especifica los atributos de la mascota que deseamos añadir a la lista de mascotas en el
sitio web PetStore.
6. El resultado es el siguiente:
La entrada Logs de la salida muestra los cambios de estado de la solicitud del método a la solicitud de
integración y de la respuesta de integración a la respuesta del método. Esto puede resultar útil para
la resolución de errores de asignación que impidan que la solicitud se realice correctamente. En este
ejemplo, el mapeo no se aplica: la carga de la solicitud de método se transfiere a través de la solicitud
13
integración al backend y, de forma parecida, la respuesta del backend se transfiere a través de la

respuesta de integración al método de respuesta.
Para probar la API con un cliente distinto de la característica test-invoke-request de API Gateway,
primero debe implementar la API en una etapa.
7. Para implementar la API de ejemplo, seleccione la API PetStore y, a continuación, elija Deploy API en
el menú desplegable Actions.
En Deploy API, para Deployment stage, elija [New Stage] porque esta es la primera implementación
de la API. Escriba un nombre (por ejemplo, test) n Stage name y, si lo desea, escriba las
descripciones en Stage description y Deployment description. Elija Deploy.
14
En el panel Stage Editor resultante, Invoke URL muestra la dirección URL para invocar la solicitud del
método GET / de la API.
8. En Stage Editor, siga el enlace Invoke URL para enviar la solicitud del método GET / en un navegador.
Una respuesta correcta devuelve el resultado, generado a partir de la plantilla de mapeo de la
respuesta de integración.
9. En el panel de navegación Stages, expanda la etapa test, seleccione GET en /pets/{petId} y, a
continuación, copie el valor Invoke URL de https://api-id.execute-api.region.amazonaws.com/
test/pets/{petId}. {petId} representa una variable de ruta.
Pegue el valor de Invoke URL (obtenido en el paso anterior) en la barra de direcciones de un

navegador, sustituyendo {petId} por 1 (por ejemplo) y, a continuación, pulse Intro para enviar la
solicitud. Debería devolverse una respuesta 200 OK con la siguiente carga JSON:
{
"id": 1,
"type": "dog",
"price": 249.99
}
Invocar el método de la API tal como se muestra es posible porque su tipo Authorization está
establecido en NONE. Si usara la autorización de AWS_IAM, debería firmar la solicitud usando los
protocolos de Signature Version 4. Para ver un ejemplo de una solicitud de este tipo, consulte Cree
una API de API Gateway para exponer un punto de enlace HTTP (p. 8).
Véase también
Usar autorizadores personalizados (p. 239), Implementar una API (p. 294)
15
Crear la API paso a paso

Esta sección le guía por los pasos para crear recursos, exponer métodos en un recurso, configurar un
método para lograr los comportamientos de la API deseados y probar e implementar la API.
1. Desde Create new API, seleccione New API, escriba un nombre en API Name, añada una descripción
opcional en Description y, a continuación, elija Create API.
Como resultado, se creará una API vacía. El árbol Resources muestra el recurso de raíz (/) sin
métodos. En este ejercicio, vamos a crear la API con la integración de HTTP del sitio web de PetStore
de demostración (http://petstore-demo-endpoint.execute-api.com). Con fines ilustrativos, crearemos
un recurso /pets como un elemento secundario de la raíz y expondremos un método GET en este
recurso para que un cliente pueda recuperar una lista de los elementos Pets disponibles en el sitio
web de PetStore.
2. Para crear el recurso /pets, seleccione la raíz, elija Actions y, a continuación, elija Create Resource.
16
Escriba Pets en Resource Name, deje el valor de Resource Path que aparece y elija Create Resource.
3. Para exponer un método GET en el recurso /pets, elija Actions y después Create Method.
Seleccione GET en la lista situada bajo el nodo del recurso /pets y elija el icono de marca de
verificación para terminar de crear el método.
17
Note
Otras opciones para un método de API son las siguientes:
• POST, que se utiliza principalmente para crear recursos secundarios.

• PUT, que se utiliza principalmente para actualizar los recursos existentes (y, aunque no es
recomendable, puede utilizarse para crear recursos secundarios).
• DELETE, que se utiliza para eliminar recursos.
• PATCH, que se utiliza para actualizar los recursos.
• HEAD, que se utiliza principalmente en escenarios de pruebas. Es igual que GET, pero no
devuelve la representación de los recursos.
• OPTIONS, que pueden usar los intermediarios para obtener la información sobre las
opciones de comunicación disponibles para el servicio de destino.
El método creado aún no está integrado con el backend. Lo haremos en el siguiente paso.
4. En el panel Setup del método, seleccione HTTP para Integration type, seleccione GET en la lista
desplegable HTTP method, escriba http://petstore-demo-endpoint.execute-api.com/petstore/
pets como el valor de Endpoint URL, no modifique el resto de campos y, a continuación, elija Save.
Note
En el caso del HTTP method de la solicitud de integración, debe elegir uno de los métodos
compatibles con el backend. Para HTTP o Mock integration, es razonable que la solicitud
del método y la solicitud de integración usen el mismo verbo HTTP. Para otros tipos de
integración, la solicitud del método usará probablemente un verbo HTTP diferente del de
la solicitud de integración. Por ejemplo, para llamar a una función Lambda, la solicitud de
integración debe utilizar POST para invocar la función, mientras que la solicitud del método
puede utilizar cualquier verbo HTTP en función de la lógica de la función Lambda.
18
Cuando termine de configurar el método, aparecerá el panel Method Execution, donde puede seguir
configurando la solicitud del método para añadir parámetros de cadena de consulta o de encabezados
personalizados. También puede actualizar la solicitud de integración para que asigne los datos de la
solicitud del método en el formato requerido por el backend.
El sitio web de PetStore le permite recuperar una lista de elementos Pet por tipo de mascota (por
ejemplo, "Dog" o "Cat") en una determinada página. Utiliza los parámetros de cadena de consulta
type y page para aceptar esta entrada. Por tanto, tenemos que añadir los parámetros de cadena
de consulta a la solicitud del método y asignarlos a las cadenas de consulta correspondientes de la
solicitud de integración.
5. En el panel Method Execution del método GET, elija Method Request, seleccione AWS_IAM para
Authorization, amplíe la sección URL Query String Parameters y elija Add query string para crear dos
parámetros de cadena de consulta denominados type y page. Elija el icono de marca de verificación
para guardar los parámetros de cadena de consulta que acaba de añadir.
19
El cliente ahora puede proporcionar un tipo de mascota y un número de página como parámetros de
cadena de consulta cuando envíe una solicitud. Estos parámetros de entrada deben mapearse a los
parámetros de cadena de consulta de la integración para reenviar los valores de entrada a nuestro
sitio web de PetStore en el backend. Como el método utiliza AWS_IAM, debe firmar la solicitud para
invocar el método.
6. En la página Integration Request del método, amplíe la sección URL Query String Parameters. De
forma predeterminada, los parámetros de cadena de consulta de la solicitud del método se asignan a
los parámetros de cadena de consulta de la solicitud de integración de igual nombre. Esta asignación
predeterminada funciona para nuestra API de demostración. La dejaremos como está. Para mapear
un parámetro de método de solicitud diferente al parámetro de método de integración correspondiente,
elija el icono de lápiz del parámetro para editar la expresión de mapeo, mostrada en la columna
Mapped from. Para mapear un parámetro de solicitud de método a un parámetro de solicitud de
integración diferente, primero seleccione el icono de eliminación para eliminar el parámetro de solicitud
de integración existente y elija Add query string para especificar un nuevo nombre y la expresión de
mapeo del parámetro de solicitud del método que desee.
20
Con esto finaliza la creación de esta API sencilla de demostración. Es el momento de probar la API.
7. Para probar la API utilizando la consola de API Gateway, elija Test en el panel Method Execution del
método GET /pets. En el panel Method Test, escriba Dog y 2 para las cadenas de consulta type y
page, respectivamente y, a continuación, elija Test.
21
El resultado es el siguiente. (Es posible que necesite desplazarse hacia abajo para ver los resultados
de la prueba).
22
Ahora que la prueba se ha realizado correctamente, podemos implementar la API para ponerla a
disposición del público en general.
8. Para implementar la API, seleccione la API y, a continuación, elija Deploy API en el menú desplegable
Actions.
23
En el cuadro de diálogo Deploy API, seleccione una etapa (o [New Stage] para la primera
implementación de la API); escriba un nombre (por ejemplo, "test", "prod", "dev", etc.) en el cuadro
de entrada Stage name; si lo desea, proporcione una descripción en Stage description o Deployment
description; y, a continuación, elija Deploy.
Una vez implementada, puede obtener las URL de invocación (Invoke URL) de los puntos de enlace
de la API.
24
Asignar parámetros de solicitudes
Si el método GET admitiera el acceso anónimo, (por ejemplo, si el tipo de autorización del método
se hubiera establecido en NONE), podría hacer doble clic en el enlace Invoke URL para invocar el
método en su navegador predeterminado. Si fuera necesario, podría también agregar los parámetros
de cadena de consulta necesarios a la URL de invocación. Con el tipo de autorización de AWS_IAM
que se describe aquí, deberá firmar la solicitud con un ID de clave de acceso y la clave secreta
correspondiente de un usuario de IAM de su cuenta de AWS. Para ello, debe utilizar un cliente
que admita los protocolos Signature Version 4 (SigV4). Un ejemplo de este tipo de cliente es una
aplicación que utilice uno de los SDK de AWS o la extensión Postman del navegador Chrome. Para
llamar a un método POST, PUT o PATCH, también necesitará un cliente de este tipo para administrar
la carga.
Para invocar este método de API en la extensión Postman, añada los parámetros de cadena de
consulta a la URL de invocación específica de la etapa (tal y como se muestra en la imagen anterior)
para crear la URL de la solicitud de método completa:
https://api-id.execute-api.region.amazonaws.com/test/pets?type=Dog&page=2
Especifique esta URL en la barra de direcciones del navegador. Elija GET como verbo HTTP.
Seleccione AWS Signature para la opción Type bajo la pestaña Authorization y, a continuación,
especifique las siguientes propiedades obligatorias antes de enviar la solicitud:
• En AccessKey, escriba la clave de acceso de AWS del intermediario, aprovisionada desde AWS
IAM.
• En SecretKey, escriba la clave secreta de AWS del intermediario que se aprovisionó desde AWS
IAM cuando se creó la clave de acceso.
• En AWS Region, escriba la región de AWS donde se va a alojar la API, tal como se especifica en la
URL de invocación.
• En Service Name, escriba execute-api para el servicio de ejecución de API Gateway.
Si utiliza un SDK para crear un cliente, puede llamar a los métodos expuestos por el SDK para firmar
la solicitud. Para obtener más información sobre la implementación, consulte los SDK de AWS de su
elección.
Note
Cuando se realicen cambios en la API, deberá volver a implementar la API para que las
características nuevas o actualizadas estén disponibles antes de volver a invocar la URL de
la solicitud.
Asignar parámetros de solicitudes para una API de

API Gateway
En este tutorial, aprenderá a asignar parámetros de solicitudes de métodos a los parámetros de solicitudes
de integración correspondientes para una API de API Gateway. A modo de ejemplo, crearemos una
API con la integración de HTTP y la usaremos para mostrar cómo usar API Gateway para asignar un
parámetro de solicitud de método al parámetro de solicitud de integración correspondiente y para tener
acceso al punto de enlace HTTP accesible públicamente:
http://petstore-demo-endpoint.execute-api.com/petstore/pets
Si copia la URL anterior, péguela en la barra de direcciones de un navegador web y pulse las teclas Enter
o Return; obtendrá el siguiente cuerpo de respuesta con formato JSON:
25
[
{
"id": 1,
"type": "dog",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]
El punto de enlace anterior puede tomar dos parámetros de consulta: type y page. Por ejemplo, si cambia
la URL anterior por la siguiente:
http://petstore-demo-endpoint.execute-api.com/petstore/pets?type=cat&page=2
recibirá la siguiente carga de respuesta con formato JSON, en la que se muestra la segunda página solo
con entradas "cat":
[
{
"id": 4,
"type": "cat",
"price": 999.99
},
{
"id": 5,
"type": "cat",
"price": 249.99
},
{
"id": 6,
"type": "cat",
"price": 49.97
}
]
Este punto de enlace admite también el uso de un ID de elemento, expresado mediante un parámetro de
ruta URL. Por ejemplo, si busca lo siguiente:
http://petstore-demo-endpoint.execute-api.com/petstore/pets/1
Se muestra la siguiente información con formato JSON sobre el elemento con el ID 1:
{
"id": 1,
"type": "dog",
"price": 249.99
}
Además de admitir operaciones GET, este punto de enlace acepta solicitudes POST con una carga. Por
ejemplo, si utiliza Postman para enviar una solicitud de método POST a lo siguiente:
26
http://petstore-demo-endpoint.execute-api.com/petstore/pets
incluyendo el encabezado Content-type: application/json y el siguiente cuerpo de solicitud:
{
"type": "dog",
"price": 249.99
}
recibirá el siguiente objeto JSON en el cuerpo de la respuesta:
{
"pet": {
"type": "dog",
"price": 249.99
},
"message": "success"
}
Estas y otras características se exponen ahora creando una API de API Gateway con la integración HTTP
de este sitio web de PetStore. Las tareas son las siguientes:
• Crear una API con un recurso de https://my-api-id.execute-api.region-id.amazonaws.com/test/

petstorewalkthrough/pets que actúe como un proxy al punto de enlace HTTP de http://petstore-
demo-endpoint.execute-api.com/petstore/pets
• Habilitar la API para aceptar dos parámetros de consulta de la solicitud de método (petType y petsPage),
asignarlos a los parámetros de consulta type y page de la solicitud de integración, respectivamente, y
pasar la solicitud al punto de enlace HTTP
• Admitir un parámetro de ruta {petId} en la URL de solicitud de método de la API para especificar un
ID de elemento, asignarlo al parámetro de ruta {id} de la URL de la solicitud de integración y enviar la
solicitud al punto de enlace HTTP
• Habilitar la solicitud de método para aceptar la carga JSON del formato definido por sitio web del
backend y transmitir la carga sin modificaciones a través de la solicitud de integración al punto de enlace
HTTP del backend.
Temas
• Requisitos previos (p. 27)
• Paso 1: Crear recursos (p. 28)
• Paso 2: Crear y probar los métodos (p. 28)
• Paso 3: Implementar la API (p. 31)
• Paso 4: Probar la API (p. 31)
• Pasos siguientes (p. 33)
Note
Preste atención al uso de mayúsculas y minúsculas en los pasos de este tutorial. El uso de una
letra minúscula en lugar de una letra mayúscula (o viceversa) puede producir errores más tarde
en el tutorial.
Requisitos previos
Antes de empezar este tutorial, debe hacer lo siguiente:
27
1. Realice los pasos de Prepararse para usar API Gateway (p. 6), incluida la asignación del permiso
de acceso de API Gateway al usuario de IAM.
2. Como mínimo, siga los pasos de Cree una API de API Gateway para exponer un punto de enlace
HTTP (p. 8) para crear una nueva API denominada MyDemoAPI en la consola de API Gateway.
Paso 1: Crear recursos

En este paso, creará tres recursos que permitirán a la API interactuar con el punto de enlace HTTP.
Para crear el primer recurso
1. En el panel Resources, seleccione la raíz del recurso, representada por un signo de barra diagonal
inversa (/) y, a continuación, elija Create Resource en el menú desplegable Actions.
2. En Resource Name, escriba petstorewalkthrough.
3. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough y, a continuación, elija
Create Resource.
Para crear el segundo recurso
1. En el panel Resources, elija /petstorewalkthrough y, a continuación, elija Create Resource.

2. En Resource Name, escriba pets.
3. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough/pets y, a continuación,
elija Create Resource.
Para crear el tercer recurso
1. En el panel Resources, elija /petstorewalkthrough/pets y, a continuación, elija Create Resource.

2. En Resource Name, escriba petId. Esto realiza la asignación con el ID de elemento en el punto de
enlace HTTP.
3. En Resource Path, sobrescriba petid con {petId}. Asegúrese de utilizar llaves ({ }) entre petId para
que se muestre /petstorewalkthrough/pets/{petId} y, a continuación, elija Create Resource.
Esto realiza la asignación con /petstore/pets/my-item-id en el punto de enlace HTTP.
Paso 2: Crear y probar los métodos

En este paso, integrará los métodos con los puntos de enlace HTTP del backend, mapeará el parámetro
de la solicitud de método GET a los parámetros de la solicitud de integración correspondientes y, a
continuación, probará los métodos.
Para configurar y probar el primer método GET
Este procedimiento muestra lo siguiente:
• Crear e integrar la solicitud del método GET /petstorewalkthrough/pets con la solicitud de integración
GET http://petstore-demo-endpoint.execute-api.com/petstore/pets
• Asignar los parámetros de consulta de la solicitud del método petType y petsPage a los parámetros de la
cadena de consulta de la solicitud de integración type y page, respectivamente
1. En el panel Resources, elija /petstorewalkthrough/pets, elija Create Method en el menú Actions y, a

continuación, elija GET en /pets en la lista desplegable de nombres de método.
28
2. En el panel /petstorewalkthrough/pets - GET - Setup, elija HTTP for Integration type y elija GET para
HTTP method.
3. En Endpoint URL, escriba http://petstore-demo-endpoint.execute-api.com/petstore/pets.
4. Seleccione Save.
5. En el panel Method Execution, elija Method Request y, a continuación, elija la flecha situada junto a
URL Query String Parameters.
6. Elija Add query string.
7. En Name, escriba petType.
Esto especifica el parámetro de consulta petType en la solicitud del método de la API.

8. Elija el icono de marca de verificación para terminar de crear el parámetro de cadena de consulta de la
URL de solicitud del método.
9. Vuelva a elegir Add query string.
10. En Name, escriba petsPage.
Esto especifica el parámetro de consulta petsPage en la solicitud del método de la API.

URL de solicitud del método.
12. Elija Method Execution, elija Integration Request y, a continuación, elija la flecha situada junto a URL
Query String Parameters.
13. Elimine la entrada petType asignada desde method.request.querystring.petType y la entrada
petsPage asignada desde method.request.querystring.petsPage. Esto es así porque el punto de
enlace espera los parámetros de cadena de consulta type y page para la URL de la solicitud, en lugar
de los valores predeterminados.
14. Elija Add query string.
15. En Name, escriba type. Esto crea los parámetros de cadena de consulta para la URL de la solicitud
de integración.
16. En Mapped from, escriba method.request.querystring.petType.
Esto asigna el parámetro de consulta petType de la solicitud del método al parámetro de consulta
type de la solicitud de integración.
URL de solicitud de integración.
18. Vuelva a elegir Add query string.
19. En Name, escriba page. Esto crea los parámetros de cadena de consulta para la URL de la solicitud
de integración.
20. En Mapped from, escriba method.request.querystring.petsPage.
Esto asigna el parámetro de consulta petsPage de la solicitud del método al parámetro de consulta
page de la solicitud de integración.
URL de solicitud de integración.
22. Elija Method Execution y, en el cuadro Client, elija TEST. En el área Query Strings, para petType,
escriba cat. En petsPage, escriba 2.
23. Elija Test. Si todo sale bien, Response Body mostrará lo siguiente:
[
{
"id": 4,
"type": "cat",
29
"price": 999.99
},
{
"id": 5,
"type": "cat",
"price": 249.99
},
{
"id": 6,
"type": "cat",
"price": 49.97
}
]
Para configurar y probar el segundo método GET
• Crear e integrar la solicitud del método GET /petstorewalkthrough/pets/{petId} con la solicitud de

integración GET http://petstore-demo-endpoint.execute-api.com/petstore/pets/{id}
• Asignar los parámetros de ruta de la solicitud del método de petId a los parámetros de ruta de la
solicitud de integración de id
1. En la lista Resources, elija /petstorewalkthrough/pets/{petId}, elija Create Method en el menú

desplegable Actions y, a continuación, elija GET como el verbo HTTP del método.
2. En el panel Setup, elija HTTP para Integration type y elija GET para HTTP method.
3. En Endpoint URL, escriba http://petstore-demo-endpoint.execute-api.com/petstore/pets/{id}.
4. Seleccione Save.
5. En el panel Method Execution, elija Integration Request y, a continuación, elija la flecha situada junto a
URL Path Parameters.
6. Elija Add path.
7. En Name, escriba id.
8. En Mapped from, escriba method.request.path.petId.
Esto asigna el parámetro de ruta de la solicitud del método de petId al parámetro de ruta de la
solicitud de integración de id.
9. Elija el icono de marca de verificación para terminar de crear el parámetro de ruta URL.
10. Elija Method Execution y, en el cuadro Client, elija TEST. En el área Path, para petId, escriba 1.
{
"id": 1,
"type": "dog",
"price": 249.99
}
Para configurar y probar el método POST
• Crear e integrar la solicitud del método POST /petstorewalkthrough/pets con la solicitud de integración
POST http://petstore-demo-endpoint.execute-api.com/petstore/pets
30
• Pasar la carga JSON de la solicitud del método a través de la carga de la solicitud de integración, sin
ningún tipo de modificación
1. En el panel Resources, elija /petstorewalkthrough/pets, elija Create Method en el menú desplegable

Actions y, a continuación, elija POST como el verbo HTTP del método.
2. En el panel Setup, elija HTTP para Integration type y elija POST para HTTP method.
3. En Endpoint URL, escriba http://petstore-demo-endpoint.execute-api.com/petstore/pets.
4. Seleccione Save.
5. En el panel Method Execution, en el cuadro Client, elija TEST. Amplíe Request Body y, a continuación,
escriba lo siguiente:
{
"type": "dog",
"price": 249.99
}
{
"pet": {
"type": "dog",
"price": 249.99
},
}
Paso 3: Implementar la API

En este paso, implementará la API para que pueda empezar a llamarla fuera de la consola de API
Gateway.
Para implementar la API
1. En el panel Resources, elija Deploy API.

2. En Deployment stage, elija test.
Note
La entrada debe tener texto cifrado UTF-8 (es decir, no localizado).

3. En Deployment description, escriba Calling HTTP endpoint walkthrough.
4. Elija Deploy.
Paso 4: Probar la API

En este paso, saldrá de la consola de API Gateway y utilizará la API para tener acceso al punto de enlace
HTTP.
1. En el panel Stage Editor, junto a Invoke URL, copie la URL en el portapapeles. Debe tener un aspecto
similar al siguiente:
https://my-api-id.execute-api.region-id.amazonaws.com/test
2. Pegue esta URL en el cuadro de direcciones de una nueva pestaña del navegador.
31
3. Añada /petstorewalkthrough/pets para que tenga el siguiente aspecto:
https://my-api-id.execute-api.region-id.amazonaws.com/test/petstorewalkthrough/pets
Desplácese hasta la dirección URL. Se debe mostrar la siguiente información:
[
{
"id": 1,
"type": "dog",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]
4. Detrás de petstorewalkthrough/pets, escriba ?petType=cat&petsPage=2 de forma que tenga el

siguiente aspecto:
https://my-api-id.execute-api.region-id.amazonaws.com/test/petstorewalkthrough/pets?
petType=cat&petsPage=2
5. Desplácese hasta la dirección URL. Se debe mostrar la siguiente información:
[
{
"id": 4,
"type": "cat",
"price": 999.99
},
{
"id": 5,
"type": "cat",
"price": 249.99
},
{
"id": 6,
"type": "cat",
"price": 49.97
}
]
6. Detrás de petstorewalkthrough/pets, sustituya ?petType=cat&petsPage=2 por /1 de forma que

tenga el siguiente aspecto:
https://my-api-id.execute-api.region-id.amazonaws.com/test/petstorewalkthrough/pets/1
{
"id": 1,
"type": "dog",
"price": 249.99
32
Asignar la carga de respuesta
8. Mediante una herramienta de proxy de depuración web o la herramienta de línea de comandos de

cURL, envíe una solicitud de método POST a la URL desde el procedimiento anterior. Asegúrese de
añadir /petstorewalkthrough/pets de forma que tenga el aspecto siguiente:
https://my-api-id.execute-api.region-id.amazonaws.com/test/petstorewalkthrough/pets
Además, asegúrese de añadir el siguiente encabezado:
Content-Type: application/json
Y asegúrese de añadir el siguiente código al cuerpo de la solicitud:
{
"type": "dog",
"price": 249.99
}
Por ejemplo, si utiliza la herramienta de línea de comandos de cURL, ejecute un comando similar al
siguiente:
curl -H "Content-Type: application/json" -X POST -d "{\"type\": \"dog\",

\"price\": 249.99}" https://my-api-id.execute-api.region-id.amazonaws.com/test/
petstorewalkthrough/pets
Debe devolverse la siguiente información en el cuerpo de la respuesta:
{
"pet": {
"type": "dog",
"price": 249.99
},
}
Ha llegado al final de este tutorial.
Pasos siguientes
Tal vez desee comenzar con el próximo tutorial, que le mostrará como usar los modelos y las asignaciones
de API Gateway para transformar la salida de una llamada API de un formato de datos a otro. Consulte
Asignar la carga de respuesta (p. 33).

En este tutorial, aprenderá a usar modelos y plantillas de asignación de API Gateway para transformar
la salida de una llamada API de un esquema de datos a otro. Este tutorial se basa en las instrucciones
y conceptos de Crear una API para exponer una función Lambda (p. 45) y Asignar parámetros de
solicitudes (p. 25). Si aún no ha completado estos tutoriales, le sugerimos que los complete antes.
Este tutorial utilizará API Gateway para obtener datos de ejemplo de un punto de enlace HTTP accesible
públicamente y de una función de AWS Lambda que creará. Tanto el punto de enlace HTTP como la
función Lambda devuelven los mismos datos de ejemplo:
33
[
{
"id": 1,
"type": "dog",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]
Utilizará modelos y plantillas de asignación para transformar estos datos en uno o varios formatos de
salida. En API Gateway, un modelo define el formato, también conocido como el esquema o forma, de
algunos datos. En API Gateway, se usa una plantilla de mapeo para transformar algunos datos de un
formato en otro. Para obtener más información, consulte Crear modelos y plantillas de asignación para las
cargas de solicitud y respuesta (p. 123).
El primer modelo y plantilla de asignación se utiliza para cambiar el nombre de id a number, de type a
class y de price a salesPrice, como se indica a continuación:
[
{
"number": 1,
"class": "dog",
"salesPrice": 249.99
},
{
"number": 2,
"class": "cat",
},
{
"number": 3,
"class": "fish",
"salesPrice": 0.99
}
]
El segundo modelo y plantilla de asignación se utiliza para combinar id y type en description y para
cambiar el nombre de price a askingPrice, tal y como se indica a continuación:
[
{
"description": "Item 1 is a dog.",
"askingPrice": 249.99
},
{
"description": "Item 2 is a cat.",
},
{
"description": "Item 3 is a fish.",
"askingPrice": 0.99
}
34
El tercer modelo y plantilla de asignación se utiliza para combinar id, type y price en un conjunto de
listings, como se indica a continuación:
{
"listings": [
"Item 1 is a dog. The asking price is 249.99.",
"Item 2 is a cat. The asking price is 124.99.",
"Item 3 is a fish. The asking price is 0.99."
]
}
Temas
• Paso 1: Crear Modelos (p. 35)
• Paso 2: Crear recursos (p. 37)
• Paso 3: Crear métodos GET (p. 38)
• Paso 4: creación de una función Lambda (p. 39)
• Paso 5: Configurar y probar los métodos (p. 40)
• Paso 8: Eliminación (p. 45)
Requisitos previos
Antes de empezar este tutorial, debe haber hecho lo siguiente:
1. Realice los pasos de Prepararse para usar API Gateway (p. 6), incluida la asignación del permiso
de acceso de API Gateway a un usuario de IAM.
2. Abra la consola de API Gateway y cree una nueva API denominada MyDemoAPI. Para obtener
más información, consulte Cree una API de API Gateway para exponer un punto de enlace
HTTP (p. 8).
3. Cree dos recursos: petstorewalkthrough y pets. Para obtener más información, consulte Crear
recursos (p. 28) en Asignar parámetros de solicitudes (p. 25).
4. Para utilizar la partes de Lambda de este tutorial, asegúrese de que el usuario de IAM tiene acceso
total para trabajar con Lambda. Puede utilizar la consola de IAM para adjuntar la política administrada
AWSLambdaFullAccess de AWS al usuario de IAM.
5. Asegúrese de que el usuario de IAM tiene acceso para crear políticas y roles en IAM. Si aún no lo ha
hecho, cree un rol de ejecución de Lambda denominado APIGatewayLambdaExecRole en IAM. Para
obtener más información, consulte Crear funciones Lambda (p. 46) en Crear una API para exponer
una función Lambda (p. 45).
Paso 1: Crear Modelos

En este paso, creará cuatro modelos. Los tres primeros modelos representan los formatos de salida de
los datos para su uso con el punto de enlace HTTP y la función Lambda. El último modelo representa el
esquema de entrada de datos para su uso con la función Lambda.
35
Para crear el primer modelo de salida
1. Inicie sesión en la consola de API Gateway en https://console.aws.amazon.com/apigateway.

2. Si se muestra MyDemoAPI, elija Models.
3. Seleccione Create.
4. En Model name, escriba PetsModelNoFlatten.
5. En Content type, escriba application/json.
6. En Model description, escriba Changes id to number, type to class, and price to salesPrice.
7. En Model schema, escriba la siguiente definición compatible con el esquema JSON:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "PetsModelNoFlatten",
"type": "array",
"items": {
"type": "object",
"properties": {
"number": { "type": "integer" },
"class": { "type": "string" },
"salesPrice": { "type": "number" }
}
}
}
8. Seleccione Create model.
Para crear el segundo modelo de salida
2. En Model name, escriba PetsModelFlattenSome.
4. En Model description, escriba Combines id and type into description, and changes price to
askingPrice.
5. En Model schema, escriba lo siguiente:
{
"title": "PetsModelFlattenSome",
"type": "array",
"items": {
"type": "object",
"properties": {
"description": { "type": "string" },
"askingPrice": { "type": "number" }
}
}
}
Para crear el tercer modelo de salida
2. En Model name, escriba PetsModelFlattenAll.
36
4. En Model description, escriba Combines id, type, and price into a set of listings.
{
"title": "PetsModelFlattenAll",
"type": "object",
"properties": {
"listings": {
"type": "array",
"items": {
"type": "string"
}
}
}
}
Para crear el modelo de entrada
2. En Model name, escriba PetsLambdaModel.
4. En Model description, escriba GetPetsInfo model.
{
"title": "PetsLambdaModel",
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "integer" },
"type": { "type": "string" },
"price": { "type": "number" }
}
}
}
Paso 2: Crear recursos

En este paso, creará cuatro recursos. Los tres primeros recursos le permitirán obtener los datos de
ejemplo del punto de enlace HTTP en tres formatos de salida. El último recurso le permitirá obtener los
datos de ejemplo de la función Lambda en el esquema de salida que combina id y type en description y
cambia el nombre de price a askingPrice.
Para crear el primer recurso
1. En la lista de enlaces, elija Resources.

2. En el panel Resources, elija /petstorewalkthrough y, a continuación, elija Create Resource.
3. En Resource Name, escriba NoFlatten.
4. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough/noflatten y, a continuación,
37
Para crear el segundo recurso
1. En el panel Resources, vuelva a elegir /petstorewalkthrough y, a continuación, elija Create Resource.

2. En Resource Name, escriba FlattenSome.
3. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough/flattensome y, a
continuación, elija Create Resource.
Para crear el tercer recurso

2. En Resource Name, escriba FlattenAll.
3. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough/flattenall y, a continuación,
Para crear el cuarto recurso

2. En Resource Name, escriba LambdaFlattenSome.
3. En Resource Path, acepte el valor predeterminado de /petstorewalkthrough/lambdaflattensome y, a
continuación, elija Create Resource.
Paso 3: Crear métodos GET

En este paso, creará un método GET para cada uno de los recursos que ha creado en el paso anterior.
Para crear el primer método GET
1. En la lista Resources, elija /petstorewalkthrough/flattenall y, a continuación, elija Create Method.

2. En la lista desplegable, elija GET y después elija el icono de marca de verificación para guardar la
selección.
3. En el panel Setup, elija HTTP para Integration type y GET para HTTP method, escriba http://
petstore-demo-endpoint.execute-api.com/petstore/pets en Endpoint URL y elija Save.
Para crear el segundo método GET
1. En la lista Resources, elija /petstorewalkthrough/lambdaflattensome y, a continuación, elija Create

Method.
2. En la lista desplegable, elija GET y después elija la marca de verificación para guardar la selección.
3. En el panel Setup, elija Lambda Function para Integration type, elija la región en la que ha creado
la función Lambda GetPetsInfo (p. 39) en la lista desplegable Lambda Region, seleccione
GetPetsInfo para Lambda Function y elija Save. Elija OK cuando se le solicite que añada permiso a la
función Lambda.
Para crear el tercer método GET
1. En la lista Resources, elija /petstorewalkthrough/flattensome y, a continuación, elija Create Method.

selección.
petstore-demo-endpoint.execute-api.com/petstore/pets en Endpoint URL y, a continuación, elija
Save.
38
Para crear el cuarto método GET
1. En la lista Resources, elija /petstorewalkthrough/noflatten y, a continuación, elija Actions, Create

Method.
selección.
petstore-demo-endpoint.execute-api.com/petstore/pets en Endpoint URL y, a continuación, elija
Save.
Paso 4: creación de una función Lambda

En este paso, creará una función Lambda que devuelve los datos de ejemplo.
Para crear la función Lambda
1. Abra la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.

• Si aparece una página de bienvenida, elija Get Started Now.

• Si aparece la página de lista Lambda: Function list, elija Create a Lambda function.
3. En Name, escriba GetPetsInfo.
4. En Description, escriba Gets information about pets.
5. En Code template, elija None.
6. Escriba el código siguiente:
console.log('Loading event');
exports.handler = function(event, context, callback) {

callback(null,
[{"id": 1, "type": "dog", "price": 249.99},
{"id": 2, "type": "cat", "price": 124.99},
{"id": 3, "type": "fish", "price": 0.99}]); // SUCCESS with message
};
Tip
En el código anterior, escrito en Node.js, console.log escribe información en un log de

Amazon CloudWatch. event contiene la entrada a la función Lambda. context contiene
el contexto de llamada. callback devuelve el resultado (para node.js 4.3 y versiones
posteriores). Para obtener más información sobre cómo escribir código de funciones Lambda,
consulte la sección "Programming Model" de AWS Lambda: How it Works y los tutoriales de
ejemplo de la AWS Lambda Developer Guide.
7. En Handler name, deje el valor predeterminado index.handler.
8. En Role, seleccione el rol de ejecución de Lambda, APIGatewayLambdaExecRole, que ha creado en
Crear una API para exponer una función Lambda (p. 45).
9. Elija Create Lambda function.
10. En la lista de funciones, elija GetPetsInfo para mostrar los detalles de la función.
11. Anote la región de AWS en la que creó esta función. La necesitará más adelante.
12. En la lista desplegable, elija Edit or test function.
13. En Sample event, sustituya el código que aparece por lo siguiente:
39
Tip
Las llaves vacías indican que no hay valores de entrada para esta función Lambda. Esta
función simplemente devuelve el objeto JSON que contiene la información de mascotas, por
lo que los pares de clave/valor no son obligatorios aquí.
14. Elija Invoke. Execution result muestra [{"id":1,"type":"dog","price":249.99},
{"id":2,"type":"cat","price":124.99},{"id":3,"type":"fish","price":0.99}], que también se
escribe en los registros de CloudWatch.
15. Elija Go to function list.
Paso 5: Configurar y probar los métodos

En este paso, configurará las respuestas del método, la solicitudes de integración y las solicitudes de
respuesta para especificar los esquemas (o modelos) de datos de entrada y salida para los métodos GET
asociados con el punto de enlace HTTP y la función Lambda. También aprenderá a probar la llamada a
estos métodos utilizando la consola de API Gateway.
Para configurar la integración para el primer método GET y después probarla
1. En el árbol Resources de la API, elija GET en el nodo /petstorewalkthrough/flattenall.

2. En el panel Method Execution, elija Method Response y, a continuación, elija la flecha situada junto a
200.
3. En el área Response Models for 200, para application/json, elija el icono de lápiz para empezar a
configurar el modelo para la salida del método. En Models, elija PetsModelFlattenAll y, a continuación,
elija el icono de marca de verificación para guardar la configuración.
4. Elija Method Execution, Integration Response y, a continuación, la flecha situada junto a 200.
5. Amplíe la sección Body Mapping Templates, elija application/json en Content-Type.
6. En Generate template from model, elija PetsModelFlattenAll para mostrar una plantilla de mapeo
detrás del modelo PetsModelFlattenAll como punto de partida.
7. Modifique el código de la plantilla de asignación de la siguiente manera:
#set($inputRoot = $input.path('$'))
{
"listings" : [
#foreach($elem in $inputRoot)
"Item number $elem.id is a $elem.type. The asking price is
$elem.price."#if($foreach.hasNext),#end
#end
]
}
8. Seleccione Save.
9. Elija Method Execution, en el cuadro Client, elija TEST y, a continuación, elija Test. Si todo sale bien,
Response Body mostrará lo siguiente:
{
"listings" : [
"Item number 1 is a dog. The asking price is 249.99.",
"Item number 2 is a cat. The asking price is 124.99.",
"Item number 3 is a fish. The asking price is 0.99."
]
40
Para configurar la integración para el segundo método GET y después probarla
1. En el árbol Resources de la API, elija GET en el nodo /petstorewalkthrough/lambdaflattensome.

2. En Method Execution, elija Method Response. Y, a continuación, elija la flecha situada junto a 200
para expandir la sección.
3. En el área Response Models for 200, elija el icono de lápiz en la fila del tipo de contenido de
application/json. Elija PetsModelFlattenSome en Models y elija el icono de marca de verificación para
guardar la selección.
4. Vuelva a Method Execution. Elija Integration Response y, a continuación, elija la flecha situada junto a
200.
5. En la sección Body Mapping Templates, elija application/json en Content-Type.
6. En Generate template, elija PetsModelFlattenSome para mostrar la plantilla de script de mapeo para la
salida de este método.
7. Modifique el código como se indica a continuación y, a continuación, elija Save:
[
{
"description" : "Item $elem.id is a $elem.type.",
"askingPrice" : $elem.price
}#if($foreach.hasNext),#end
#end
]
8. Elija Method Execution, en el cuadro Client, elija TEST y, a continuación, elija Test. Si todo sale bien,
Response Body mostrará lo siguiente:
[
{
"description" : "Item 1 is a dog.",
"askingPrice" : 249.99
},
{
"description" : "Item 2 is a cat.",
},
{
"description" : "Item 3 is a fish.",
}
]
Para configurar la integración para el tercer método GET y después probarla
1. En el árbol Resources de la API, elija GET en el nodo /petstorewalkthrough/flattensome.

2. En el panel Method Execution, elija Method Response.
3. Elija la flecha situada junto a 200.
4. En el área Response Models for 200, para application/json, elija el icono de lápiz. En Models, elija
PetsModelFlattenSome y elija el icono de marca de verificación para guardar la selección.
5. Vuelva a Method Execution y elija Integration Response.
6. Elija la flecha situada junto a 200 para expandir la sección.
41
7. Amplíe el área Body Mapping Templates. Elija application/json para Content-Type. En Generate
template, elija PetsModelFlattenSome para mostrar una plantilla de script de mapeo para la salida de
este método.
8. Modifique el código de la siguiente manera:
[
{
"description": "Item $elem.id is a $elem.type.",
"askingPrice": $elem.price
#end
]
9. Seleccione Save.
10. Vuelva a Method Execution y elija TEST en el cuadro Client. Y, a continuación, elija Test. Si todo sale
bien, Response Body mostrará lo siguiente:
[
{
},
{
},
{
"askingPrice": 0.99
}
]
Para configurar la integración para el cuarto método GET y después probarla
1. En el árbol Resources de la API, elija GET en el nodo /petstorewalkthrough/noflatten.

2. En el panel Method Execution, elija Method Response y después amplíe la sección 200.
3. En el área Response Models for 200, para application/json, elija el icono de lápiz para actualizar el
modelo de respuesta de este método.
4. Elija PetsModelNoFlatten como modelo para el tipo de contenido de application/json y, a continuación,
elija el icono de marca de verificación para guardar la selección.
5. Elija Method Execution, Integration Response y, a continuación, la flecha situada junto a 200 para
ampliar la sección.
6. Amplíe la sección Mapping Mapping Templates. Elija application/json para Content-Type. En Generate
templates, elija PetsModelNoFlatten para mostrar una plantilla de script de mapeo para la salida de
este método.
7. Modifique el código de la siguiente manera:
[
{
"number": $elem.id,
"class": "$elem.type",
"salesPrice": $elem.price
42
#end
]
8. Seleccione Save.
9. Vuelva a Method Execution, en el cuadro Client, elija TEST y, a continuación, elija Test. Si todo sale
bien, Response Body mostrará lo siguiente:
[
{
"number": 1,
"class": "dog",
},
{
"number": 2,
"class": "cat",
},
{
"number": 3,
"class": "fish",
"salesPrice": 0.99
}
]

En este paso, implementará la API para que pueda empezar a llamarla fuera de la consola de API
Gateway.

3. En Deployment description, escriba Using models and mapping templates walkthrough.
4. Elija Deploy.

En este paso, saldrá de la consola de API Gateway para interactuar con el punto de enlace HTTP y la
función Lambda.
1. En el panel Stage Editor, junto a Invoke URL, copie la URL en el portapapeles. Debe tener un aspecto
2. Pegue esta URL en el cuadro de direcciones de una nueva pestaña del navegador.
3. Añada /petstorewalkthrough/noflatten para que tenga el siguiente aspecto:
https://my-api-id.execute-api.region-id.amazonaws.com/test/petstorewalkthrough/
noflatten
Desplácese hasta la dirección URL. Se debe mostrar la siguiente información:
43
[
{
"number": 1,
"class": "dog",
},
{
"number": 2,
"class": "cat",
},
{
"number": 3,
"class": "fish",
"salesPrice": 0.99
}
]
4. Detrás de petstorewalkthrough/, reemplace noflatten por flattensome.

[
{
},
{
},
{
"askingPrice": 0.99
}
]
6. Detrás de petstorewalkthrough/, reemplace flattensome por flattenall.

{
"listings" : [
"Item number 1 is a dog. The asking price is 249.99.",
"Item number 2 is a cat. The asking price is 124.99.",
"Item number 3 is a fish. The asking price is 0.99."
]
}
8. Detrás de petstorewalkthrough/, reemplace flattenall por lambdaflattensome.

[
{
"description" : "Item 1 is a dog.",
},
{
"description" : "Item 2 is a cat.",
},
{
"description" : "Item 3 is a fish.",
44
Crear una API para exponer una función Lambda
}
]
Paso 8: Eliminación
Si ya no necesita la función Lambda que ha creado para este tutorial, puede eliminarla ahora. También
puede eliminar los recursos de IAM asociados.
Warning
Si elimina una función Lambda que usan sus API, esas API dejarán de funcionar. La eliminación
de una función Lambda no se puede deshacer. Si desea utilizar la función Lambda de nuevo,
debe volver a crearla.
Si elimina un recurso de IAM que usa una función Lambda, la función Lambda y todas las API
que la utilizan dejarán de funcionar. La eliminación de un recurso de IAM no se puede deshacer.
Si desea utilizar el recurso de IAM de nuevo, debe volver a crearlo. Si tiene previsto continuar
experimentando con los recursos que ha creado para este y el resto de tutoriales, no elimine el rol
de invocación de Lambda ni el rol de ejecución de Lambda.
API Gateway no admite actualmente la desactivación o eliminación de API que ya no funcionan.
Para eliminar la función Lambda
1. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS Lambda en https://
console.aws.amazon.com/lambda/.
2. En la página Lambda: Function list, en la lista de funciones, elija el botón situado junto a GetPetsInfo y,
a continuación, elija Actions, Delete. Cuando se le pregunte, elija Delete otra vez.
Para eliminar los recursos de IAM asociados
1. Abra la consola de IAM, en https://console.aws.amazon.com/iam/.

2. En el área Details, elija Roles.
3. Seleccione APIGatewayLambdaExecRole y, a continuación, elija Role Actions, Delete Role. Cuando
se le pregunte, elija Yes, Delete.
4. En el área Details, elija Policies.
5. Seleccione APIGatewayLambdaExecPolicy y, a continuación, elija Policy Actions, Delete. Cuando se
le pregunte, elija Delete.
Pasos siguientes
Es posible que desee comenzar con el próximo tutorial, que muestra cómo crear una API de API Gateway
para tener acceso a un servicio de AWS. Consulte Crear un servicio de proxy de AWS (p. 67).
Crear una API para exponer una función Lambda

AWS Lambda permite crear backends de una forma sencilla sin administrar servidores. El uso de API
Gateway y Lambda juntos puede resultar muy útil para crear e implementar aplicaciones web sin servidor.
En este tutorial aprenderá a crear funciones Lambda y una API de API Gateway para habilitar un cliente
web que llame a las funciones Lambda de forma sincrónica. Para obtener más información sobre Lambda,
45
Paso 1: Requisitos previos
consulte AWS Lambda Developer Guide. Para obtener información sobre la invocación asincrónica de
funciones Lambda, consulte Crear una API para funciones Lambda (p. 394).
Note
Para crear una función Lambda con el tipo de integración de proxy de Lambda, siga las
instrucciones de Crear una API con la integración de proxy Lambda a través de un Recurso de
proxy (p. 59) y asegúrese de que la función Lambda devuelve la salida de acuerdo con el
formato de salida requerido (p. 123).
Temas
• Paso 1: Requisitos previos (p. 46)
• Paso 2: Crear una API (p. 46)
• Paso 3: Crear un recurso (p. 46)
• Paso 4: Crear funciones Lambda (p. 46)
• Paso 5: Crear y probar un método GET (p. 50)
• Paso 6: Crear y probar un método POST (p. 51)
Paso 1: Requisitos previos

Debe conceder permiso de acceso de API Gateway al usuario de IAM que va a realizar las
tareas que se describen aquí. El usuario de IAM deben tener acceso completo para trabajar con
Lambda. Para ello, puede utilizar o personalizar la política administrada de AWSLambdaFullAccess
(arn:aws:iam::aws:policy/AWSLambdaFullAccess) y adjuntarla al usuario de IAM. Para obtener más
información, consulte Prepararse para usar API Gateway (p. 6). El usuario de IAM también puede
crear políticas y funciones en IAM. Para ello, puede utilizar o personalizar la política administrada de
IAMFullAccess (arn:aws:iam::aws:policy/IAMFullAccess) y adjuntarla al usuario.
Paso 2: Crear una API

En este paso, creará una nueva API denominada MyDemoAPI. Para crear la nueva API, siga las
instrucciones que se indican en el paso 1 de Crear la API paso a paso (p. 16).
Paso 3: Crear un recurso

En este paso, creará un nuevo recurso denominado MyDemoResource. Para crear este recurso, siga las
instrucciones que se indican en el paso 2 de Crear la API paso a paso (p. 16).
Paso 4: Crear funciones Lambda

Note
La creación de funciones Lambda puede producir cargos en su cuenta de AWS.
En este paso, creará dos nuevas funciones Lambda. La primera función Lambda, GetHelloWorld,
registrará la llamada a Amazon CloudWatch y devolverá el objeto JSON {"Hello": "World"}. Para
obtener más información acerca de JSON, consulte Introducing JSON.
46
La segunda función Lambda, GetHelloWithName, obtendrá una entrada ("name"), registrará la llamada a
CloudWatch y devolverá el objeto JSON {"Hello": user-supplied-input-value}. Si no se proporciona
ningún valor de entrada, el valor será "No-Name".
Utilizará la consola de Lambda para crear las funciones Lambda y configurar el rol o la política de
ejecución necesaria. A continuación, usará la consola de API Gateway para crear una API para integrar
los métodos de la API con las funciones Lambda; la consola de API Gateway configurará el rol o la política
de invocación Lambda necesaria. Si configura la API sin usar la consola de API Gateway (por ejemplo, si
importa una API de Swagger), tendrá que crear de forma explícita, si es necesario, y configurar un rol o
política de invocación para que API Gateway invoque las funciones Lambda. Para obtener más información
sobre cómo configurar los roles de ejecución e invocación de Lambda para una API de API Gateway,
consulte Usar permisos de IAM (p. 221). Para obtener más información sobre Lambda, consulte la AWS
Lambda Developer Guide.
Para crear la función Lambda GetHelloWorld
1. Abra la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.

• Si aparece la página de bienvenida, elija Get Started Now.

• Si aparece la página de lista Lambda > Functions, elija Create a Lambda function.
3. En Select blueprint, elija el proyecto hello-world para nodejs. Es posible que tenga que escribir Hello
como filtro de búsqueda para llevar el foco al proyecto.
4. En el panel Configure triggers, seleccione Next.
5. En Name, escriba GetHelloWorld.
6. En Description, escriba Returns {"Hello":"World"}.
7. En Runtime, elija Node.js 4.3.
8. En Lambda function code, sustituya las instrucciones de código predeterminadas en el editor de
código integrado por lo siguiente:
'use strict';

console.log('"Hello":"World"');
callback(null, {"Hello":"World"}); // SUCCESS with message
};
Tip
En el código de la función Lambda anterior en Node.js 4.3, el método console.log escribe

información en un log de Amazon CloudWatch. El parámetro event contiene la entrada a la
función. El parámetro context contiene el contexto de ejecución y la función de devolución
de llamada callback. Para que la función Lambda se ejecute correctamente, llame a
callback(null, result) para salir de la función. Para devolver un mensaje de error, llame a
callback(error) después de salir. Para obtener más información sobre cómo escribir código
de funciones Lambda, consulte la sección "Programming Model" de AWS Lambda: How it
Works y los tutoriales de ejemplo de la AWS Lambda Developer Guide.
9. En Lambda function handler and role, deje el valor predeterminado de index.handler para Handler.
10. En Role, elija Create new role from template(s):
a. En Role name, escriba un nombre para su función (por ejemplo, execute_my_lambda).

b. En Policy templates, elija Simple Microservice permissions.
47
Tip
Para utilizar un rol de IAM existente, elija Choose an existing role para Role y, a
continuación, seleccione una entrada en la lista desplegable de los roles existentes.
También puede crear un rol personalizado eligiendo Create a Custom Role y siguiendo las
instrucciones.
11. En Advanced settings deje los valores predeterminados.
12. Seleccione Next
13. Elija Create function.
Anote la región de AWS en la que creó esta función. La necesitará más adelante.
14. Para probar la nueva función, elija Actions y, a continuación, seleccione Configure test event.
15. En Input test event, sustituya todas las instrucciones de código predeterminadas por lo siguiente y
después elija Save and test.
{ }
Tip
Esta función no utiliza ninguna entrada. Por lo tanto, proporcionamos un objeto JSON vacío
como entrada.
16. Elija Test para invocar la función. La sección Execution result muestra {"Hello": "World"}. La salida
también se escribe en los logs de CloudWatch.
Puede utilizar la consola de IAM para ver el rol de IAM (execute_my_lambda) creado como parte de la
creación de la función Lambda. Asociada a este rol de IAM está la siguiente política integrada que concede
a los usuarios de su cuenta de AWS permiso para llamar a las acciones de CloudWatch CreateLogGroup,
CreateLogStreams y PutLogEvents en cualquiera de los recursos de CloudWatch.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
}
]
}
Una entidad de confianza de este rol de IAM es lambda.amazonaws.com, que tiene la siguiente relación de
confianza:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
48
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
La combinación de esta relación de confianza y la política integrada permite que el usuario invoque la
función Lambda y que Lambda llame a las acciones de CloudWatch admitidas en nombre del usuario.
Para crear la función Lambda GetHelloWithName
1. Vuelva a la lista de Lambda > Functions para crear la siguiente función Lambda, que toma un valor de
entrada.
2. Seleccione Create a Lambda function.
3. En Select blueprint, seleccione el proyecto hello-world para nodejs.
4. Escriba GetHelloWithName en Name.
5. En Description, escriba Returns {"Hello":", a user-provided string, and "}.
6. En Runtime, elija Node.js 4.3.
7. En el editor de código bajo Lambda function code, sustituya las instrucciones de código
predeterminadas por lo siguiente:
'use strict';

var name = (event.name === undefined ? 'No-Name' : event.name);
console.log('"Hello":"' + name + '"');
callback(null, {"Hello":name}); // SUCCESS with message
};
8. En Lambda function handler and role, deje el valor predeterminado de index.handler para Handler.
9. En Role, elija Use existing role y, a continuación, elija el rol execute_my_lambda, creado anteriormente,
en la lista desplegable de roles existentes.
10. Deje los valores predeterminados de Advanced settings. A continuación, elija Next.
11. Elija Create function.
Anote la región de AWS en la que creó esta función. La necesitará más adelante.
12. Para probar esta nueva función, elija Actions y, a continuación, Configure test event.
13. En Input test event, sustituya todas las instrucciones de código predeterminadas por lo siguiente y
después elija Save and test.
{
"name": "User"
}
Tip
La función llama a event.name para leer el nombre de entrada. Esperamos que devuelva
{"Hello": "User"}, de acuerdo con la entrada anterior.
Puede experimentar con esta función eliminando "name": "User" de Input test event para la función
y eligiendo Save and test de nuevo. Debería ver la salida de {"Hello": "No-Name"} bajo Execution
result en la consola de Lambda y en los registros de CloudWatch.
49
Paso 5: Crear y probar un método GET
Paso 5: Crear y probar un método GET

Vuelva a la consola de API Gateway. En este paso, creará un método GET, lo conectará a la función
GetHelloWorld de Lambda y, a continuación, lo probará. El método GET se usa principalmente para
recuperar o leer una representación de un recurso. Si se ejecuta correctamente, el método GET devolverá
un objeto con formato JSON.
Para crear y probar el método GET
1. En la consola de API Gateway, en APIs, elija MyDemoAPI.

2. En el panel Resources, elija /mydemoresource. En Actions, elija Create Method. Elija GET en la lista
desplegable de métodos HTTP y después elija la marca de verificación para crear el método.
3. En el panel Setup del método GET, en Integration type, elija Lambda Function. En Lambda Region,
seleccione la región (por ejemplo, us-east-1) en la que ha creado las funciones Lambda. En Lambda
Function, escriba GetHelloWorld. Elija Save para terminar de configurar la solicitud de integración
para este método.
Para ver una lista de nombres e identificadores de regiones, consulte AWS Lambda en la Referencia
general de Amazon Web Services.
4. En Add Permission to Lambda Function, elija OK.

5. En el panel Method Execution, elija TEST del cuadro Client y, a continuación, elija el botón Test. Si
todo sale bien, Response Body mostrará lo siguiente:
{
"Hello": "World"
}
De forma predeterminada, API Gateway atravesará la solicitud del intermediario de la API. Para la llamada
al método GET que acaba de crear, así como para las llamadas a los métodos HEAD, una función Lambda
recibirá una carga de solicitud JSON vacía de forma predeterminada y después devolverá la carga de
respuesta de la función Lambda sin modificaciones.
En el siguiente paso, creará una llamada al método POST. Para las llamadas a los métodos POST y PUT,
puede pasar un cuerpo de la solicitud en formato JSON, que la función Lambda recibirá como su evento
de entrada. Si lo desea, puede transformar la entrada a la función Lambda mediante el uso de plantillas de
asignación de API Gateway.
50
Paso 6: Crear y probar un método POST
Paso 6: Crear y probar un método POST

En este paso, creará un nuevo método POST, lo conectará a la función GetHelloWithName de Lambda y,
a continuación, lo probará. Si se ejecuta correctamente, el método POST suele devolver el intermediario
del URI del recurso recién creado. En este tutorial, el método POST devolverá simplemente un objeto con
formato JSON.
Para crear y probar el método POST
1. En el panel Resources, elija /mydemoresource y, a continuación, elija Create Method.

2. Para el método HTTP, elija POST y, a continuación, elija la marca de verificación para guardar la
selección.
3. En el panel Setup, en Integration Type, elija Lambda Function.
4. En Lambda Region, seleccione el identificador de región correspondiente al nombre de región en la
que creó la función Lambda GetHelloWithName.
5. En Lambda Function, escriba GetHelloWithName y, a continuación, elija Save.
6. Cuando se le pregunte si desea conceder permiso a API Gateway para invocar su función Lambda,
elija OK.
7. En el panel Method Execution, en el cuadro Client, y, a continuación, elija TEST. Amplíe Request Body
y escriba lo siguiente:
{
"name": "User"
}
{
"Hello": "User"
}
9. Cambie Request Body eliminando "name": "User" de forma que solo quede un conjunto de llaves
({ }) y después elija de nuevo Test. Si todo sale bien, Response Body mostrará lo siguiente:
{
"Hello": "No-Name"
}
La integración de funciones Lambda asistida por la consola de API Gateway usa el tipo de integración de
proxy de servicio de AWS para Lambda. Esto simplifica el proceso de integrar un método de API con una
función Lambda al configurar, entre otras cosas, el URI de invocación de la función Lambda y el rol de
invocación necesarios en nombre del desarrollador de la API.
Los métodos GET y POST aquí descritos se integran con una solicitud POST en el backend:
POST /2015-03-31/functions/FunctionArn/invocations?Qualifier=Qualifier HTTP/1.1

X-Amz-Invocation-Type: RequestReponse
...
Content-Length: PayloadSize
Payload
51
El encabezado X-Amz-Invocation-Type: RequestReponse especifica que la función Lambda

se invoque sincrónicamente. FunctionArn tiene el formato arn:aws:lambda:region:account-
id:function:FunctionName. En este tutorial, la consola establece FunctionName en GetHelloWorld
para la solicitud del método GET y proporciona una carga JSON vacía cuando prueba o invoca el método.
Para el método POST, la consola establece FunctionName en GetHelloWithName y pasa la carga de
solicitud del método suministrada por el intermediario a la solicitud de integración. Puede recuperar el
control total de la creación y configuración de un método obteniendo acceso directamente a la integración
del proxy de servicio de AWS. Para obtener más información, consulte Crear una API para funciones
Lambda (p. 394).

Ahora está listo para implementar la API para que pueda llamarla desde fuera de la consola de API
Gateway. En este paso, creará una etapa. En API Gateway, una etapa define la ruta a través de la cual
se puede tener acceso a la implementación de una API. Por ejemplo, puede definir una etapa test e
implementar su API en ella, de forma que un recurso denominado MyDemoAPI esté accesible a través de un
URI que termine en .../test/MyDemoAPI.
1. Elija la API en el panel APIs o elija un recurso o método en el panel Resources. Elija Deploy API en el
menú desplegable Actions.
2. En Deployment stage, elija New Stage.
3. En Stage name, escriba test.
Note
La entrada debe tener texto cifrado UTF-8 (es decir, no localizado).

4. En Stage description, escriba This is a test.
5. En Deployment description, escriba Calling Lambda functions walkthrough.
6. Elija Deploy.

En este paso, saldrá de la consola de API Gateway para llamar a los métodos GET y POST en la API que
acaba de implementar.
Para probar el método GET-on-mydemoresource
1. En el panel Stage Editor, copie la URL de Invoke URL en el portapapeles. Debe tener un aspecto
2. En una nueva ventana o pestaña del navegador web, pegue la dirección URL en el cuadro de
dirección. Añada la ruta al recurso (/mydemoresource) al final de la URL. La URL debe tener un
aspecto similar al siguiente:
https://my-api-id.execute-api.region-id.amazonaws.com/test/mydemoresource
3. Desplácese hasta esta URL. Si se llama correctamente al método GET, se mostrará la página web:
{"Hello":"World"}
52
Para probar el método POST-on-mydemoresource
1. No podrá probar la solicitud de un método POST en la barra de direcciones del navegador web. En su
lugar, utilice un cliente de API REST avanzado, como Postman o la herramienta de línea de comandos
de cURL.
2. Envíe una solicitud de método POST a la URL del procedimiento anterior. La URL debe tener un
https://my-api-id.execute-api.region-id.amazonaws.com/test/mydemoresource
Asegúrese de añadir a los encabezados de solicitud el siguiente encabezado:
Asegúrese también de añadir el siguiente código al cuerpo de la solicitud:
{
"name": "User"
}
Por ejemplo, si utiliza la herramienta de línea de comandos de cURL, ejecute un comando similar al
siguiente:
curl -H "Content-Type: application/json" -X POST -d "{\"name\": \"User\"}" https://my-

api-id.execute-api.region-id.amazonaws.com/test/mydemoresource
Si se llama correctamente al método POST, la respuesta debe contener:
{"Hello":"User"}
Si ya no necesita las funciones Lambda que ha creado para este tutorial, puede eliminarlas ahora.
También puede eliminar los recursos de IAM asociados.
Warning
Si tiene previsto completar el resto de tutoriales de esta serie, no elimine el rol de ejecución de
Lambda ni el rol de invocación de Lambda. Si elimina una función Lambda que usan sus API,
esas API dejarán de funcionar. La eliminación de una función Lambda no se puede deshacer. Si
desea utilizar la función Lambda de nuevo, debe volver a crearla.
Si elimina un recurso de IAM que usa una función Lambda, esa función Lambda dejará de
funcionar y las API que dependen de esa función tampoco funcionarán. La eliminación de un
recurso de IAM no se puede deshacer. Si desea utilizar el recurso de IAM de nuevo, debe volver a
crearlo.
Para eliminar funciones Lambda
1. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS Lambda en https://
console.aws.amazon.com/lambda/.
2. En la lista de funciones, elija GetHelloWorld, Actions y, a continuación, Delete function. Cuando se le
pregunte, elija Delete otra vez.
53
Pasos siguientes
3. En la lista de funciones, elija GetHelloWithName, Actions y, a continuación, Delete function. Cuando

se le pregunte, elija Delete otra vez.

2. En Details, elija Roles.
3. En la lista de funciones, elija APIGatewayLambdaExecRole, Role Actions y, a continuación, Delete
Role. Cuando se le pregunte, elija Yes, Delete.
4. En Details, elija Policies.
5. En la lista de políticas, elija APIGatewayLambdaExecPolicy, Policy Actions y, a continuación, Delete.
Cuando se le pregunte, elija Delete.
Pasos siguientes
Es posible que desee continuar con el siguiente tutorial, que le muestra cómo asignar parámetros de
encabezado de la solicitud de método a la solicitud de integración y de la respuesta de integración a la
respuesta del método. Utiliza la integración de proxy HTTP para conectar la API a puntos de enlace HTTP
en el backend.
Para obtener más información acerca de API Gateway, consulte ¿Qué es Amazon API Gateway? (p. 1).
Para obtener más información sobre REST, consulte RESTful Web Services: A Tutorial.
Crear una API de API Gateway como un proxy

HTTP o Lambda
Como desarrollador de API, puede configurar un recurso de proxy en una API de API Gateway para
permitir que un cliente acceda a un backend HTTP o llame a una función Lambda que siga diversas rutas
con una única configuración de integración en un método catch-all ANY. Para obtener más información
sobre el recurso de proxy, el método ANY y los tipos de integración de recursos de proxy, consulte
Configuración de la integración del proxy (p. 115).
Este tutorial describe cómo crear y probar dos API con recurso de proxys, uno para un backend
HTTP y el otro para una función Lambda. Para seguir las instrucciones, debe haberse inscrito para
obtener una cuenta de AWS. Para obtener más información sobre la inscripción en AWS, consulte
Introducción (p. 6).
Temas
• Creación y prueba de una API con integración de proxy HTTP (p. 54)
• Crear una API con la integración de proxy Lambda a través de un Recurso de proxy (p. 59)
Creación y prueba de una API con integración de

proxy HTTP
En este tutorial, crearemos una API para integrarla con el sitio web de PetStore a través de un recurso de
proxy mediante la integración de proxy HTTP.
54
Creación y prueba de una API
con integración de proxy HTTP
Temas
• Creación de una API con la integración de proxy HTTP (p. 55)
• Probar una API con la integración de proxy HTTP a través de Recurso de proxy (p. 57)
Creación de una API con la integración de proxy HTTP

El siguiente procedimiento le guiará por los pasos para crear y probar una API con un recurso de proxy
para un backend HTTP mediante la consola de API Gateway. El backend HTTP es el sitio web PetStore
(http://petstore-demo-endpoint.execute-api.com/) de Cree una API de API Gateway para exponer un
punto de enlace HTTP (p. 8).
Para crear una API con la integración de proxy HTTP con el sitio web PetStore a través de un
recurso de proxy

2. Para crear una API, elija Create new API (para crear la primera API) o Create API (para crear las
siguientes). Después, haga lo siguiente:
a. Elija New API.

b. Escriba un nombre en API Name .
c. Opcionalmente, añada una descripción breve en Description.
d. Seleccione Create API.
Para este tutorial, utilice ProxyResourceForPetStore para el nombre de la API.

3. Para crear un recurso secundario, elija un elemento de recurso principal en el árbol Resources y
después elija Create Resource en el menú desplegable Actions. A continuación, haga lo siguiente en
el panel New Child Resource.
a. Seleccione la opción Configure as proxy resource para crear un recurso de proxy. Si no va a

hacerlo, déjelo sin seleccionar.
b. Escriba un nombre en el campo de texto de entrada Resource Name*.
c. Escriba un nombre en el campo de texto de entrada Resource Path*.
d. Elija Create Resource.
e. Seleccione Enable API Gateway CORS, si se requiere.
Para este tutorial, seleccione Configure as proxy resource. En Resource Name, use el valor
predeterminado, proxy. En Resource Path, use /{proxy+}. Seleccione Enable API Gateway CORS.
55
4. Para establecer el método ANY para la integración con el back end HTTP, haga lo siguiente:
a. Elija HTTP Proxy en Integration type.

b. Escriba una URL de recurso de back-end HTTP en Endpoint URL.
c. Elija Save para terminar la configuración del método ANY.
Para este tutorial, utilice http://petstore-demo-endpoint.execute-api.com/{proxy} para Endpoint

URL.
56
Probar una API con la integración de proxy HTTP a través de

Recurso de proxy
En la API que acabamos de crear, la ruta de recurso de proxy de la API {proxy+} se convierte en
el marcador de posición de cualquier punto de enlace del backend bajo http://petstore-demo-
endpoint.execute-api.com/. Por ejemplo, puede ser petstore, petstore/pets y petstore/pets/
{petId}. El método ANY actúa como un marcador de posición para cualquiera de los verbos HTTP
admitidos en tiempo de ejecución. Estos se ilustran en el siguiente procedimiento de prueba.
Para probar una API integrada con el sitio web PetStore utilizando la integración de proxy HTTP a
través de recurso de proxy
1. Para usar la consola API Gateway para probar la llamada a la API, haga lo siguiente.
a. Elija ANY en un recurso de proxy del árbol Resources.

b. Elija Test en el panel Method Execution.
c. En la lista desplegable Method, elija un verbo HTTP que admita el back end.
d. En Path, escriba una ruta específica para recurso de proxy que respalde la operación elegida.
e. Si se requiere, escriba una expresión de consulta admitida para la operación elegida en el
encabezado Query Strings.
f. Si se requiere, escriba una o varias expresiones de encabezado admitidas para la operación
elegida en el encabezado Headers.
g. Si está configurado, establezca los valores de variable de fase requeridos para la operación
elegida en el encabezado Stage Variables.
h. Si se solicita, elija un certificado de cliente generado por API Gateway en el encabezado Client
Certificate para que el back end autentique la operación.
i. Si se solicita, escriba un cuerpo de solicitud adecuado en el editor de texto en el encabezado
Request Body.
j. Elija Test para probar la llamada al método.
Para este tutorial, utilice GET para el método ANY, y utilice petstore/pets en lugar de la ruta de recurso
de proxy ({proxy}) y type=fish para la cadena de consulta.
57
58
Crear una API con la integración de proxy
Lambda a través de un Recurso de proxy
Como que el sitio web del backend es compatible con la solicitud GET /petstore/pets?type=fish, se
devolverá una respuesta correcta similar a la siguiente:
[
{
"id": 1,
"type": "fish",
"price": 249.99
},
{
"id": 2,
"type": "fish",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]
Si intenta llamar a GET /petstore, obtendrá una respuesta 404 con un mensaje de error Cannot
GET /petstore. Esto se debe a que el backend no es compatible con la operación especificada. Por
otro lado, si llama a GET /petstore/pets/1, obtendrá una respuesta 200 OK con la siguiente carga, ya
que la solicitud es compatible con el sitio web PetStore.
{
"id": 1,
"type": "dog",
"price": 249.99
}
2. Para usar un explorador que llame a un método GET en un recurso específico de la API, haga lo
siguiente.
a. Si aún no lo ha hecho, elija Deploy API en el menú desplegable Actions de la API que ha creado.
Siga las instrucciones para implementar la API en un rango específico. Anote la Invoke URL que
se muestra en la página Stage Editor resultante. Esta es la URL base de la API.
b. Para enviar una solicitud GET en un recurso específico, anexe la ruta del recurso, incluyendo
posibles expresiones de cadenas de consulta, al valor Invoke URL obtenido en el paso anterior,
copie la URL completa en la barra de direcciones de un explorador y presione Intro.
En este tutorial, implemente la API en una etapa test y añada petstore/pets?type=fish

a la URL Invoke de la API. Esto produce la URL https://4z9giyi2c1.execute-api.us-
west-2.amazonaws.com/test/petstore/pets?type=fish.
El resultado debe ser el mismo que el resultado que se devuelve cuando utiliza TestInvoke desde la
Crear una API con la integración de proxy Lambda a

través de un Recurso de proxy
Como requisito previo, creamos una función Lambda como el backend de nuestra API a través de la
integración de proxy Lambda con un recurso de proxy. A modo de ilustración, crearemos la siguiente
función de Node.js, denominada LambdaForSimpleProxy, utilizando la consola de AWS Lambda.
59
A continuación, creamos una API con la integración de proxy Lambda mediante la función
LambdaForSimpleProxy a través de un recurso de proxy usando la consola de API Gateway. Por último, le
mostramos cómo probar la API.
Temas
• Una función Lambda en Node.js para la integración de proxy (p. 60)
• Una función Lambda en C# para la integración de proxy (p. 61)
• Una función Lambda en Java para la integración de proxy (p. 61)
• Creación de un backend para la integración de proxy Lambda (p. 63)
• Crear una API con la integración de proxy Lambda (p. 64)
• Probar la API con la integración de proxy Lambda (p. 65)
Una función Lambda en Node.js para la integración de proxy

La siguiente función Lambda en Node.js es una aplicación "Hello, World!" revisiones de. La función
muestra cómo analizar el parámetro event de entrada que contiene una solicitud realizada por un cliente
a un recurso de proxy de API Gateway. Este recurso se integra con la función mediante la integración
de proxy Lambda. La función también muestra cómo formatear la salida de la función Lambda de API
Gateway para devolver los resultados como una respuesta HTTP. Para obtener más información acerca
de los formatos de entrada y salida que este tipo de función Lambda debe seguir, consulte Formato de
entrada de una función Lambda para la integración de proxy (p. 121) y Formato de salida de una función
Lambda para la integración de proxy (p. 123).
'use strict';
console.log('Loading hello world function');

var name = "World";
var responseCode = 200;
console.log("request: " + JSON.stringify(event));
if (event.queryStringParameters !== null && event.queryStringParameters !== undefined)
{
if (event.queryStringParameters.name !== undefined &&
event.queryStringParameters.name !== null && event.queryStringParameters.name !== "") {
console.log("Received name: " + event.queryStringParameters.name);
name = event.queryStringParameters.name;
}
if (event.queryStringParameters.httpStatus !==
undefined && event.queryStringParameters.httpStatus !== null &&
event.queryStringParameters.httpStatus !== "") {
console.log("Received http status: " + event.queryStringParameters.httpStatus);
responseCode = event.queryStringParameters.httpStatus;
}
}
var responseBody = {
message: "Hello " + name + "!",
input: event
};
var response = {
statusCode: responseCode,
headers: {
"x-custom-header" : "my custom header value"
},
body: JSON.stringify(responseBody)
};
console.log("response: " + JSON.stringify(response))
callback(null, response);
60
};
Cuando se utiliza con un recurso de proxy en API Gateway, el parámetro de entrada event contiene
una solicitud de API serializada como un objeto JSON por API Gateway. Esta entrada puede incluir el
método HTTP de la solicitud (httpMethod), la ruta (path y pathParameters), los parámetros de consulta
(queryStringParameters), los encabezados (headers), la carga aplicable (body), así como el contexto
(requestContext) y las variables de etapa (stageVariables).
Esta función Lambda de ejemplo analiza el parámetro event para recuperar los parámetros de la cadena
de consulta name y httpStatus.
La función devuelve a continuación un saludo al usuario designado en la propiedad message del objeto
responseBody. Para mostrar los detalles de la solicitud entrante serializada por API Gateway, la función
también devuelve el objeto event de entrada como la propiedad input del cuerpo de la respuesta.
Por último, al salir, la función devuelve un objeto JSON, que contiene el elemento statusCode necesario
y todos los elementos headers y body aplicables para API Gateway, para devolverlo como una respuesta
HTTP al cliente.
Una función Lambda en C# para la integración de proxy

Consulte la explicación de Authoring Lambda Functions in C# para crear un controlador de funciones
Lambda C# y ampliar el flujo de programación que se muestra en la siguiente función Lambda Java.
Una función Lambda en Java para la integración de proxy

La siguiente función Lambda en Java es una aplicación "Hello, World!" similar a su homóloga (p. 60) en
Node.js. La función muestra cómo analizar el evento de entrada que se pasa como un objeto InputStream
y que contiene una solicitud realizada por un cliente a un recurso de proxy de API Gateway. Este recurso
se integra con la función mediante la integración de proxy Lambda. También muestra cómo analizar el
objeto context para obtener LambdaLogger. El ejemplo muestra también cómo formatear la salida de
la función Lambda de API Gateway en Java para devolver los resultados en un objeto OutputStream
como una respuesta HTTP. Para obtener más información sobre los formatos de entrada y salida de la
integración de proxy Lambda, consulte Formato de entrada de una función Lambda para la integración de
proxy (p. 121) y Formato de salida de una función Lambda para la integración de proxy (p. 123).
package examples;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.BufferedReader;
import java.io.Writer;
import com.amazonaws.services.lambda.runtime.RequestStreamHandler;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import org.json.simple.JSONObject;
import org.json.simple.JSONArray;
import org.json.simple.parser.ParseException;
import org.json.simple.parser.JSONParser;
public class ProxyWithStream implements RequestStreamHandler {
61
JSONParser parser = new JSONParser();
public void handleRequest(InputStream inputStream, OutputStream outputStream, Context

context) throws IOException {
LambdaLogger logger = context.getLogger();

logger.log("Loading Java Lambda handler of ProxyWithStream");
BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));

JSONObject responseJson = new JSONObject();
String name = "World";
String responseCode = "200";
try {
JSONObject event = (JSONObject)parser.parse(reader);
if (event.get("queryStringParameters") != null) {
JSONObject qps = (JSONObject)event.get("queryStringParameters");
if ( qps.get("name") != null) {
name = (String)qps.get("name");
}
if (qps.get("httpStatus") != null) {
responseCode = qps.get("httpStatus").toString();
}
}
JSONObject responseBody = new JSONObject();

responseBody.put("input", event.toJSONString());
responseBody.put("message", "Hello " + name + "!");
JSONObject headerJson = new JSONObject();

headerJson.put("x-custom-response-header", "my custom response header value");
responseJson.put("statusCode", responseCode);
responseJson.put("headers", headerJson);
responseJson.put("body", responseBody.toString());
} catch(ParseException pex) {
responseJson.put("statusCode", "400");
responseJson.put("exception", pex);
}
logger.log(responseJson.toJSONString());
OutputStreamWriter writer = new OutputStreamWriter(outputStream, "UTF-8");
writer.write(responseJson.toJSONString());
writer.close();
}
}
Cuando se utiliza con un recurso de proxy en API Gateway, la secuencia de entrada contiene una
solicitud API serializada como una cadena JSON por API Gateway. Los datos de entrada pueden
incluir el método HTTP de la solicitud (httpMethod), la ruta (path y pathParameters), los parámetros de
consulta (queryStringParameters), los encabezados (headers), la carga aplicable (body), el contexto
(requestContext) y las variables de etapa (stageVariables).
Esta función Lambda de ejemplo analiza el parámetro inputStream para recuperar los parámetros de
la cadena de consulta name y httpStatus. Para el registro, recupera el objeto LambdaLogger del objeto
context de entrada.
La función devuelve a continuación un saludo al usuario designado en la propiedad message del objeto
responseBody. Para mostrar los detalles de la solicitud entrante serializada por API Gateway, la función
también devuelve los datos de entrada (event) en el cuerpo de la respuesta.
62
Por último, al salir, la función devuelve una cadena JSON, que contiene el elemento statusCode necesario
y todos los elementos headers y body aplicables para API Gateway, para devolverlo como una respuesta
HTTP al cliente.
Para crear esta función en la consola de Lambda, debe crear un paquete de implementación antes de
cargar el paquete en Lambda. Para crear un paquete de implementación, siga estas instrucciones.
Creación de un backend para la integración de proxy Lambda

Ahora vamos a crear la función Lambda en API Gateway utilizando la consola de Lambda.
Crear una función Lambda para una API con un recurso de proxy en la consola de Lambda
1. Inicie sesión en la consola de Lambda en https://console.aws.amazon.com/lambda.

2. En la esquina superior derecha, elija una región disponible para la función Lambda.
3. En el panel de navegación principal, elija Functions.
4. Elija uno de los siguientes procedimientos para crear una función Lambda en Node.js o Java. Puede
adaptar las instrucciones para otros lenguajes y plataformas.
a. Para crear la función Node.js Lambda, elija Create a Lambda function o Get Started Now para
crear la primera función de Lambda en una región y después haga lo siguiente.
i. En la página Select blueprint, elija Skip.

ii. En la página Configure triggers, elija Next.
iii. En la página Configure function, haga lo siguiente:
- Escriba un nombre de función en el campo de entrada Name.
- Escriba una descripción breve de la función en el campo de entrada Description.
- En la lista desplegable Runtime, elija Node.js 4.3.

iv. En Lambda function code, haga lo siguiente:
- Elija Edit code inline en la lista desplegable Code entry type.
- Escriba o copie el código de Node.js en el editor de código.

v. En Lambda function handler and role, haga lo siguiente:
- Deje index.handler como está para Handler.
- Elija un rol de IAM o cree uno nuevo para la ejecución de la función.

vi. Mantenga los valores predeterminados de Advanced settings.
vii. Seleccione Next.
viii. En el panel Review, seleccione Create function.
Para este tutorial, utilice LambdaForSimpleProxy (p. 60) como el nombre de la función y elija
las plantillas de política Simple Microservice permissions estándar para crear el rol de ejecución
de Lambda necesario.
b. Para crear una función Java Lambda, elija Create a Lambda function o Get Started Now para
crear la primera función de Lambda en una región y después haga lo siguiente.
i. En la página Select blueprint, elija Skip.

ii. En la página Configure triggers, elija Next.
iii. En la página Configure function, haga lo siguiente:
- Escriba un nombre de función en el campo de entrada Name.
63
- Escriba una descripción breve de la función en el campo de entrada Description.
- En la lista desplegable Runtime, elija Java 8.

iv. En Lambda function code, haga lo siguiente:
- Elija un Code entry type para cargar un paquete de implementación de una unidad local o
Amazon S3.
- Elija Upload junto a Function package.
- Navegue hasta la ubicación del paquete de implementación y selecciónelo.

v. En Lambda function handler and role, haga lo siguiente:
- Escriba el controlador de función del formato package_name.function_name::method_name

en Handler.
- Elija un rol de IAM o cree uno nuevo para la ejecución de la función.

vi. Mantenga los valores predeterminados de Advanced settings.
vii. Seleccione Next.
viii. En el panel Review, seleccione Create function.
Para este tutorial, utilice examples como el nombre del paquete de Java, utilice
ProxyWithStreams (p. 61) como el nombre de clase Java, utilice handleRequest como el
nombre de la función Java y utilice examples.ProxyWithStreams::handleRequest como el
nombre del controlador de la función Lambda. Elija las plantillas de política Simple Microservice
permissions estándar para crear el rol de ejecución de Lambda necesario.
Note
Anote la región en la que ha creado la función Lambda. La necesitará cuando cree la API para la
función.
Crear una API con la integración de proxy Lambda

Ahora cree una API con un recurso de proxy para una función Lambda mediante la consola de API
Gateway.
Crear una API con un recurso de proxy para una función Lambda

2. Para crear una API, elija Create new API (para crear la primera API) o Create API (para crear las
siguientes). Después, haga lo siguiente:
a. Elija New API.

b. Escriba un nombre en API Name .
c. Opcionalmente, añada una descripción breve en Description.
d. Seleccione Create API.
Para este tutorial, utilice LambdaSimpleProxy como el nombre de la API.

3. Para crear un recurso secundario, elija un elemento de recurso principal en el árbol Resources y
después elija Create Resource en el menú desplegable Actions. A continuación, haga lo siguiente en
el panel New Child Resource.
64
a. Seleccione la opción Configure as proxy resource para crear un recurso de proxy. Si no va a

hacerlo, déjelo sin seleccionar.
b. Escriba un nombre en el campo de texto de entrada Resource Name*.
c. Escriba un nombre en el campo de texto de entrada Resource Path*.
d. Elija Create Resource.
e. Seleccione Enable API Gateway CORS, si se requiere.
Para este tutorial, utilice el recurso de raíz (/) como el recurso principal. Seleccione Configure as
proxy resource. En Resource Name, use el valor predeterminado, proxy. En Resource Path, use /
{proxy+}. Anule la selección de Enable API Gateway CORS.
4. Para establecer el método ANY para la integración con el back end Lambda, haga lo siguiente:
a. Elija Lambda Function Proxy en Integration type.

b. Elija una región de Lambda Region.
c. Escriba el nombre de su función Lambda en Lambda Function.
d. Seleccione Save.
e. Elija Aceptar cuando se le solicite Add Permission to Lambda Function.
Para este tutorial, utilice el recurso LambdaForSimpleProxy (p. 60) creado previamente para
Lambda Function.
En el caso de la API de recurso de proxy que Lambda acaba de crear, API Gateway reenvía la solicitud sin
procesar desde el cliente al backend para que la procese la función Lambda. La solicitud incluye el método
de solicitud, su ruta, la cadena de consulta y los parámetros de encabezado, cualquier carga y el contexto
y las variables de etapa. El procedimiento siguiente describe cómo probar esto.
Probar la API con la integración de proxy Lambda

El siguiente procedimiento describe cómo probar la integración de proxy.
Llamar a la función Lambda LambdaForSimpleProxy (p. 60) a través del recurso de proxy
1. Para usar un explorador que llame a un método GET en un recurso específico de la API, haga lo
siguiente.
a. Si aún no lo ha hecho, elija Deploy API en el menú desplegable Actions de la API que ha creado.
Siga las instrucciones para implementar la API en un rango específico. Anote la Invoke URL que
se muestra en la página Stage Editor resultante. Esta es la URL base de la API.
b. Para enviar una solicitud GET en un recurso específico, anexe la ruta del recurso, incluyendo
posibles expresiones de cadenas de consulta, al valor Invoke URL obtenido en el paso anterior,
copie la URL completa en la barra de direcciones de un explorador y presione Intro.
En este tutorial, implemente la API en una etapa test y añada hello?name=me a la URL de la API para
producir la URL https://wt6mne2s9k.execute-api.us-west-2.amazonaws.com/test/hello?name=me.
La respuesta correcta devuelve un resultado similar al siguiente desde la función Lambda del
backend. La propiedad input captura la solicitud sin procesar de API Gateway. La respuesta
contiene httpMethod, path, headers, pathParameters, queryStringParameters, requestContext y
stageVariables.
{
"message": "Hello me!",
65
"input": {
"path": "/test/hello",
"headers": {
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/
webp,*/*;q=0.8",
"Accept-Encoding": "gzip, deflate, lzma, sdch, br",
"Accept-Language": "en-US,en;q=0.8",
"CloudFront-Forwarded-Proto": "https",
"CloudFront-Is-Desktop-Viewer": "true",
"CloudFront-Is-Mobile-Viewer": "false",
"CloudFront-Is-SmartTV-Viewer": "false",
"CloudFront-Is-Tablet-Viewer": "false",
"CloudFront-Viewer-Country": "US",
"Host": "wt6mne2s9k.execute-api.us-west-2.amazonaws.com",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
OPR/39.0.2256.48",
"Via": "1.1 fb7cca60f0ecd82ce07790c9c5eef16c.cloudfront.net (CloudFront)",
"X-Amz-Cf-Id": "nBsWBOrSHMgnaROZJK1wGCZ9PcRcSpq_oSXZNQwQ10OTZL4cimZo3g==",
"X-Forwarded-For": "192.168.100.1, 192.168.1.1",
"X-Forwarded-Port": "443",
"X-Forwarded-Proto": "https"
},
"pathParameters": {"proxy": "hello"},
"requestContext": {
"accountId": "123456789012",
"resourceId": "us4z18",
"stage": "test",
"requestId": "41b45ea3-70b5-11e6-b7bd-69b5aaebc7d9",
"identity": {
"cognitoIdentityPoolId": "",
"accountId": "",
"cognitoIdentityId": "",
"caller": "",
"apiKey": "",
"sourceIp": "192.168.100.1",
"cognitoAuthenticationType": "",
"cognitoAuthenticationProvider": "",
"userArn": "",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
OPR/39.0.2256.48",
"user": ""
},
"resourcePath": "/{proxy+}",
"httpMethod": "GET",
"apiId": "wt6mne2s9k"
},
"resource": "/{proxy+}",
"queryStringParameters": {"name": "me"},
"stageVariables": {"stageVarName": "stageVarValue"}
}
}
Note
requestContext es un mapa de pares de clave-valor y se corresponde con la variable

$context (p. 158). Su resultado depende de la API. API Gateway puede añadir nuevas
claves al mapa. Para obtener más información, consulte Formato de entrada de una función
Lambda para la integración de proxy (p. 121).
66
Crear un servicio de proxy de AWS
Puede utilizar otra ruta de recurso de proxy diferente de /hello/world?name=me para llamar a la
función Lambda. El valor de la propiedad input.path de la carga JSON de la respuesta correcta será
test/hello/world.
Si utiliza POST para el método ANY en su lugar, la propiedad input de la carga de respuesta contiene
una propiedad JSON body. Para probar una solicitud POST, puede utilizar la característica TestInvoke
de la consola de API Gateway, un comando Curl, la extensión Postman o un SDK de AWS.
2. Para usar la consola API Gateway para probar la llamada a la API, haga lo siguiente.
a. Elija ANY en un recurso de proxy del árbol Resources.

b. Elija Test en el panel Method Execution.
c. En la lista desplegable Method, elija un verbo HTTP que admita el back end.
d. En Path, escriba una ruta específica para recurso de proxy que respalde la operación elegida.
e. Si se requiere, escriba una expresión de consulta admitida para la operación elegida en el
encabezado Query Strings.
f. Si se requiere, escriba una o varias expresiones de encabezado admitidas para la operación
elegida en el encabezado Headers.
g. Si está configurado, establezca los valores de variable de fase requeridos para la operación
elegida en el encabezado Stage Variables.
h. Si se solicita, elija un certificado de cliente generado por API Gateway en el encabezado Client
Certificate para que el back end autentique la operación.
i. Si se solicita, escriba un cuerpo de solicitud adecuado en el editor de texto en el encabezado
Request Body.
j. Elija Test para probar la llamada al método.
Para este tutorial, utilice GET como el método HTTP, hello como la ruta de recurso de proxy {proxy} y
name=me como la expresión de consulta.
La respuesta correcta devolverá una carga JSON similar a la carga mostrada en el paso anterior.
Crear un servicio de proxy de AWS para Amazon

SNS
Además de exponer funciones Lambda o puntos de enlace HTTP, también puede crear una API de
API Gateway como un proxy a un servicio de AWS, como Amazon SNS, Amazon S3 o Kinesis, lo que
permite a su cliente tener acceso a los servicios de AWS del backend a través de las API. En este tutorial,
ilustraremos esto creando una API para exponer Amazon SNS. Para ver ejemplos de integración de una
API con otros servicios de AWS, consulte Ejemplos y tutoriales (p. 394).
Un proxy de servicio de AWS puede llamar a una única acción en un servicio de AWS y esa acción
normalmente no cambia. Si desea más flexibilidad, debe llamar a una función Lambda en su lugar.
API Gateway no reintenta las operaciones cuando se agota el tiempo de espera del punto de enlace. El
intermediario de la API debe implementar una lógica de reintentos para administrar los tiempos de espera
del punto de enlace.
Este tutorial se basa en las instrucciones y conceptos de Crear una API para exponer una función
Lambda (p. 45), que muestran cómo utilizar API Gateway para crear una API personalizada, conectarla
a un conjunto de funciones AWS Lambda y después llamar a las funciones Lambda desde la API. Si aún
no ha completado ese tutorial, le sugerimos que lo haga primero.
Temas
67
Requisitos previos

• Paso 1: Crear el recurso (p. 68)
• Paso 2: Crear el método GET (p. 68)
• Paso 3: Crear el rol de ejecución del proxy de servicio de AWS (p. 69)
• Paso 4: Especificar la configuración del método y probar el método (p. 70)
Requisitos previos
Antes de empezar este tutorial, debe haber hecho lo siguiente:
1. Realice los pasos que se indican en Prepararse para usar API Gateway (p. 6).
2. Asegúrese de que el usuario de IAM tiene acceso para crear políticas y roles en IAM. Tendrá que
crear una política y un rol de IAM en este tutorial.
3. Como mínimo, abra la consola de API Gateway y cree una nueva API denominada MyDemoAPI. Para
obtener más información, consulte Cree una API de API Gateway para exponer un punto de enlace
HTTP (p. 8).
4. Implemente la API al menos una vez en una etapa denominada test. Para obtener más información,
consulte Implementar la API (p. 52) en Crear una API para exponer una función Lambda (p. 45).
5. Realice el resto de los pasos de Crear una API para exponer una función Lambda (p. 45).
6. Cree al menos un tema en Amazon Simple Notification Service (Amazon SNS). Utilizará la API
implementada para obtener una lista de temas de Amazon SNS asociados a su cuenta de AWS. Para
obtener información sobre cómo crear un tema en Amazon SNS, consulte Create a Topic. (No es
necesario que copie el ARN del tema mencionado en el paso 5).
Paso 1: Crear el recurso

En este paso, creará un recurso que permitirá al proxy de servicio de AWS interactuar con el servicio de
AWS.
Para crear el recurso

2. Si se muestra MyDemoAPI, elija Resources.
3. En el panel Resources, elija el recurso raíz, representado por una barra diagonal (/), y elija Create
Resource.
4. En Resource Name, escriba MyDemoAWSProxy y, a continuación, elija Create Resource.
Paso 2: Crear el método GET

En este paso, creará un método GET que permitirá al proxy de servicio de AWS interactuar con el servicio
de AWS.
Para crear el método GET
1. En el panel Resources, elija /mydemoawsproxy y, a continuación, elija Create Method.
68
Paso 3: Crear el rol de ejecución
del proxy de servicio de AWS
2. Para el método HTTP, elija GET y guarde la selección.
Paso 3: Crear el rol de ejecución del proxy de servicio

de AWS
En este paso, creará un rol de AWS que usará el proxy de servicio de IAM para interactuar con el servicio
de AWS. Llamaremos a este rol de IAM "rol de ejecución del proxy de servicio de AWS". Sin este rol,
API Gateway no puede interactuar con el servicio de AWS. Más adelante, especificará este rol en la
configuración del método GET que acaba de crear.
Para crear el rol de ejecución del proxy de servicio de AWS y su política
1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en https://

console.aws.amazon.com/iam/.
2. Elija Policies.
• Si aparece la página Welcome to Managed Policies, elija Get Started y, a continuación, elija Create
Policy.
• Si aparece una lista de políticas, elija Create Policy.
4. Junto a Create Your Own Policy, seleccione Select.
5. En Policy Name, escriba un nombre para la política (por ejemplo, APIGatewayAWSProxyExecPolicy).
6. En Description, escriba Enables API Gateway to call AWS services.
7. En Policy Document, escriba lo siguiente y, a continuación, elija Create Policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"sns:ListTopics"
]
}
]
}
Note
Este documento de política permite el intermediario obtener una lista de los temas de
Amazon SNS para la cuenta de AWS.
8. Elija Roles.
9. Elija Create New Role.
10. En Role Name, escriba un nombre para el rol de ejecución (por ejemplo,
APIGatewayAWSProxyExecRole) y, a continuación, elija Next Step.
11. Junto a Amazon EC2, elija Select.
Note
Aquí elige Select, porque debe elegir una instrucción de rol de servicio de AWS estándar para
poder continuar. Actualmente no existe la posibilidad de seleccionar una instrucción de rol de
69
Paso 4: Especificar la configuración
del método y probar el método
servicio de API Gateway estándar. Más adelante en este paso, modificará la instrucción del
rol de servicio de Amazon EC2 estándar para usarla con API Gateway.
12. En la lista de políticas, seleccione APIGatewayAWSProxyExecPolicy y, a continuación, elija Next Step.
13. En Role ARN, anote el nombre de recurso de Amazon (ARN) del rol de ejecución. Lo necesitará
más adelante. El ARN debe tener un aspecto similar a: arn:aws:iam::123456789012:role/
APIGatewayAWSProxyExecRole, donde 123456789012 es el ID de su cuenta de AWS.
14. Elija Create Role.
El rol de invocación de IAM que acaba de crear permite a Amazon EC2 obtener una lista de los temas
Amazon SNS de la cuenta de AWS. Cambiará este rol para que API Gateway pueda obtener una lista
de los temas Amazon SNS de la cuenta de AWS en su lugar.
15. En la lista de roles, seleccione APIGatewayAWSProxyExecRole.
16. En el área Trust Relationships, elija Edit Trust Relationship.
17. En Policy Document, sustituya ec2.amazonaws.com por apigateway.amazonaws.com para que el
documento de la política de control de acceso tenga el siguiente aspecto:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
}
]
}
Este documento de política permite a API Gateway realizar acciones en nombre de su cuenta de
AWS.
18. Elija Update Trust Policy.
Paso 4: Especificar la configuración del método y

probar el método
En este paso, especificará la configuración para el método GET, de forma que pueda interactuar con un
servicio de AWS a través de un proxy de servicio de AWS. A continuación, probará el método.
Para especificar la configuración del método GET y después probarlo
1. En la consola de API Gateway, en el panel Resources de la API denominada MyDemoAPI, en /

mydemoawsproxy, elija GET.
2. En el panel Setup, en Integration type, elija Show advanced y, a continuación, elija AWS Service
Proxy.
3. En AWS Region, seleccione el nombre de la región de AWS donde desea obtener los temas de
Amazon SNS.
4. En AWS Service, elija SNS.
5. En HTTP method, elija GET.
6. En Action, escriba ListTopics.
7. En Execution Role, escriba el ARN del rol de ejecución.
70
8. Deje Path Override en blanco.

9. Seleccione Save.
10. En el panel Method Execution, en el cuadro Client, elija TEST y, a continuación, elija Test. Si todo sale
bien, Response Body mostrará una respuesta parecida a la siguiente:
{
"ListTopicsResponse": {
"ListTopicsResult": {
"NextToken": null,
"Topics": [
{
"TopicArn": "arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-1"
},
{
"TopicArn": "arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-2"
},
...
{
"TopicArn": "arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-N"
}
]
},
"ResponseMetadata": {
"RequestId": "abc1de23-45fa-6789-b0c1-d2e345fa6b78"
}
}
}

En este paso, implementará la API para que pueda empezar a llamarla desde fuera de la consola de API
Gateway.

3. En Deployment description, escriba Calling AWS service proxy walkthrough.
4. Elija Deploy.

En este paso, saldrá de la consola de API Gateway y usará el proxy de servicio de AWS para interactuar
con el servicio Amazon SNS.
1. En el panel Stage Editor, junto a Invoke URL, copie la URL en el portapapeles. Debería tener un
2. Pegue la URL en el cuadro de direcciones de una nueva pestaña del navegador.

3. Añada /mydemoawsproxy para que tenga el siguiente aspecto:
https://my-api-id.execute-api.region-id.amazonaws.com/test/mydemoawsproxy
71
Desplácese hasta la dirección URL. Se debe mostrar información similar a la siguiente:
{"ListTopicsResponse":{"ListTopicsResult":{"NextToken": null,"Topics":
[{"TopicArn": "arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-1"},{"TopicArn":
"arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-2"},...{"TopicArn":
"arn:aws:sns:us-east-1:80398EXAMPLE:MySNSTopic-N}]},"ResponseMetadata":
{"RequestId":"abc1de23-45fa-6789-b0c1-d2e345fa6b78}}}
Puede eliminar los recursos de IAM que el proxy de servicio de AWS necesita para funcionar.
Warning
Si elimina un recurso de IAM que utiliza un proxy de servicio de AWS, ese proxy de servicio de
AWS y todas las API que lo utilicen dejarán de funcionar. La eliminación de un recurso de IAM no
se puede deshacer. Si desea utilizar el recurso de IAM de nuevo, debe volver a crearlo.

2. En el área Details, haga clic en Roles.
3. Seleccione APIGatewayAWSProxyExecRole y, a continuación, elija Role Actions, Delete Role.
Cuando se le pregunte, elija Yes, Delete.
4. En el área Details, elija Policies.
5. Seleccione APIGatewayAWSProxyExecPolicy y, a continuación, elija Policy Actions, Delete. Cuando
se le pregunte, elija Delete.
Ha llegado al final de este tutorial. Para obtener más detalles sobre la creación de una API con un proxy
de servicio de AWS, consulte Crear una API como un proxy de Amazon S3 (p. 413), Crear una API para
funciones Lambda (p. 394) o Crear una API como un proxy de Amazon Kinesis (p. 439).
72
Crear una API sencilla
Crear una API en Amazon API

Gateway
En general, la creación de una API en API Gateway implica los siguientes pasos:
1. Crear una instancia de RestApi.

2. Añadir todos los objetos Resource secundarios, si es necesario, al recurso raíz (/).
3. Añadir una instancia de Method para representar un método orientado al cliente en la entidad Resource.
4. Configurar el método Integration para reenviar la solicitud del método al backend integrado y para
dirigir la respuesta del backend al método.
Para ayudar a sus clientes a comprender su API, puede proporcionar documentación para la API, cuando
la cree. Para ello, añada un recurso DocumentationPart para una entidad de API compatible.
Para controlar la forma en que los clientes llaman a una API, puede solicitar credenciales de AWS,
utilizando un autorizador personalizado o un conjunto de usuarios de Amazon Cognito. Para medir el uso
de la API, configure usage plans para limitar las solicitudes a la API.
Temas
• Crear una API sencilla en API Gateway (p. 73)
• Configurar un método y una integración de API de API Gateway (p. 83)
• Crear modelos y plantillas de asignación para las asignaciones de solicitud y respuesta (p. 123)
• Asignación de datos de solicitud y respuesta de API de Amazon API Gateway (p. 147)
• Funciones y variables integradas en la plantilla de asignación de API Gateway (p. 158)
• Habilitar la validación básica de solicitudes para una API en API Gateway (p. 165)
• Documentar una API de API Gateway (p. 177)
• Importar una API en API Gateway (p. 217)
• Controlar el acceso en API Gateway (p. 221)
• Mantener una API en Amazon API Gateway (p. 291)
Crear una API sencilla en API Gateway

Para fines ilustrativos, utilizaremos una API PetStore simplificada que expone únicamente el método
GET /. Este método se integra con el punto de enlace http://petstore-demo-endpoint.execute-
73
Crear una API mediante la consola de API Gateway
api.com/petstore/pets y administra las respuestas 200 OK. La explicación se centra en las tareas de
programación esenciales para crear una API en API Gateway, usando la configuración predeterminada. En
otras partes de este capítulo se explican detalles más complejos de la creación de una API.
Temas
• Crear una API mediante la consola de API Gateway (p. 74)
• Crear una API mediante el SDK de API Gateway para AWS (p. 74)
• Crear una API con la API REST de API Gateway (p. 74)
• Crear una API con comandos de la AWS CLI (p. 79)
• Crear una API importando definiciones de Swagger (p. 81)
Crear una API mediante la consola de API Gateway

Para crear una API de API Gateway mediante la consola de API Gateway, consulte Cree una API de API
Gateway para exponer un punto de enlace HTTP (p. 8).
Puede obtener información sobre cómo crear una API siguiendo un ejemplo. Para obtener más
información, consulte Crear una API de API Gateway a partir de un ejemplo (p. 9).
También puede crear una API a través de la característica Import API (p. 217) de API Gateway para
cargar una definición de la API externa, como la expresada en Swagger 2.0 con Extensiones de API
Gateway para Swagger (p. 373). En el ejemplo proporcionado en Crear una API de API Gateway a partir
de un ejemplo (p. 9) se utiliza la característica Import API.
Crear una API mediante el SDK de API Gateway para

AWS
Para obtener más información sobre el uso de un SDK de AWS, consulte SDK de AWS.
Crear una API con la API REST de API Gateway

Para crear una API con la API REST de API Gateway, debe utilizar las entidades RestApi, Resource,
Method, MethodResponse, Integration y IntegrationResponse. Los siguientes procedimientos muestran
cómo trabajar con estas entidades de API para crear la API PetStore.
Para crear la API PetStore sencilla
1. Para crear la RestApi para la API, llame a la acción restapi:create, tal y como se muestra a
continuación:
POST /restapis HTTP/1.1

Host: apigateway.us-west-2.amazonaws.com
Content-Type: application/x-amz-json-1.0
X-Amz-Date: 20170511T214723Z
Authorization: AWS4-HMAC-SHA256 Credential={ACCESS-KEY-ID}/20170511/us-west-2/
apigateway/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-date,
Signature=d0abd98a2a06199531c2916b162ede9f63a247032cdc8e4d077216446d13103c
Cache-Control: no-cache
Postman-Token: 0889d2b5-e507-6aab-f222-ab9548dbacaa
{
"name": "Simple PetStore (REST API)",
"description": "A sample API Gateway API created using the REST API."
}
74
Si la llamada se realiza correctamente, se devuelve una respuesta 201 Created con una carga similar
a la siguiente:
{
"createdDate": "2017-05-11T21:47:24Z",
"description": "A sample API Gateway API created using the REST API.",
"id": "x7hyqq0ik7",
"name": "Simple PetStore (REST API)"
}
Anote el valor de id de la RestApi recién creada. Usará este valor en las siguientes operaciones con
esta API. Una RestApi recién creada incluye el recurso raíz (/) de la API. Debe especificar el valor de
id de este recurso raíz para asociar un recurso secundario y para añadir un método en el recurso raíz
o en un recurso secundario. Para obtener este identificador, siga el paso que se indica a continuación.
2. Para obtener el identificador del recurso raíz, llame a la acción restapi:resources , tal y como se
muestra a continuación:
GET /restapis/x7hyqq0ik7/resources HTTP/1.1

X-Amz-Date: 20170511T215738Z
Authorization: AWS4-HMAC-SHA256 Credential={ACCESS-KEY-ID}/20170511/us-
west-2/apigateway/aws4_request, SignedHeaders=content-type;host;x-amz-date,
Signature=76c24ef91d835b85313142bf75545c4ac4c212067e8188ee6a127c21dae09e29
Postman-Token: ed8fb586-8d67-8db7-d229-5a88b4620037
Si la solicitud se realiza correctamente, se devuelve la respuesta 200 OK con una carga similar a la
siguiente:
{
"_embedded": {
"item": {
"_links": {
"self": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd"
},
"method:by-http-method": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/{http_method}",
"templated": true
},
"method:put": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/{http_method}",
"templated": true
},
"resource:create-child": {
},
"resource:update": {
}
},
"id": "0f72nvvnkd",
"path": "/"
}
}
}
75
Tenga en cuenta que el recurso raíz se identifica mediante la ruta / en la carga de la respuesta
devuelta.
3. Para añadir un método GET al recurso raíz, llame a la acción method:put, tal y como se muestra a
continuación:
PUT /restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET HTTP/1.1

X-Amz-Date: 20170512T000729Z
Signature=8a7093411c97b0aa90f4b1890475d93cf20aa3732089da61e6deb410fbc6037d
Postman-Token: 48abcd2f-c357-9e44-669e-d8d813f876ca
{
"authorizationType": "NONE"
}
Si establece authorizationType en NONE, cualquiera podrá llamar a la API. Esto es coherente con
los permisos de acceso en el sitio web PetStore del backend. Para otros backends o para otros
escenarios de aplicación, es posible que necesite usar otro tipo de autorización.
La solicitud, si se realiza correctamente, devuelve una respuesta 201 Created con una carga similar a
la siguiente:
{
"_links": {
"curies": [
...
],
"self": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET",
"name": "GET",
"title": "GET"
},
"integration:put": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/integration"
},
"method:delete": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET"
},
"method:update": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET"
},
"methodresponse:put": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/responses/
{status_code}",
"templated": true
}
},
"apiKeyRequired": false,
"authorizationType": "NONE",
"httpMethod": "GET"
}
El recurso Method que se acaba de crear representa la solicitud del método orientada al cliente. En
función de los requisitos de la API, puede configurar parámetros de encabezado, ruta y consulta en
una solicitud de método. Para POST, PUT, PATCH y otros métodos que toman cargas, puede definir un
76
modelo para la carga en la solicitud del método. Para obtener más información sobre estas opciones,
consulte Configurar un método y una integración (p. 83).
4. Para configurar la respuesta 200 OK para el método GET /, llame a la acción method:put, tal y como se
PUT /restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/responses/200 HTTP/1.1

X-Amz-Date: 20170512T003943Z
Signature=229ef4cfba4bbe41132f36c027f0ae4449bb741671875075a4b216e9b778233e
Postman-Token: 268fcf18-92e4-dfea-821a-ebf4e1d0edfd
{}
La respuesta, si es correcta, devuelve un código de estado 201 Created y una carga similar a la
siguiente:
{
"_links": {
"curies": {
"href": "http://docs.aws.amazon.com/apigateway/latest/developerguide/restapi-
method-response-{rel}.html",
"name": "methodresponse",
"templated": true
},
"self": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/responses/200",
"title": "200"
},
"methodresponse:delete": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/responses/200"
},
"methodresponse:update": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/responses/200"
}
},
"statusCode": "200"
}
La solicitud Method y MethodRepsonse representan la interfaz orientada al cliente del método

GET / de la API. Para que la interfaz funcione correctamente, configuramos su Integration e
IntegrationResponse para reenviar la solicitud entrante del cliente al backend y para dirigir la
respuesta devuelta del backend al cliente.
5. Para configurar la solicitud Integration con el backend PetStore, llame a la acción integration:put, tal
y como se muestra a continuación:
PUT /restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/integration HTTP/1.1

X-Amz-Date: 20170512T002249Z
Signature=10359971a8c54862a47e39d6a6e4b6e62c263e9a2b785b47b40c426c0aa61c19
Postman-Token: 7f7bbb22-afdb-09ed-e22a-8c13f8e91ee7
77
"type" : "HTTP",
"httpMethod" : "GET",
"uri" : "http://petstore-demo-endpoint.execute-api.com/petstore/pets"
}
En la carga de la solicitud, uri apunta al punto de enlace del backend asociado al método. type hace
referencia al tipo de integración. Para el uri HTTP especificado, el valor de type debe ser HTTP. La
propiedad httpMethod establece el verbo HTTP requerido por el backend, que puede ser diferente del
verbo HTTP de la solicitud del método establecido en la URL de la acción integration:put.
La respuesta, si es correcta, devuelve un código de estado 201 Created con una carga similar a la
siguiente:
{
"_links": {
"curies": [
...
],
"self": {
},
"integration:delete": {
},
"integration:update": {
},
"integrationresponse:put": {
"href": "/restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/integration/
responses/{status_code}",
"templated": true
}
},
"cacheKeyParameters": [],
"cacheNamespace": "0f72nvvnkd",
"passthroughBehavior": "WHEN_NO_MATCH",
"type": "HTTP",
"uri": "http://petstore-demo-endpoint.execute-api.com/petstore/pets"
}
6. Para configurar IntegrationResponse, llame a la acción integrationresponse:put, tal y como se

PUT /restapis/x7hyqq0ik7/resources/0f72nvvnkd/methods/GET/integration/responses/200
HTTP/1.1
X-Amz-Date: 20170512T004542Z
Signature=545ab6ea151f72c52161ee856ee621f136d717e40a02743cd8fe3638895794b1
Postman-Token: d29cabea-5232-7021-88ad-f1e950f55a99
{}
La respuesta, si es correcta, devuelve el código de estado 201 Created con una carga similar a la
siguiente:
78
Crear una API con comandos de la AWS CLI
"_links": {
"curies": {
integration-response-{rel}.html",
"name": "integrationresponse",
"templated": true
},
"self": {
responses/200",
"title": "200"
},
"integrationresponse:delete": {
responses/200"
},
"integrationresponse:update": {
responses/200"
}
},
"statusCode": "200"
}
Ahora hemos creado correctamente una API PetStore sencilla.
Después de implementar la API en, por ejemplo, una etapa test (consulte deployment:create), puede
probar esta API escribiendo la URL https://x7hyqq0ik7.execute-api.us-west-2.amazonaws.com/test
en un navegador. Sustituya el identificador de RestApi (x7hyqq0ik7) por el identificador de la API. La
salida esperada debe ser la siguiente:
[
{
"id": 1,
"type": "dog",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]

Para crear una API utilizando la AWS CLI, debe utilizar los comandos create-rest-api, create-resource
o get-resources, put-method, put-method-response, put-integration y put-integration-response.
Los siguientes procedimientos muestran cómo trabajar con estos comandos de la AWS CLI para crear la
API PetStore.
Para crear una API PetStore sencilla mediante la AWS CLI
1. Llame al comando create-rest-api para crear una RestApi.
79
aws apigateway create-rest-api --name 'Simple PetStore (AWS CLI)' --region us-west-2
A continuación se muestra la salida de este comando:
{
"name": "Simple PetStore (AWS CLI)",
"id": "vaz7da96z6",
"createdDate": 1494572809
}
2. Llame al comando get-resources para recuperar el identificador del recurso raíz de la RestApi.
aws apigateway get-resources --rest-api-id vaz7da96z6 --region us-west-2
{
"items": [
{
"path": "/",
"id": "begaltmsm8"
}
]
}
3. Llame al comando put-method para crear una solicitud Method GET / con acceso abierto.
aws apigateway put-method --rest-api-id vaz7da96z6 --resource-id begaltmsm8 --http-

method GET --authorization-type "NONE" --region us-west-2
{
"apiKeyRequired": false,
"authorizationType": "NONE"
}
4. Llame al comando put-method-response para crear un entidad MethodResponse del método GET /.
aws apigateway put-method-response --rest-api-id vaz7da96z6 --resource-id begaltmsm8 --

http-method GET --status-code 200 --region us-west-2
{
"statusCode": "200"
}
5. Llame al comando put-integration para crear una entidad Integration con un punto de enlace
HTTP especificado para el método GET /.
aws apigateway put-integration --rest-api-id vaz7da96z6 --resource-id begaltmsm8 --

http-method GET --type HTTP --integration-http-method GET --uri 'http://petstore-demo-
endpoint.execute-api.com/petstore/pets' --region us-west-2
80
Crear una API importando definiciones de Swagger
{
"passthroughBehavior": "WHEN_NO_MATCH",
"cacheKeyParameters": [],
"type": "HTTP",
"uri": "http://petstore-demo-endpoint.execute-api.com/petstore/pets",
"cacheNamespace": "begaltmsm8"
}
6. Llame al comando put-integration-response para crear una entidad IntegrationResponse del

método GET / integrada con un backend HTTP.
aws apigateway put-integration-response --rest-api-id vaz7da96z6 --resource-id

begaltmsm8 --http-method GET --status-code 200 --selection-pattern "" --region us-
west-2
{
"selectionPattern": "",
"statusCode": "200"
}
Implemente la API en una etapa stage llamando, por ejemplo, a create-deployment:
aws apigateway create-deployment --rest-api-id vaz7da96z6 --stage-name test --stage-

description 'Test stage' --description 'First deployment'
Puede probar esta API escribiendo la URL https://vaz7da96z6.execute-api.us-

west-2.amazonaws.com/test en un navegador y sustituyendo vaz7da96z6 por el identificador de la API. La
salida esperada debe ser la siguiente:
[
{
"id": 1,
"type": "dog",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
"id": 3,
"type": "fish",
"price": 0.99
}
]

Puede crear una API en API Gateway especificando definiciones de Swagger de las entidades API de API
Gateway correspondientes e importando las definiciones de Swagger en API Gateway.
81
Las siguientes definiciones de Swagger describen la API sencilla, que expone solo el método GET /
integrado con un punto de enlace HTTP del sitio web PetStore en el backend y devuelve una respuesta
200 OK.
{
"swagger": "2.0",
"info": {
"title": "Simple PetStore (Swagger)"
},
"schemes": [
"https"
],
"paths": {
"/": {
"get": {
"responses": {
"200": {
"description": "200 response"
}
},
"x-amazon-apigateway-integration": {
"responses": {
"default": {
"statusCode": "200"
}
},
"uri": "http://petstore-demo-endpoint.execute-api.com/petstore/pets",
"passthroughBehavior": "when_no_match",
"type": "http"
}
}
}
}
}
El siguiente procedimiento describe cómo importar estas definiciones de Swagger en API Gateway
mediante la consola de API Gateway.
Para importar las definiciones de Swagger de la API sencilla utilizando la consola de API Gateway
1. Inicie sesión en la consola de API Gateway.

2. Seleccione Create API.
3. Elija Import from Swagger.
4. Si guardó las definiciones de Swagger anteriores en un archivo, elija Select Swagger File. También
puede copiar las definiciones de Swagger y pegarlas en el editor de texto de importación.
5. Elija Import para completar la importación de las definiciones de Swagger.
Para importar las definiciones de Swagger utilizando la API REST de API Gateway, llame a la acción
restapi:import, proporcionando las definiciones de Swagger anteriores como la carga. Para obtener más
información, consulte el ejemplo de la sección Observaciones del tema restapi:import.
Para importar las definiciones de Swagger utilizando la AWS CLI, guarde las definiciones de Swagger en
un archivo y, a continuación, ejecute el siguiente comando, suponiendo que utiliza la región us-west-2 y
que la ruta absoluta del archivo de Swagger es file:///path/to/API_Swagger_template.json:
aws apigateway import-rest-api --body 'file:///path/to/API_Swagger_template.json' --region

us-west-2
82
Configurar un método y una integración
Configurar un método y una integración de API de

API Gateway
Antes de configurar métodos e integraciones
• El método debe estar disponible en API Gateway. Siga las instrucciones en Cree una API de API
• Si desea que el método se comunique con una función Lambda, debe haber creado el rol de invocación
de Lambda y el rol de ejecución de Lambda en IAM y debe haber creado la función Lambda con la que
se comunicará el método en AWS Lambda. Para crear los roles y funciones, utilice las instrucciones de
Paso 4: Crear funciones Lambda (p. 46) de Crear una API para exponer una función Lambda (p. 45).
• Si desea que el método se comunique con una integración HTTP o de proxy HTTP, debe haber creado y
tener acceso a la URL del punto de enlace HTTP con la que se comunicará el método.
• Compruebe API Gateway admite los certificados de los puntos de enlace HTTP y proxy de HTTP. Para
obtener más información, consulte Entidades de certificación compatibles para las integraciones HTTP y
Proxy HTTP (p. 260).
Configurar una solicitud de integración de API

Gateway
La configuración de un método de API define el método y describe sus comportamientos. Para crear
un método, debe especificar un recurso, incluida la raíz ("/"), en el que se expone el método, un tipo de
método (GET, POST, etc.) y la forma en la que se integrará con el backend de destino. La solicitud y la
respuesta del método especifican el contrato con la aplicación que realiza la llamada, que estipula los
parámetros que puede recibir la API y el aspecto que tendrá la respuesta. La solicitud y la respuesta de
integración especifican cómo API Gateway interactúa con su backend: estableciendo comunicaciones
seguras a través de HTTPS con el backend y traduciendo los formatos de datos entre el cliente y el
backend. En los siguientes temas se describe cómo utilizar la consola de API Gateway para especificar la
configuración de un método.
1. En el panel de navegación Resources, elija el método.

2. En el panel Method Execution, elija Integration Request. En Integration type, seleccione una de las
siguientes opciones:
• Elija Lambda Function si la API se va a integrarse con una función Lambda. En el nivel de API, este
es un tipo de integración AWS.
• Elija HTTP si la API se va a integrar con un punto de enlace HTTP. En el nivel de API, este es el tipo
de integración HTTP.
• Elija AWS Service si la API se va a integrar directamente con un servicio de AWS. En el nivel de
API, este es el tipo de integración AWS. La opción Lambda Function anterior es un caso especial de
la integración de AWS para invocar una función Lambda y solo está disponible en la consola de API
Gateway. Para configurar una API de API Gateway para crear una función Lambda nueva en AWS
Lambda, establecer un permiso a nivel de recursos en la función Lambda o realizar cualquier otra
acción del servicio Lambda, debe elegir la opción AWS Service aquí.
• Elija Mock si desea que API Gateway actúe como backend y devuelva respuestas estáticas. En el
nivel de API, este es el tipo de integración MOCK. Normalmente, puede usar la integración MOCK si
la API aún no es definitiva, pero desea generar respuestas de API para permitir que los equipos
dependientes realicen pruebas. En el método OPTION, API Gateway establece la integración MOCK
como predeterminada para devolver encabezados que habilitan CORS para el recurso de la API que
83
Configurar una solicitud de integración
se aplicó. Si elige esta opción, omita el resto de las instrucciones de este tema y consulte Configurar
una integración simulada para un método (p. 112).
3. Si ha elegido Lambda Function, proceda de la forma siguiente:
1. En Lambda Region, elija el identificador de región correspondiente a la región en la que ha

creado la función Lambda. Por ejemplo, si ha creado la función Lambda en la región US East (N.
Virginia), debería elegir us-east-1. Para ver una lista de nombres e identificadores de regiones,
consulte AWS Lambda en la Referencia general de Amazon Web Services.
2. En Lambda Function, escriba el nombre de la función Lambda y, a continuación, elija el ARN
correspondiente de la función.
3. Seleccione Save.
4. Si ha elegido HTTP , proceda de la forma siguiente:
1. En HTTP method, elija el tipo de método HTTP que más se parezca al método del backend
HTTP.
2. En Endpoint URL, escriba la dirección URL del backend HTTP que desea que utilice este método.
3. Seleccione Save.
5. Si ha elegido Mock , proceda de la forma siguiente:
• Seleccione Save.
6. Si ha elegido AWS Service, proceda de la forma siguiente:
1. En AWS Region, elija la región de AWS que desea que utilice este método para llamar a la
acción.
2. En AWS Service, elija el servicio de AWS al que desea que llame este método.
3. En AWS Subdomain, escriba el subdominio que utilice el servicio de AWS de su interés.
Normalmente, puede dejarlo en blanco. Algunos servicios de AWS admiten subdominios como
parte de los hosts. En la documentación del servicio encontrará la disponibilidad y los detalles, si
están disponibles.
4. En HTTP method, seleccione el tipo de método HTTP correspondiente a la acción. Para el tipo de
método HTTP, consulte la documentación de referencia de la API correspondiente al servicio de
AWS que eligió en AWS Service.
5. En Action, escriba la acción que desea utilizar. Para ver una lista de las acciones disponibles,
consulte la documentación de referencia de la API correspondiente al servicio de AWS que eligió
en AWS Service.
6. En Execution Role, escriba el ARN del rol de IAM que usará el método para llamar a la acción.
Para crear el rol de IAM, puede adaptar las instrucciones de "Para crear el rol de invocación de
Lambda y sus políticas" y "Para crear el rol de ejecución de Lambda y su política" en la sección
Crear funciones Lambda (p. 46) de Crear una API para exponer una función Lambda (p. 45),
y especificar una política de acceso con el siguiente formato y con el número de acciones e
instrucciones de recursos que desee:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"action-statement"
],
"Resource": [
"resource-statement"
]
},
...
84
Configurar una solicitud de método
]
}
Para ver la sintaxis de las acciones e instrucciones de recursos, consulte la documentación del
servicio de AWS que eligió en AWS Service.
Para la relación de confianza del rol de IAM, especifique lo siguiente, que permite a API Gateway
realizar acciones en nombre de su cuenta de AWS:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
7. Si la acción que especificó para Action proporciona una ruta de recurso personalizada que
desea que utilice este método, en Path Override, escriba esta ruta. Para la ruta de recurso
personalizada, consulte la documentación de referencia de la API correspondiente al servicio de
AWS que eligió en AWS Service.
8. Seleccione Save.
7. Realice estas dos operaciones:
• Especifique cómo el método recibirá las solicitudes y enviará las respuestas a los intermediarios
(lo que en API Gateway se conoce como solicitud y respuesta del método de API), y cómo el
método autorizará las solicitudes siguiendo las instrucciones de Configurar una solicitud de
método (p. 85).
• Especifique cómo el método enviará las solicitudes y recibirá las respuestas de la función Lambda,
proxy HTTP o proxy de servicio de AWS (lo que en API Gateway se conoce como solicitud y
respuesta de integración de la API) siguiendo las instrucciones de Configuración de mapeo de datos
entre método e integración (p. 87).
Configurar una solicitud de métodos de API Gateway

Para utilizar la consola de API Gateway para especificar una solicitud o respuesta del método de una API y
la forma en que el método autorizará las solicitudes, siga estas instrucciones.
Note
Estas instrucciones presuponen que ya ha completado los pasos que se detallan en Configurar
una solicitud de integración de API Gateway (p. 83).
1. Con el método seleccionado en el panel Resources, elija Method Request en el panel Method
Execution.
2. Para asignar permisos de acceso personalizados al método, en el área Authorization Settings, para
Authorization Type, elija Edit y, a continuación, AWS_IAM. Solo los roles de IAM con la política
de IAM correcta asociada podrán llamar a este método. Si no desea asignar permisos de acceso
personalizados al método, elija NONE.
• Para crear el rol de IAM, especifique una política de acceso con un formato como el siguiente:
85
Configurar una solicitud de método
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
"Resource": [
]
}
]
}
En esta política de acceso, resource-statement es el valor del campo ARN en la sección

Authorization Settings.
Para crear el rol de IAM, puede adaptar las instrucciones de "Para crear el rol de invocación de
Lambda y su política" y "Para crear el rol de ejecución de Lambda y su política" de la sección Crear
funciones Lambda (p. 46) de Crear una API para exponer una función Lambda (p. 45).
Para guardar la selección, elija Update. De lo contrario, seleccione Cancel.

3. Para añadir un parámetro de cadena de consulta al método, haga lo siguiente:
a. Elija la flecha situada junto a URL Query String Parameters y, a continuación, elija Add query
string.
b. En Name, escriba el nombre del parámetro de cadena de consulta.
c. Elija Create a new query string.
Note
Para eliminar el parámetro de cadena de consulta, seleccione Cancel o Remove.

Para cambiar el nombre del parámetro de cadena de consulta, debe eliminarlo y crear uno
nuevo.
4. Para añadir un parámetro de encabezado al método, haga lo siguiente:
a. Elija la flecha situada junto a HTTP Request Headers y, a continuación, elija Add header.
b. En Name, escriba el nombre del parámetro de encabezado.
c. Si lo desea, active la opción Caching para crear este método como una clave de caché de API.
Para obtener más información, consulte Usar parámetros de método o integración como claves de
caché (p. 303).
d. Seleccione Create.
Tip
Para eliminar el parámetro de encabezado, seleccione Cancel o Remove.

Para cambiar el nombre del parámetro de encabezado, debe eliminar el parámetro de
encabezado anterior y crear uno nuevo en su lugar.
5. Para los tipos de métodos distintos de GET, expanda Request Models y, en Content Type y
Model name, escriba el tipo de contenido y elija el nombre de un modelo que transforme los datos
proporcionados por el intermediario en el formato esperado.
Para crear un modelo, consulte Crear un modelo (p. 130).
86
Configuración de mapeo de
datos entre método e integración
6. Para enviar un conjunto de encabezados de respuesta personalizados, un formato de datos de

respuesta personalizado o ambas cosas a los intermediarios en función del código de estado HTTP
devuelto por el método, haga lo siguiente:
a. En el panel Method Execution, elija Method Response. De forma predeterminada, la respuesta

200 se incluye en las respuestas del método. Puede modificarlo para que el método devuelva, por
ejemplo, 201 en su lugar. Además, puede añadir otras respuestas, como 409 para la denegación
de acceso y 500 para las variables de etapa sin inicializar utilizadas. Elija el icono de flecha
situado junto a 200 para especificar la configuración de la respuesta 200 o elija Add Response
para especificar la configuración de cualquier otro código de estado de respuesta HTTP. Si elige
Add Response, para HTTP Status, elija la respuesta, elija Create y elija la flecha situada junto a la
respuesta.
Tip
Utilizará Method Response para especificar todos los códigos de respuesta posibles para
la API y utilizará Integration Response para indicar a API Gateway cómo se mapean los
errores del backend a un código de estado HTTP.
b. Para cada encabezado personalizado que desee incluir en la respuesta, en el área Response
Headers, elija Add Header, escriba el nombre del encabezado y, a continuación, elija Save. (Elija
Remove para eliminar un encabezado de la lista).
Para especificar un modelo de respuesta para transformar los datos de salida de un formato de
datos a otro, en el área Response Models, elija Add Response Model. Escriba el tipo de contenido
(en Content type), elija el nombre del modelo (en Models) y, a continuación, elija Save. Elija Add
Response Model para especificar un modelo adicional o Create a model para definir un nuevo
modelo. (Elija Remove para eliminar una selección de modelo de respuesta de esta lista).
Configuración de mapeo de datos entre método e

integración
Para utilizar la consola de API Gateway para definir la solicitud o respuesta de integración de la API, siga
estas instrucciones.
Note
Estas instrucciones presuponen que ya ha completado los pasos que se detallan en Configurar
una solicitud de integración de API Gateway (p. 83).
1. Con el método seleccionado en el panel Resources, elija Integration Request en el panel Method
Execution.
2. Para un proxy HTTP o un servicio de proxy de AWS, para asociar un parámetro de ruta, un parámetro
de cadena de consulta o un parámetro de encabezado definido en la solicitud de integración con un
parámetro de ruta, parámetro de cadena de consulta o parámetro de encabezado correspondientes en
la solicitud del método del proxy HTTP o proxy de servicio AWS, haga lo siguiente:
a. Elija la flecha situada junto a URL Path Parameters, URL Query String Parameters o HTTP
Headers, respectivamente, y, a continuación, elija Add path, Add query string o Add header,
respectivamente.
b. En Name, escriba el nombre del parámetro de ruta, parámetro de cadena de consulta o parámetro
de encabezado en el proxy HTTP o proxy de servicio de AWS.
c. En Mapped from, escriba el valor de mapeo del parámetro de ruta, parámetro de cadena de
consulta o parámetro de encabezado. Utilice uno de los siguientes formatos:
• method.request.path.parameter-name para un parámetro de ruta denominado parameter-

name tal como se define en la página Method Request.
87
Configuración de mapeo de
datos entre método e integración
• method.request.querystring.parameter-name para un parámetro de cadena de consulta

denominado parameter-name tal como se define en la página Method Request.
• method.request.header.parameter-name para un parámetro de encabezado denominado
parameter-name tal como se define en la página Method Request.
También puede establecer un valor de cadena literal (incluida entre un par de comillas simples)
en un encabezado de integración.
d. Seleccione Create. (Para eliminar un parámetro de ruta, parámetro de cadena de consulta o
parámetro de encabezado, elija Cancel o Remove junto al parámetro que desea eliminar).
3. En el área Body Mapping Templates, elija una opción para Request body passthrough para definir
cómo el cuerpo de una solicitud de método de un tipo de contenido no mapeado se pasará a la
solicitud de integración sin transformación en la función Lambda, proxy HTTP o proxy de servicio de
AWS. Hay tres opciones:
• Elija When no template matches the request Content-Type header si desea que el cuerpo de la
solicitud de método se transmita a través de la solicitud de integración al backend sin transformación
cuando el tipo de contenido de la solicitud de método no coincida con ninguno de los tipos de
contenido asociados a las plantillas de mapeo, tal y como se define en el siguiente paso.
Note
Al llamar a la API de API Gateway, elige esta opción estableciendo WHEN_NO_MATCH como el
valor de la propiedad passthroughBehavior en el recurso Integration.
• Elija When there are no templates defined (recommended) si desea que el cuerpo de la solicitud
del método se transfiera a la solicitud de integración en el backend sin transformación cuando no
se haya definido ninguna plantilla de mapeo en la solicitud de integración. Si se define una plantilla
cuando esta opción está seleccionada, la solicitud de método de un tipo de contenido sin asignar se
rechazará con una respuesta HTTP 415 Unsupported Media Type.
Note
Al llamar a la API de API Gateway, elige esta opción estableciendo WHEN_NO_TEMPLATE

como el valor de la propiedad passthroughBehavior en el recurso Integration.
• Elija Never si no desea que la solicitud del método se transfiera cuando su tipo de contenido no
coincida con ningún tipo de contenido asociado a las plantillas de mapeo definidas en la solicitud
de integración o no se haya definido ninguna plantilla de mapeo en la solicitud de integración. La
solicitud del método de un tipo de contenido sin asignar se rechazará con una respuesta HTTP 415
Unsupported Media Type.
Note
Al llamar a la API de API Gateway, elige esta opción estableciendo NEVER como el valor de
la propiedad passthroughBehavior en el recurso Integration.
Para obtener más información sobre los comportamientos de paso a través de la integración, consulte
Comportamiento del acceso directo a la integración (p. 150).
4. Para definir una plantilla de mapeo para una solicitud de entrada, elija Add mapping template en
Content-Type. Especifique un tipo de contenido (por ejemplo, application/json) en el cuadro de
texto de entrada y, a continuación, elija el icono de marca de verificación para guardar la entrada. A
continuación, especifique la plantilla de mapeo manualmente o elija Generate template para crear una
a partir de una plantilla de modelo. Para obtener más información, consulte Crear modelos y plantillas
de asignación para las cargas de solicitud y respuesta (p. 123).
5. Puede mapear una respuesta de integración desde el backend a una respuesta de método de la API
devuelta a la aplicación que realiza la llamada. Esto incluye devolver los encabezados de respuesta
seleccionados del cliente desde los encabezados disponibles en el backend, transformando el
formato de datos de la carga de respuesta del backend en un formato especificado por la API. Puede
88
Tratamiento de errores de Lambda en API Gateway
especificar este tipo de mapeo configurando Method Response e Integration Response en la página
Method Execution.
a. En el panel Method Execution, elija Integration Response. Elija la flecha situada junto a 200 para
especificar la configuración de un código de respuesta HTTP 200 desde el método o elija Add
integration response para especificar la configuración de cualquier otro código de estado de
respuesta HTTP desde el método.
b. En Lambda error regex (para una función Lambda) o HTTP status regex (para un proxy HTTP o
un proxy de servicio de AWS), escriba una expresión regular para especificar las cadenas de error
de la función Lambda (para una función Lambda) o los códigos de estado de respuesta HTTP
(para un proxy HTTP o un proxy de servicio de AWS) que se mapean en este mapeo de salida.
Por ejemplo, para mapear todos los códigos de estado HTTP 2xx desde un proxy HTTP proxy
a este mapeo de salida, escriba "2\\d{2}" en HTTP status regex. Para devolver un mensaje
de error que contenga "Invalid Request" desde una función Lambda a una respuesta 400 Bad
Request, escriba".*Invalid request.*" como la expresión Lambda error regex. Por otra parte,
para devolver 400 Bad Request para todos los mensajes de error no asignados desde Lambda,
escriba"(\n|).+" en Lambda error regex. Esta última expresión regular puede utilizarse para la
respuesta de error predeterminada de una API.
Note
Los patrones de error se cotejan con la cadena completa de la propiedad errorMessage

en la respuesta de Lambda, que se rellena con callback(errorMessage) en Node.js o
con throw new MyException(errorMessage) en Java. Además, los caracteres incluidos
en secuencias de escape se sacan de las secuencias de escape antes de que se aplique
la expresión regular.
Si usa '.+' como el patrón de selección para filtrar respuestas, tenga en cuenta que es
posible que esta patrón no coincida con una respuesta que contenga un carácter de
nueva línea ('\n').
c. Si está habilitado, en Method response status, elija el código de estado de respuesta HTTP que
definió en la página Method Response.
d. En Header Mappings, para cada encabezado definido para el código de estado de respuesta
HTTP en la página Method Response, especifique un valor de mapeo eligiendo Edit. En Mapping
value, utilice el formato integration.response.header.header-name donde header-name es el
nombre de un encabezado de respuesta del backend. Por ejemplo, para devolver el encabezado
Date de la respuesta del backend como el encabezado Timestamp de la respuesta de un método
de API, la columna Response header contendrá una entrada Timestamp y la entrada Mapping
value asociada debe estar establecida en integration.response.header.Date.
e. En el área Template Mappings, situada junto a Content type, elija Add. En el cuadro Content type,
escriba el tipo de contenido de los datos que se pasarán desde la función Lambda, proxy HTTP o
proxy de servicio de AWS al método. Elija Update.
f. Seleccione Output passthrough si desea que el método reciba, pero no modifique, los datos de la
función Lambda, proxy HTTP o proxy de servicio de AWS.
g. Si Output passthrough está desactivado, en Output mapping, especifique la plantilla de mapeo de
salida que desea que la función Lambda, proxy HTTP o proxy de servicio de AWS utilicen para
enviar datos al método. Puede escribir la plantilla de mapeo manualmente o elegir un modelo de
Generate template from model.
h. Seleccione Save.

Cuando la API se integra con AWS Lambda con la integración normal de Lambda y no con la integración
de proxy Lambda, debe asignar los errores devueltos por Lambda en la respuesta de integración a las
respuestas de error HTTP estándar para sus clientes. De lo contrario, los errores de Lambda se devuelven
89
como respuestas 200 OK de forma predeterminada y el resultado no es intuitivo para los usuarios de la
API.
Hay dos tipos de errores que Lambda puede devolver: errores estándar y errores personalizados. En la
API, debe tratarlos de forma diferente.
Con la integración de proxy de Lambda, Lambda debe devolver una salida con el siguiente formato:
{
"isBase64Encoded" : "boolean",
"statusCode": "number",
"headers": { ... },
"body": "JSON string"
}
En esta salida, statusCode es normalmente 4XX para un error del cliente y 5XX para un error del servidor.
API Gateway trata estos errores asignando el error de Lambda a una respuesta de error HTTP, de acuerdo
con el statusCode especificado.
Temas
• Tratamiento de errores de Lambda estándar en API Gateway (p. 90)
• Tratamiento de errores de Lambda personalizados en API Gateway (p. 92)
Tratamiento de errores de Lambda estándar en API Gateway

Un error estándar de AWS Lambda tiene el siguiente formato:
{
"errorMessage": "<replaceable>string</replaceable>",
"errorType": "<replaceable>string</replaceable>",
"stackTrace": [
"<replaceable>string</replaceable>",
...
]
}
Aquí, errorMessage es una expresión de cadena del error. errorType es un tipo de error o excepción
dependiente del lenguaje. stackTrace es una lista de expresiones de cadena que indican la pila de
seguimiento que conduce a la aparición del error.
Considere, por ejemplo, la siguiente función Lambda de JavaScript (Node.js 4.3 y versiones posteriores).

callback(new Error("Malformed input ...");
};
Esta función devuelve el siguiente error de Lambda estándar, que contiene Malformed input ... como el
mensaje de error:
{
"errorMessage": "Malformed input ...",
"errorType": "Error",
"stackTrace": [
"exports.handler (/var/task/index.js:3:14)"
]
90
Asimismo, considere la siguiente función Lambda de Python, que produce una Exception con el mismo
mensaje de error Malformed input ....
def lambda_handler(event, context):

raise Exception('Malformed input ...')
Esta función devuelve el siguiente error de Lambda estándar:
{
"stackTrace": [
[
"/var/task/lambda_function.py",
3,
"lambda_handler",
"raise Exception('Malformed input ...')"
]
],
"errorType": "Exception",
"errorMessage": "Malformed input ..."
}
Tenga en cuenta que los valores de las propiedades errorType y stackTrace dependen del lenguaje. El
error estándar también se aplica a cualquier objeto de error que sea una extensión del objeto Error o una
subclase de la clase Exception.
Para asignar el error de Lambda estándar a una respuesta del método, primero debe decidir cuál es el
código de estado HTTP para un error de Lambda determinado. Seguidamente, debe establecer un patrón
de expresiones regulares en la propiedad selectionPattern del recurso IntegrationResponse asociado
con el código de estado HTTP especificado. En la consola de API Gateway, selectionPattern se indica
como Lambda Error Regex en el editor de configuración de Integration Response.
Por ejemplo, para configurar una nueva expresión selectionPattern mediante la AWS CLI, llame al
siguiente comando put-integration-response:
aws apigateway put-integration-response --rest-api-id z0vprf0mdh --resource-id x3o5ih --

http-method GET --status-code 400 --selection-pattern "Invalid*" --region us-west-2
Asegúrese de configurar también el código de error correspondiente (400) en la solicitud del método. De lo
contrario, API Gateway produce una respuesta de error de configuración no válida en tiempo de ejecución.
En tiempo de ejecución, API Gateway coteja el mensaje de error con el patrón de la expresión regular en
la propiedad selectionPattern. Si hay una coincidencia, API Gateway devuelve el error de Lambda como
una respuesta HTTP del código de estado HTTP correspondiente. Si no hay ninguna coincidencia, API
Gateway devuelve el error como una respuesta predeterminada o produce una excepción de configuración
no válida si no se ha configurado una respuesta predeterminada.
Note
Configurar el valor selectionPattern a .* para una determinada respuesta equivale a

restablecer esta respuesta como la predeterminada. Esto se debe a que un patrón de solicitud
de este tipo coincidirá con todos los mensajes de error, incluidos los nulos, es decir, cualquier
mensaje de error no especificado. El mapeo resultante anula el predeterminado.
Para actualizar un valor de selectionPattern existente mediante la API REST de API Gateway, llame a
la operación integrationresponse:update para reemplazar el valor de ruta de /selectionPattern por la
expresión regex especificada del patrón Malformed*.
91
PATCH /restapis/z0vprf0mdh/resources/x3o5ih/methods/GET/integration/responses/400 HTTP/1.1

X-Amz-Date: 20170513T044831Z
Signature=4b4e4881a727bc999799be5110facfcf7ec81d025afc1a4386cf440b4efc80de
Postman-Token: 04794263-29f2-f336-fa16-5653a7f3281d
{
"patchOperations" : [ {
"op" : "replace",
"path" : "/selectionPattern",
"value" : "Malformed*"
} ]
}
Para establecer la expresión selectionPattern con la consola de API Gateway, escriba la expresión en
el cuadro de texto Lambda Error Regex cuando configure o actualice una respuesta de integración de un
código de estado HTTP especificado.
Tratamiento de errores de Lambda personalizados en API

Gateway
En lugar del error estándar descrito en la sección anterior, AWS Lambda le permite devolver un objeto
de error personalizado como una cadena JSON. El error puede ser cualquier objeto JSON válido. Por
ejemplo, la siguiente función Lambda de JavaScript (Node.js 4.3 o versiones posteriores) devuelve un error
personalizado:
exports.handler = (event, context, callback) => {

...
// Error caught here:
var myErrorObj = {
errorType : "InternalServerError",
httpStatus : 500,
requestId : context.awsRequestId,
trace : {
"function": "abc()",
"line": 123,
"file": "abc.js"
}
}
callback(JSON.stringify(myErrorObj));
};
Debe activar el objeto myErrorObj en una cadena JSON antes de llamar a callback para salir de la
función. De lo contrario, myErrorObj se devuelve como una cadena de "[object Object]". Cuando un
método de la API está integrado con la función API Gateway anterior, Lambda recibe una respuesta de
integración con la siguiente carga:
{
"errorMessage": "{\"errorType\":\"InternalServerError\",\"httpStatus\":500,\"requestId
\":\"e5849002-39a0-11e7-a419-5bb5807c9fb2\",\"trace\":{\"function\":\"abc()\",\"line\":123,
\"file\":\"abc.js\"}}"
}
Al igual que con cualquier respuesta de integración, puede transferir esta respuesta de error tal como está
a la respuesta del método. O puede usar una plantilla de asignación de cuerpo para transformar la carga
92
en un formato diferente. Considere, por ejemplo, la siguiente plantilla de asignación de cuerpo para una
respuesta de método del código de estado 500:
{
errorMessage: $input.path('$.errorMessage');
}
Esta plantilla traduce el cuerpo de respuesta de la integración que contiene la cadena JSON del error
personalizado en el siguiente cuerpo de respuesta del método. Este cuerpo de respuesta del método
contiene el objeto JSON del error personalizado:
{
"errorMessage" : {
errorType : "InternalServerError",
httpStatus : 500,
requestId : context.awsRequestId,
trace : {
"function": "abc()",
"line": 123,
"file": "abc.js"
}
}
};
En función de los requisitos de la API, es posible que tenga que pasar algunas o todas las propiedades
de errores personalizados como parámetros de encabezado de la respuesta del método. Para ello,
puede aplicar asignaciones de errores personalizados desde el cuerpo de respuesta de integración a los
encabezados de respuesta del método.
Por ejemplo, la siguiente extensión de Swagger define una asignación desde las propiedades
errorMessage.errorType, errorMessage.httpStatus, errorMessage.trace.function y
errorMessage.trace a error_type, error_status, error_trace_function y error_trace,
respectivamente.
"responses": {
"default": {
"statusCode": "200",
"responseParameters": {
"method.response.header.error_trace_function":
"integration.response.body.errorMessage.trace.function",
"method.response.header.error_status":
"integration.response.body.errorMessage.httpStatus",
"method.response.header.error_type":
"integration.response.body.errorMessage.errorType",
"method.response.header.error_trace":
"integration.response.body.errorMessage.trace"
},
...
}
}
}
En tiempo de ejecución, API Gateway deserializa el parámetro integration.response.body cuando

realiza asignaciones de encabezado. Sin embargo, esta deserialización se aplica únicamente a las
asignaciones de cuerpo a encabezado para respuestas de errores personalizados de Lambda y no se
aplica a las asignaciones de cuerpo a cuerpo que utilizan $input.body. Con estas asignaciones de cuerpo
a encabezado de errores personalizados, el cliente recibe los siguientes encabezados como parte de la
respuesta del método, siempre que los encabezados error_status, error_trace, error_trace_function
y error_type estén declarados en la solicitud del método.
93
Habilitar la compatibilidad con cargas binarias
"error_status":"500",
"error_trace":"{\"function\":\"abc()\",\"line\":123,\"file\":\"abc.js\"}",
"error_trace_function":"abc()",
"error_type":"InternalServerError"
La propiedad errorMessage.trace del cuerpo de respuesta de integración es una propiedad compleja. Se

asigna al encabezado error_trace como una cadena JSON.
Habilitar la compatibilidad con cargas binarias en API

Gateway
En API Gateway, la solicitud y respuesta de API pueden tener una carga de texto o binaria. Una carga de
texto es una cadena JSON codificada en UTF-8. y una carga binaria es cualquier otra cosa distinta de una
carga de texto. La carga binaria puede ser, por ejemplo, un archivo JPEG, un archivo GZip o un archivo
XML.
De forma predeterminada, API Gateway trata el cuerpo del mensaje como una carga de texto y aplica
cualquier plantilla de mapeo preconfigurada para transformar la cadena JSON. Si no se especifica
ninguna plantilla de mapeo, API Gateway puede pasar la carga de texto a o desde el punto de enlace de
integración sin modificación, siempre que el comportamiento de paso a través esté habilitado en el método
de la API. Para una carga binaria, API Gateway transfiere el mensaje tal como está.
Para que API Gateway pueda pasar cargas binarias, debe añadir los tipos de medios a la lista
binaryMediaTypes del recurso RestApi o establecer las propiedades contentHandling en los recursos
Integration e IntegrationResponse. El valor contentHandling puede ser CONVERT_TO_BINARY,
CONVERT_TO_TEXT o no estar definido. En función del valor de contentHandling y de si el encabezado
Content-Type de la respuesta o el encabezado Accept de la solicitud coinciden con una entrada de la
lista binaryMediaTypes, API Gateway puede codificar los bytes binarios sin formato como una cadena
codificada en Base64, descodificar una cadena codificada en Base64 en sus bytes sin formato o transferir
el cuerpo sin realizar ninguna modificación.
Debe configurar la API como se indica a continuación para que su API de API Gateway admita cargas
binarias:
• Agregue los tipos de medios binarios que desee a la lista binaryMediaTypes en el recurso RestApi. Si
esta propiedad y la contentHandling propiedad no se definen, las cargas se administran como cadenas
JSON codificadas en UTF-8.
• Establezca la propiedad contentHandling del recurso Integration en CONVERT_TO_BINARY para que la
carga de la solicitud se convierta de una cadena codificada en Base64 en su blob binario, o establezca
la propiedad en CONVERT_TO_TEXT para que la carga de la solicitud se convierta de un blob binario en
una cadena codificada en Base64. Si no se define esta propiedad, API Gateway transfiere la carga sin
modificaciones. Esto ocurre cuando el valor del encabezado Content-Type coincide con una de las
entradas de binaryMediaTypes y cuando los comportamientos de paso a través (p. 150) están también
habilitados para la API.
• Establezca la propiedad contentHandling del recurso IntegrationResponse en CONVERT_TO_BINARY para
que la carga de la respuesta se convierta de una cadena codificada en Base64 en su blob binario, o
establezca la propiedad en CONVERT_TO_TEXT para que la carga de la respuesta se convierta de un blob
binario en una cadena codificada en Base64. Si contentHandling no está definido, y si el encabezado
Content-Type de la respuesta y el encabezado Accept de la solicitud original coinciden con una entrada
de la lista binaryMediaTypes, API Gateway transfiere el cuerpo. Esto ocurre cuando el encabezado
Content-Type y el encabezado Accept son iguales; de lo contrario, API Gateway convierte el cuerpo de
la respuesta al tipo especificado en el encabezado Accept.
Temas
94
• Conversiones de tipo de contenido en API Gateway (p. 95)

• Habilitar la compatibilidad con datos binarios mediante la consola de API Gateway (p. 97)
• Habilitar la compatibilidad con datos binarios mediante la API REST de API Gateway (p. 101)
• Importar y exportar codificaciones de contenido (p. 105)
• Ejemplos de compatibilidad con datos binarios (p. 105)
Conversiones de tipo de contenido en API Gateway

La siguiente tabla muestra cómo API Gateway convierte la carga de solicitud para configuraciones
específicas del encabezado Content-Type de una solicitud, la lista binaryMediaTypes de un recurso
RestApi y el valor de la propiedad contentHandling del recurso Integration.
Conversiones de tipo de contenido de solicitudes de API en API Gateway
Carga de solicitud Encabezado binaryMediaTypes contentHandling Carga de solicitud

de método Content-Type de de integración
solicitud
Datos de texto Cualquier tipo de Sin definir Sin definir Cadena codificada
datos en UTF8
Datos de texto Cualquier tipo de Sin definir CONVERT_TO_BINARY Blob binario

datos descodificado en
Base64
Datos de texto Cualquier tipo de Sin definir CONVERT_TO_TEXT Cadena codificada

datos en UTF8
Datos de texto Un tipo de datos Establecida con Sin definir Datos de texto
de texto tipos de medios
coincidentes
Datos de texto Un tipo de datos Establecida con CONVERT_TO_BINARY Blob binario

de texto tipos de medios descodificado en
coincidentes Base64
Datos de texto Un tipo de datos Establecida con CONVERT_TO_TEXT Datos de texto

de texto tipos de medios
coincidentes
Datos binarios Un tipo de datos Establecida con Sin definir Datos binarios
binarios tipos de medios
coincidentes
Datos binarios Un tipo de datos Establecida con CONVERT_TO_BINARY Datos binarios

binarios tipos de medios
coincidentes
Datos binarios Un tipo de datos Establecida con CONVERT_TO_TEXT Cadena codificada

binarios tipos de medios en Base64
coincidentes
La siguiente tabla muestra cómo API Gateway convierte la carga de respuesta para configuraciones
específicas del encabezado Accept de una solicitud, la lista binaryMediaTypes de un recurso RestApi y el
valor de la propiedad contentHandling del recurso IntegrationResponse.
95
Conversiones de tipo de contenido de respuesta en API Gateway
Carga de Encabezado binaryMediaTypes contentHandling Carga de

respuesta de Accept de solicitud respuesta de
integración método
Datos de texto o Un tipo de texto Sin definir Sin definir Cadena codificada
binarios en UTF8
Datos de texto o Un tipo de texto Sin definir CONVERT_TO_BINARY Blob descodificado

binarios en Base64
Datos de texto o Un tipo de texto Sin definir CONVERT_TO_TEXT Cadena codificada

binarios en UTF8
Datos de texto Un tipo de texto Establecida con Sin definir Datos de texto
tipos de medios
coincidentes
Datos de texto Un tipo de texto Establecida con CONVERT_TO_BINARY Blob descodificado

tipos de medios en Base64
coincidentes
Datos de texto Un tipo de texto Establecida con CONVERT_TO_TEXT Cadena codificada

tipos de medios en UTF8
coincidentes
Datos de texto Un tipo binario Establecida con Sin definir Blob descodificado
coincidentes
Datos de texto Un tipo binario Establecida con CONVERT_TO_BINARY Blob descodificado

coincidentes
Datos de texto Un tipo binario Establecida con CONVERT_TO_TEXT Cadena codificada

tipos de medios en UTF8
coincidentes
Datos binarios Un tipo de texto Establecida con Sin definir Cadena codificada
coincidentes
Datos binarios Un tipo de texto Establecida con CONVERT_TO_BINARY Datos binarios

tipos de medios
coincidentes
Datos binarios Un tipo de texto Establecida con CONVERT_TO_TEXT Cadena codificada

coincidentes
Datos binarios Un tipo binario Establecida con Sin definir Datos binarios
tipos de medios
coincidentes
Datos binarios Un tipo binario Establecida con CONVERT_TO_BINARY Datos binarios

tipos de medios
coincidentes
96
Carga de Encabezado binaryMediaTypes contentHandling Carga de

respuesta de Accept de solicitud respuesta de
integración método
Datos binarios Un tipo binario Establecida con CONVERT_TO_TEXT Cadena codificada

coincidentes
Tip
Cuando una solicitud contiene varios tipos de medios en su encabezado Accept, API Gateway
solo respeta el primer tipo de medio Accept. En aquella situación en la que no pueda controlar
el orden de los tipos de medios Accept y el tipo de medio del contenido binario no sea el primero
de la lista, puede añadir el primer tipo de medio Accept en la lista binaryMediaTypes de la API;
API Gateway devolverá su contenido como binario. Por ejemplo, para enviar un archivo JPEG
utilizando un elemento <img> en un navegador, el navegador puede enviar Accept:image/
webp,image/*,*/*;q=0.8 en una solicitud. Al añadir image/webp a la lista binaryMediaTypes, el
punto de enlace recibirá el archivo JPEG como binario.
Cuando se convierte una carga de texto en un blob binario, API Gateway asume que los datos de texto son
una cadena codificada en Base64 y envía los datos binarios como un blob descodificado en Base64. Si la
conversión produce un error, devuelve una respuesta 500 que indica un error de configuración de la API.
No tiene que proporcionar una plantilla de asignación para este tipo de conversión, pero sí debe habilitar
los comportamiento de paso a través (p. 150) en la API.
Al convertir una carga binaria en una cadena de texto, API Gateway siempre aplica una codificación
en Base64 a los datos binarios. Puede definir una plantilla de asignación para este tipo de carga, pero
solo puede tener acceso a la cadena codificada en Base64 en la plantilla de asignación a través de
$input.body, tal y como se muestra en el fragmento siguiente de una plantilla de asignación de ejemplo.
{
"data": "$input.body"
}
Para que se transfiera la carga binaria sin modificaciones, debe habilitar los comportamientos de paso a
través (p. 150) en la API.
Habilitar la compatibilidad con datos binarios mediante la consola

de API Gateway
En esta sección se explica cómo habilitar la compatibilidad con datos binarios en la consola de API
Gateway. A modo de ejemplo, usaremos una API integrada con Amazon S3. Nos centraremos en las
tareas para establecer tipos de medios compatibles y para especificar cómo debe manejarse la carga. Para
obtener información detallada sobre cómo crear una API integrada con Amazon S3, consulte Crear una
API como un proxy de Amazon S3 (p. 413).
Para habilitar la compatibilidad con datos binarios mediante la consola de API Gateway
1. Establezca tipos de medios binarios para la API:
a. Cree una nueva API o elija una API existente. En este ejemplo, asignaremos a la API el nombre
de FileMan.
b. Elija Binary Support en la API.
c. En el panel Binary Support, elija Edit.
97
d. Elija Add binary media types y escriba el tipo MIME que se va a admitir para la API.
e. Seleccione Save.
2. Establezca cómo se administran las cargas de mensajes para el método de API:
a. Cree un nuevo recurso o elija uno existente en la API. Para este ejemplo, usaremos el recurso /
{folder}/{item}.
b. Cree un nuevo método o elija uno existente en el recurso. Como ejemplo, usaremos el método
GET /{folder}/{item} integrado con la acción Object GET en Amazon S3.
c. En Content Handling, elija una opción.
98
Elija Passthrough si no desea convertir el cuerpo cuando el cliente y el backend acepten el mismo
formato binario. Elija Convert to text (if needed) para convertir el cuerpo binario en una cadena
codificada en Base64 cuando, por ejemplo, el backend requiera que una carga de solicitud binaria
se pase como una propiedad JSON. Y elija Convert to binary (if needed) cuando el cliente envíe
una cadena codificada en Base64 y el backend requiera el formato binario original, o cuando el
punto de enlace devuelva una cadena codificada en Base64 y el cliente acepte únicamente la
salida binaria.
d. Conserve el encabezado Accept de la solicitud entrante en la solicitud de integración. Debe
hacerlo si ha establecido contentHandling en passthrough y desea invalidar esa configuración
en tiempo de ejecución.
99
e. Active el comportamiento de paso a través en el cuerpo de la solicitud.
f. Para la conversión en texto, defina una plantilla de asignación para aplicar a los datos binarios
codificados en Base64 el formato requerido.
100
El formato de esta plantilla de asignación depende de los requisitos de punto de enlace de la

entrada.
Habilitar la compatibilidad con datos binarios mediante la API

REST de API Gateway
Las siguientes tareas muestran cómo habilitar la compatibilidad con datos binarios mediante llamadas a la
API REST de API Gateway.
Temas
• Añadir y actualizar tipos de medios binarios compatibles en una API (p. 102)
• Configurar las conversiones de carga de solicitud (p. 102)
• Configurar conversiones de carga de respuesta (p. 102)
• Convertir datos binarios en datos de texto (p. 103)
• Convertir datos de texto en una carga binaria (p. 103)
• Transferir una carga binaria (p. 104)
101
Añadir y actualizar tipos de medios binarios compatibles en una API

Para habilitar API Gateway para que admita un nuevo tipo de medios binarios, debe añadir el tipo de
medios binarios a la lista binaryMediaTypes del recurso RestApi. Por ejemplo, para que API Gateway
admita imágenes JPEG, envíe una solicitud PATCH al recurso RestApi:
PATCH /restapis/<restapi_id>
{
"op" : "add",
"path" : "/binaryMediaTypes/image~1jpeg"
}
]
}
La especificación del tipo MIME de image/jpeg que forma parte del valor de la propiedad path se ha
incluido en una secuencia de escape: image~1jpeg.
Para actualizar los tipos de medios binarios compatibles, sustituya o elimine el tipo de medios en la
lista binaryMediaTypes del recurso RestApi. Por ejemplo, para cambiar la compatibilidad binaria de
archivos JPEG a bytes sin formato, envíe una solicitud PATCH al recurso RestApi, tal y como se indica a
continuación.
{
"patchOperations" : [{
"op" : "replace",
"path" : "/binaryMediaTypes/image~1jpeg",
"value" : "application/octet-stream"
},
{
"op" : "remove",
"path" : "/binaryMediaTypes/image~1jpeg"
}]
}
Configurar las conversiones de carga de solicitud

Si el punto de enlace requiere una entrada binaria, establezca la propiedad contentHandling del recurso
Integration en CONVERT_TO_BINARY. Para ello, envíe una solicitud PATCH, tal y como se muestra a
continuación:
PATCH /restapis/<restapi_id>/resources/<resource_id>/methods/<http_method>/integration
{
"op" : "replace",
"path" : "/contentHandling",
"value" : "CONVERT_TO_BINARY"
}]
}
Configurar conversiones de carga de respuesta

Si el cliente acepta el resultado como un blob binario en lugar de una carga codificada en Base64 devuelta
por el punto de enlace, establezca la propiedad contentHandling del recurso IntegrationResponse en
CONVERT_TO_BINARY enviando una solicitud PATCH, tal y como se muestra a continuación:
102
PATCH /restapis/<restapi_id>/resources/<resource_id>/methods/<http_method>/integration/
responses/<status_code>
{
"op" : "replace",
"path" : "/contentEncoding",
}]
}
Convertir datos binarios en datos de texto

Para enviar datos binarios como una propiedad JSON de la entrada a AWS Lambda o Kinesis a través de
API Gateway, haga lo siguiente:
1. Habilite la compatibilidad de carga binaria de la API añadiendo el nuevo tipo de medios binarios de
application/octet-stream a la lista binaryMediaTypes de la API.
{
"op" : "add",
"path" : "/binaryMediaTypes/application~1octet-stream"
}
]
}
2. Establezca CONVERT_TO_TEXT en la propiedad contentHandling del recurso Integration y proporcione

una plantilla de asignación para asignar la cadena codificada en Base64 de los datos binarios a una
propiedad JSON. En el siguiente ejemplo, la propiedad JSON es body y $input.body contiene la
cadena codificada en Base64.
{
"patchOperations" : [
{
"op" : "replace",
"value" : "CONVERT_TO_TEXT"
},
{
"op" : "add",
"path" : "/requestTemplates/application~1octet-stream",
"value" : "{\"body\": \"$input.body\"}"
}
]
}
Convertir datos de texto en una carga binaria

Supongamos que tiene una función Lambda que devuelve un archivo de imagen como una cadena
codificada en Base64. Para pasar esta salida binaria al cliente a través de API Gateway, haga lo siguiente:
1. Actualice la lista binaryMediaTypes de la API añadiendo el tipo de medios binarios de application/

octet-stream, si aún no está en la lista.
103
{
"op" : "add",
"path" : "/binaryMediaTypes/application~1octet-stream",
}]
}
2. Establezca la propiedad contentHandling del recurso Integration en CONVERT_TO_BINARY. No defina

una plantilla de asignación. Cuando no define una plantilla de asignación, API Gateway llama a la
plantilla de paso a través para devolver el blob binario descodificado en Base64 como el archivo de
imagen al cliente.
PATCH /restapis/<restapi_id>/resources/<resource_id>/methods/<http_method>/integration/
responses/<status_code>
{
{
"op" : "replace",
"value" : "CONTVERT_TO_BINARY"
}
]
}
Transferir una carga binaria

Para almacenar una imagen en un bucket de Amazon S3 utilizando API Gateway, haga lo siguiente:
1. Actualice la lista binaryMediaTypes de la API añadiendo el tipo de medios binarios de application/

octet-stream, si aún no está en la lista.
{
"op" : "add",
"path" : "/binaryMediaTypes/application~1octet-stream"
}
]
}
2. En la propiedad contentHandling del recurso Integration, establezca CONVERT_TO_BINARY. Establezca

WHEN_NO_MATCH como el valor de la propiedad passthroughBehavior sin definir una plantilla de
asignación. Esto permite a API Gateway invocar la plantilla de paso a través.
{
{
"op" : "replace",
},
{
"op" : "replace",
104
"path" : "/passthroughBehaviors",
"value" : "WHEN_NO_MATCH"
}
]
}
Importar y exportar codificaciones de contenido

Para importar la lista binaryMediaTypes de un recurso RestApi, use la siguiente extensión de API
Gateway al archivo de definición de Swagger de la API. La extensión también se utiliza para exportar la
configuración de la API.
• Propiedad x-amazon-apigateway-binary-media-types (p. 378)
Para importar y exportar los valores de la propiedad contentHandling en un recurso Integration o

IntegrationResponse , utilice las siguientes extensiones de API Gateway a las definiciones de Swagger:
• Objeto x-amazon-apigateway-integration (p. 382)

• Objeto x-amazon-apigateway-integration.response (p. 388)
Ejemplos de compatibilidad con datos binarios

El siguiente ejemplo ilustra cómo obtener acceso a un archivo binario en Amazon S3 o AWS Lambda a
través de una API de API Gateway. La API de ejemplo se presenta en un archivo de Swagger. El ejemplo
de código usa llamadas a la API REST de API Gateway.
Temas
• Acceso a archivos binarios en Amazon S3 a través de una API de API Gateway (p. 105)
• Acceso a archivos binarios en Lambda mediante una API de API Gateway (p. 109)
Acceso a archivos binarios en Amazon S3 a través de una API de API Gateway

Los siguientes ejemplos muestran el archivo de Swagger utilizado para obtener acceso a las imágenes en
Amazon S3, cómo descargar una imagen de Amazon S3 y cómo cargar una imagen en Amazon S3.
Temas
• Archivo de Swagger de una API de ejemplo para obtener acceso a imágenes en Amazon S3 (p. 105)
• Descargar una imagen de Amazon S3 (p. 107)
• Cargar una imagen en Amazon S3 (p. 108)
Archivo de Swagger de una API de ejemplo para obtener acceso a imágenes en Amazon S3
El siguiente archivo de Swagger muestra una API de ejemplo que ilustra cómo descargar un archivo de
imagen de Amazon S3 y cargarlo en Amazon S3. Esta API expone los métodos GET /s3?key={file-name}
y PUT /s3?key={file-name} para descargar y cargar un archivo de imagen especificado. El método GET
devuelve el archivo de imagen como una cadena codificada en Base64 como parte de una salida JSON,
siguiendo la plantilla de asignación suministrada, en una respuesta 200 OK. El método PUT toma un blob
binario sin formato como entrada y devuelve una respuesta 200 OK con una carga vacía.
{
"swagger": "2.0",
"info": {
105
"version": "2016-10-21T17:26:28Z",
"title": "ApiName"
},
"host": "abcdefghi.execute-api.us-east-1.amazonaws.com",
"basePath": "/v1",
"schemes": [
"https"
],
"paths": {
"/s3": {
"get": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "key",
"in": "query",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"description": "200 response",
"schema": {
"$ref": "#/definitions/Empty"
}
},
"500": {
}
},
"credentials": "arn:aws:iam::123456789012:role/binarySupportRole",
"responses": {
"default": {
"statusCode": "500"
},
"2\\d{2}": {
"statusCode": "200" }
},
"requestParameters": {
"integration.request.path.key": "method.request.querystring.key"
},
"uri": "arn:aws:apigateway:us-west-2:s3:path/{key}",
"type": "aws"
}
},
"put": {
"produces": [
"application/json", "application/octet-stream"
],
"parameters": [
{
"name": "key",
"in": "query",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
106
"schema": {
}
},
"500": {
}
},
"responses": {
"default": {
"statusCode": "500"
},
"2\\d{2}": {
"statusCode": "200"
}
},
"integration.request.path.key": "method.request.querystring.key"
},
"uri": "arn:aws:apigateway:us-west-2:s3:path/{key}",
"httpMethod": "PUT",
"type": "aws",
"contentHandling" : "CONVERT_TO_BINARY"
}
}
}
},
"x-amazon-apigateway-binary-media-types" : ["application/octet-stream", "image/jpeg"],
"definitions": {
"Empty": {
"type": "object",
"title": "Empty Schema"
}
}
}
Descargar una imagen de Amazon S3

Para descargar un archivo de imagen (image.jpg) como un blob binario desde Amazon S3:
GET /v1/s3?key=image.jpg HTTP/1.1

Host: abcdefghi.execute-api.us-east-1.amazonaws.com
Accept: application/octet-stream
Una respuesta correcta tiene un aspecto similar al siguiente:
200 OK HTTP/1.1
[raw bytes]
Los bytes sin procesar se devuelven, ya que el encabezado Accept está establecido en un tipo de medio
binario de application/octet-stream y la compatibilidad con los datos binarios está habilitada para la
API.
Para descargar un archivo de imagen (image.jpg) como una cadena codificada en Base64 con formato
de propiedad JSON, también puede, en Amazon S3, añadir una plantilla de respuesta a la respuesta de
integración 200 tal y como se muestra en el bloque de definición de Swagger que aparece en negrita a
continuación:
107
"responses": {
"default": {
"statusCode": "500"
},
"2\\d{2}": {
"responseTemplates": {
"application/json": "{\n \"image\": \"$input.body\"\n}"
}
}
},
La solicitud para descargar el archivo de imagen se parece a esta:

Accept: application/json
200 OK HTTP/1.1
{
"image": "W3JhdyBieXRlc10="
}
Cargar una imagen en Amazon S3
Para cargar un archivo de imagen (image.jpg) como un blob binario en Amazon S3:
PUT /v1/s3?key=image.jpg HTTP/1.1

Content-Type: application/octet-stream
[raw bytes]
200 OK HTTP/1.1
Para cargar un archivo de imagen (image.jpg) como una cadena codificada en Base64 en Amazon S3:

W3JhdyBieXRlc10=
Observe que la carga de entrada debe ser una cadena codificada en Base64, ya que el valor del
encabezado Content-Type está establecido en application/json. Una respuesta correcta tiene un
108
200 OK HTTP/1.1
Acceso a archivos binarios en Lambda mediante una API de API Gateway

El siguiente ejemplo ilustra cómo obtener acceso a un archivo binario en AWS Lambda a través de una
API de API Gateway. La API de ejemplo se presenta en un archivo de Swagger. El ejemplo de código usa
llamadas a la API REST de API Gateway.
Temas
• Archivo de Swagger de una API de ejemplo para obtener acceso a imágenes en Lambda (p. 109)
• Descargar una imagen de Lambda (p. 111)
• Cargar una imagen en Lambda (p. 111)
Archivo de Swagger de una API de ejemplo para obtener acceso a imágenes en Lambda
El siguiente archivo de Swagger muestra una API de ejemplo que ilustra cómo descargar un archivo de
imagen de Lambda y cargarlo en Lambda.
{
"swagger": "2.0",
"info": {
"version": "2016-10-21T17:26:28Z",
"title": "ApiName"
},
"host": "abcdefghi.execute-api.us-east-1.amazonaws.com",
"basePath": "/v1",
"schemes": [
"https"
],
"paths": {
"/lambda": {
"get": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "key",
"in": "query",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
},
"500": {
}
},
"uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/
arn:aws:lambda:us-east-1:123456789012:function:image/invocations",
"type": "AWS",
"credentials": "arn:aws:iam::123456789012:role/Lambda",
"httpMethod": "POST",
109
"requestTemplates": {
"application/json": "{\n \"imageKey\": \"$input.params('key')\"\n}"
},
"responses": {
"default": {
"statusCode": "500"
},
"2\\d{2}": {
"application/json": "{\n \"image\": \"$input.body\"\n}"
}
}
}
}
},
"put": {
"produces": [
"application/json", "application/octet-stream"
],
"parameters": [
{
"name": "key",
"in": "query",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
},
"500": {
}
},
arn:aws:lambda:us-east-1:123456789012:function:image/invocations",
"type": "AWS",
"credentials": "arn:aws:iam::123456789012:role/Lambda",
"contentHandling" : "CONVERT_TO_TEXT",
"application/json": "{\n \"imageKey\": \"$input.params('key')\", \"image\":
\"$input.body\"\n}"
},
"responses": {
"default": {
"statusCode": "500"
},
"2\\d{2}": {
"statusCode": "200"
}
}
}
}
}
},
"x-amazon-apigateway-binary-media-types" : ["application/octet-stream", "image/jpeg"],
"definitions": {
"Empty": {
"type": "object",
110

}
}
}
Descargar una imagen de Lambda
Para descargar un archivo de imagen (image.jpg) como un blob binario desde Lambda:

Accept: application/octet-stream
200 OK HTTP/1.1
[raw bytes]
Para descargar un archivo de imagen (image.jpg) como una cadena codificada en Base64, formateada
como una propiedad JSON, desde Lambda:

200 OK HTTP/1.1
{
"image": "W3JhdyBieXRlc10="
}
Cargar una imagen en Lambda
Para cargar un archivo de imagen (image.jpg) como un blob binario en Lambda:

Content-Type: application/octet-stream
[raw bytes]
200 OK
Para cargar un archivo de imagen (image.jpg) como una cadena codificada en Base64 en Lambda:

111
Configurar una integración simulada para un método
W3JhdyBieXRlc10=
200 OK

en API Gateway
Amazon API Gateway admite integraciones simuladas para los métodos de la API. Esta característica
permite a los desarrolladores de API generar respuestas de API directamente desde API Gateway sin
necesidad de un backend de integración. Como desarrollador de una API, puede utilizar esta característica
para que otros equipos dependientes puedan trabajar con una API antes de que se complete el desarrollo
del proyecto. También puede usar esta característica para aprovisionar una página de inicio para la API,
en la que se proporcione una descripción general de la API y cómo navegar por ella. Para ver un ejemplo
de una página de inicio como esta, consulte la solicitud y la respuesta de integración del método GET
en el recurso raíz de la API de ejemplo que se describe en Crear una API de API Gateway a partir de un
ejemplo (p. 9).
Como desarrollador de una API, puede decidir cómo API Gateway responde a una solicitud de integración
simulada. Para ello, configura la solicitud de integración y la respuesta de integración del método para
asociar una respuesta a un código de estado determinado. Las tareas implican configurar una plantilla de
asignación en la solicitud de integración para especificar un código de estado admitido en la carga de la
solicitud y configurar plantillas de asignación, una para cada código de estado admitido, en la respuesta de
integración para proporcionar las cargas de la respuesta asociadas. En tiempo de ejecución API Gateway
recupera el código de estado de la carga de la solicitud e invoca la plantilla de asignación para devolver
la carga de la respuesta asociada. El tipo de contenido de la carga de la solicitud de integración debe ser
application/json y su formato debe ser {"statusCode": ddd, ... }, donde ddd representa un código
de estado HTTP. El tipo de contenido de la carga de la respuesta de integración puede ser cualquier tipo
que coincida con los datos de la respuesta, incluido application/json, application/xml, text/html,
text/plain etc.
En esta sección, aprenderá a utilizar la consola de API Gateway para habilitar la integración simulada para
un método de la API.
Temas
• Habilitar la integración simulada en un método (p. 112)
• Plantillas de solicitud de ejemplo (p. 114)
• Plantillas de respuesta de ejemplo (p. 114)
Requisitos previos
• El método debe estar disponible en API Gateway. Siga las instrucciones en Cree una API de API
Habilitar la integración simulada en un método

1. Elija un recurso de API y cree un método. En el panel Setup, elija Mock Integration y, a continuación,
elija Save.
112
2. En el panel Method Execution, elija Integration Request.

3. De forma predeterminada, las integraciones simuladas devuelven un código de estado HTTP 200.
Para personalizar este comportamiento predeterminado, haga lo siguiente:
1. Amplíe Mapping Templates.

2. En Content-Type, lleve a cabo alguna de las siguientes operaciones:
• Si el tipo de contenido deseado ya está visible (por ejemplo, application/json), elíjalo.

• Si el tipo de contenido deseado aún no está visible, elija Add mapping template, escriba el tipo
de contenido que desee (por ejemplo, application/json) y, a continuación, elija Create.
3. En el editor Template, escriba el contenido de la plantilla que desea que API Gateway utilice
para determinar el código de estado HTTP que se va a utilizar en la respuesta de integración.
La plantilla debe producir una carga JSON con la propiedad statusCode. Para obtener más
información, consulte Plantillas de solicitud de ejemplo (p. 114).
4. Junto a Mapping template, elija Save.
4. Para cada uno de los parámetros de cadena de consulta o de encabezado que desee añadir al
método, haga lo siguiente:
1. Elija Method Execution y, a continuación, elija Method Request.

2. Elija la flecha situada junto a URL Query String Parameters o HTTP Request Headers y, a
continuación, elija Add query string o Add header, respectivamente.
3. Para Name, escriba el nombre del parámetro de cadena de consulta o de encabezado y, a
continuación, elija Create a new query string o Create, respectivamente.
Note
Para eliminar un parámetro de cadena de consulta o de encabezado, seleccione Cancel

o Remove. Para cambiar el nombre de un parámetro de cadena de consulta o de
encabezado, debe eliminarlo y crear uno nuevo en su lugar.
5. Elija Method Execution y, a continuación, elija Method Response.
• Si todas las entradas de HTTP Status que desea usar ya están visibles (por ejemplo, 200), vaya al
paso 8.
• Si alguna de las entradas de HTTP Status que desea utilizar aún no están visibles, para cada
entrada de HTTP Status que falta, elija Add Response, elija el código de estado HTTP que desea
utilizar y, a continuación, elija Create.
7. Elija Method Execution y, a continuación, elija Integration Response.
• Si todas las entradas de Method response status que desea usar ya están visibles (por ejemplo,
200), vaya al paso 10.
• Si alguna de las entradas de Method response status que desea utilizar aún no está visible, para
cada entrada de Method response status que falta, elija Add integration response, para Method
response status elija la entrada HTTP Status que creó anteriormente y, a continuación, elija Save.
9. Para cada entrada de Method response status que desee utilizar, haga lo siguiente:
1. Expanda la fila correspondiente a la entrada Method response status que desea utilizar.
2. En HTTP status regex, escriba la entrada de HTTP Status coincidente (por ejemplo, escriba 400
para una entrada 400 HTTP Status o 500 para una entrada 500 HTTP Status). O bien especifique
un intervalo de códigos de estado HTTP (por ejemplo, 5\d{2} coincide con todos los códigos de
estado HTTP 5XX).
3. Amplíe Mapping Templates.
4. En Content-Type, lleve a cabo alguna de las siguientes operaciones:
113
• Si el tipo de contenido deseado ya está visible (por ejemplo, application/json), elíjalo.

• Si el tipo de contenido deseado aún no está visible, elija Add mapping template, escriba el tipo
de contenido que desee (por ejemplo, application/json) y, a continuación, elija Create.
5. En el editor Template, escriba el contenido de la plantilla que desea que API Gateway utilice para
responder al intermediario. Para obtener más información, consulte Plantillas de respuesta de
ejemplo (p. 114).
6. Junto a Mapping template, elija Save.
10. Realice una de las siguientes operaciones para probar el método:
• Llame al método desde la consola de API Gateway. Siga las instrucciones en Usar la consola para
probar un método (p. 348).
• Llame al método desde un navegador web, una herramienta de proxy de depuración web o la
herramienta de línea de comandos cURL, o desde su propia API. Siga las instrucciones en Llamar a
una API (p. 347).
Plantillas de solicitud de ejemplo

El siguiente ejemplo muestra una plantilla de solicitud que siempre utiliza el código de estado HTTP 200.
{
"statusCode": 200
}
El siguiente ejemplo muestra una plantilla de solicitud que utiliza el código de estado HTTP 200 si la
solicitud especifica el parámetro petType cat; 400 si la solicitud especifica dog; y 500, en caso contrario.
Este ejemplo se basa en el de Asignar parámetros de solicitudes (p. 25).
{
#if( $input.params('petType') == "cat" )
"statusCode": 200
#elseif( $input.params('petType') == "dog" )
"statusCode": 400
#else
"statusCode": 500
#end
}
Plantillas de respuesta de ejemplo

Los siguientes dos ejemplos muestran plantillas de respuesta que responden con la misma información
cada vez. Estos ejemplos se basan en el de Asignar parámetros de solicitudes (p. 25).
## Example 400 response.

{
"Message": "Error: petType not valid."
}
## Example 500 response.

{
"Message": "Error: petType not valid or not specified."
}
114
Configuración de la integración del proxy
El siguiente ejemplo muestra una plantilla de respuesta que responde con la misma información cada vez,
pero incluye el valor que especificó el intermediario para el parámetro petType. Este ejemplo se basa en el
de Asignar parámetros de solicitudes (p. 25).
## Example 200 response for ?petType=cat (response will contain "type": "cat").
{
"id": 1,
"name": "Kitty",
"type": "$input.params('petType')"
}
Configuración de la integración del proxy de API

Gateway
Para configurar un recurso de proxy en una API de API Gateway con una integración de proxy, realiza las
tres tareas siguientes:
• Crear un recurso de proxy con la variable de ruta expansiva {proxy+}

• Establecer el método ANY en el recurso de proxy
• Integrar el recurso y el método con un backend mediante el tipo de integración HTTP o Lambda
Note
Las variables de ruta expansiva, los métodos ANY y los tipos de integración de proxy son
características independientes, aunque se utilizan normalmente juntas. Puede configurar un
método HTTP específico en un recurso expansivo o aplicar tipos de integración distintos de proxy
en un recurso de proxy.
API Gateway establece determinadas restricciones y limitaciones al manipular métodos con una
integración de proxy Lambda o una integración de proxy HTTP. Para obtener más información, consulte
Problemas conocidos (p. 474).
Note
Cuando se utilice la integración con paso a través, API Gateway devolverá el encabezado
Content-Type:application/json predeterminado si no se especifica el tipo de contenido de una
carga.
Temas
• Recurso de proxy de API Gateway (p. 115)
• Tipos de integración de proxy de API Gateway (p. 116)
• Configurar un recurso de proxy con la integración de proxy HTTP (p. 116)
• Configurar un recurso de proxy con la integración de proxy Lambda (p. 120)
• Formato de entrada de una función Lambda para la integración de proxy (p. 121)
• Formato de salida de una función Lambda para la integración de proxy (p. 123)
Recurso de proxy de API Gateway

API Gateway define un recurso proxy como un marcador de posición para especificar un recurso a la hora
de enviar la solicitud. Un recurso proxy de API Gateway tiene las siguientes propiedades:
115
• Un parámetro de ruta especial indicado como {proxy+}. Este parámetro de ruta representa cualquiera
de los recursos secundarios bajo el recurso principal de una API. En otras palabras, /parent/{proxy
+} puede representar cualquier recurso que coincida con el patrón de ruta de /parent/*. El símbolo +
indica a API Gateway que intercepte todas las solicitudes sobre el recurso coincidente. Este parámetro
de ruta especial también se conoce como "variable de ruta expansiva". La variable proxy es el nombre
de la variable de ruta expansiva y puede reemplazarse por otra cadena como cualquier otro nombre de
parámetro de ruta.
• Un método especial, denominado ANY, que se utiliza para definir la misma integración configurada para
todos los métodos admitidos: DELETE, GET, HEAD, OPTIONS, PATCH, POST y PUT.
Puede definir un método de API en un recurso proxy y no proxy al mismo nivel de jerarquía que los
recursos de una API. Por ejemplo, puede exponer el método GET en los recursos /{ggg+} y /sss bajo
el recurso raíz (/) de la API. Cuando un cliente llama a GET /aaa, donde aaa es cualquier nombre de
recurso que no sean 'sss', la llamada se dirigirá a través GET /{ggg+} con un proxy de integración. En
otras palabras, cada solicitud de método en API Gateway de un recurso específico prevalece sobre la
solicitud de método similar de un recurso genérico en el mismo nivel de la jerarquía de recursos.
Tipos de integración de proxy de API Gateway

Un recurso de proxy es más eficaz cuando se integra con un backend que usa uno de los dos tipos
siguientes de integración de proxy:
• La integración de proxy HTTP, designada por HTTP_PROXY en la API REST de API Gateway, es para
la integración de una solicitud de método con un punto de enlace HTTP del backend. Con este tipo de
integración, API Gateway simplemente transmite toda la solicitud y la respuesta entre el frontend y el
backend, aunque esto está sujeto a determinadas restricciones y limitaciones (p. 474).
• La integración de proxy Lambda, designada por AWS_PROXY en la API REST de API Gateway, es para
la integración de una solicitud de método con una función Lambda en el backend. Con este tipo de
integración, API Gateway aplica una plantilla de asignación predeterminada para enviar toda la solicitud
a la función Lambda y transforma la salida de la función Lambda en respuestas HTTP.
Cuando aplica la integración de proxy HTTP a un recurso de proxy, puede configurar la API para que
exponga una parte o la totalidad de la jerarquía del punto de enlace HTTP del backend con una sola
integración configurada. Suponga, por ejemplo, que el sitio web del backend está organizado en varias
ramas de nodos de árbol desde el nodo raíz (/site) como: /site/a0/a1/.../aN, /site/b0/b1/.../bM, etc.
Si integra el método ANY en un recurso de proxy de /api/{proxy+} con los puntos de enlace del backend
con rutas URL /site/{proxy}, una sola solicitud de integración puede admitir todas las operaciones
HTTP (GET, POST, etc.) en cualquiera de los nodos [a0, a1, ..., aN, b0, b1, ...bM, ...]. Si aplica
una integración de proxy a un método HTTP específico (por ejemplo, GET), en su lugar, la solicitud de
integración resultante funcionará con las operaciones especificadas (por ejemplo, GET) en cualquiera de
los nodos del backend.
Del mismo modo, puede aplicar la integración de proxy Lambda a un recurso proxy de /api/{proxy+} para
configurar una sola integración, si desea que la función Lambda del backend reaccione individualmente a
los cambios que se produzcan en cualquiera de los recursos de la API bajo /api.
Configurar un recurso de proxy con la integración de proxy HTTP

Para configurar un recurso de proxy con el tipo de integración de proxy HTTP, cree un recurso de API
con el parámetro de ruta extensiva (p. ej., /parent/{proxy+}) e integre este recurso con un punto de
enlace HTTP del backend (por ejemplo, https://petstore-demo-endpoint.execute-api.com/petstore/
{proxy}) en el método ANY. El parámetro de ruta expansiva debe estar al final de la ruta del recurso.
Al igual que con un recurso distinto de proxy, puede configurar un recurso de proxy con la integración
de proxy HTTP mediante la consola de API Gateway, importando un archivo de definición de Swagger o
llamando a la API REST de API Gateway directamente. Para obtener instrucciones detalladas acerca de
116
cómo utilizar la consola de API Gateway para configurar un recurso de proxy con la integración HTTP,
consulte Creación y prueba de una API con integración de proxy HTTP (p. 54).
El siguiente archivo de definición de API de Swagger muestra un ejemplo de una API con un recurso de
proxy que está integrado en el sitio web PetStore.
{
"swagger": "2.0",
"info": {
"version": "2016-09-12T23:19:28Z",
"title": "PetStoreWithProxyResource"
},
"host": "4z9giyi2c1.execute-api.us-east-1.amazonaws.com",
"basePath": "/test",
"schemes": [
"https"
],
"paths": {
"/{proxy+}": {
"x-amazon-apigateway-any-method": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "proxy",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {},
"responses": {
"default": {
"statusCode": "200"
}
},
"integration.request.path.proxy": "method.request.path.proxy"
},
"uri": "http://petstore-demo-endpoint.execute-api.com/petstore/{proxy}",
"httpMethod": "ANY",
"cacheNamespace": "rbftud",
"cacheKeyParameters": [
"method.request.path.proxy"
],
"type": "http_proxy"
}
}
}
}
}
En este ejemplo, una clave de caché se declara en el parámetro de ruta method.request.path.proxy

del recurso de proxy. Esta es la configuración predeterminada al crear la API utilizando la consola de API
Gateway. La ruta base de la API (/test, correspondiente a una etapa) se asigna a la página PetStore del
sitio web (/petstore). La solicitud de integración sirve para replicar todo el sitio web PetStore utilizando
la variable de ruta expansiva de la API y el método catch-all ANY. Los siguientes ejemplos ilustran esta
replicación.
• Establecer ANY en GET y {proxy+} en pets
117
Solicitud de método iniciada desde el frontend:
GET https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test/pets HTTP/1.1
Solicitud de integración enviada al backend:
GET http://petstore-demo-endpoint.execute-api.com/petstore/pets HTTP/1.1
Las instancias en tiempo de ejecución del método ANY y el recurso de proxy son válidas. La llamada
devolverá una respuesta 200 OK con la carga que contiene el primer lote de mascotas, tal y como se
devuelve desde el backend.
• Establecer ANY en GET y {proxy+} en pets?type=dog
GET https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test/pets?type=dog HTTP/1.1
GET http://petstore-demo-endpoint.execute-api.com/petstore/pets?type=dog HTTP/1.1
devolverá una respuesta 200 OK con la carga que contiene el primer lote de perros especificados, tal y
como se devuelve desde el backend.
• Establecer ANY en GET y {proxy+} en pets/{petId}
GET https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test/pets/1 HTTP/1.1
GET http://petstore-demo-endpoint.execute-api.com/petstore/pets/1 HTTP/1.1
devolverá una respuesta 200 OK con la carga que contiene la mascota especificada, tal y como se
• Establecer ANY en POST y {proxy+} en pets
POST https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test/pets HTTP/1.1

Content-Length: ...
{
"type" : "dog",
"price" : 1001.00
}
POST http://petstore-demo-endpoint.execute-api.com/petstore/pets HTTP/1.1

118
Content-Length: ...
{
"type" : "dog",
"price" : 1001.00
}
devolverá una respuesta 200 OK con la carga que contiene la mascota recién creada, tal y como se
• Establecer ANY en GET y {proxy+} en pets/cat
GET https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test/pets/cat
GET http://petstore-demo-endpoint.execute-api.com/petstore/pets/cat
La instancia en tiempo de ejecución de la ruta del recurso de proxy no se corresponde con un punto de
enlace del backend y la solicitud resultante no es válida. Como resultado, se devuelve una respuesta 400
Bad Request con el siguiente mensaje de error.
{
"errors": [
{
"key": "Pet2.type",
"message": "Missing required field"
},
{
"key": "Pet2.price",
"message": "Missing required field"
}
]
}
• Establecer ANY en GET y {proxy+} en null
GET https://4z9giyi2c1.execute-api.us-west-2.amazonaws.com/test
GET http://petstore-demo-endpoint.execute-api.com/petstore
El recurso de destino es el elemento principal del recurso de proxy, pero la instancia en tiempo de
ejecución del método ANY no está definida en la API de ese recurso. Como resultado, esta solicitud GET
devuelve una respuesta 403 Forbidden con el mensaje de error "Missing Autenticación Token", devuelto
por API Gateway. Si la API expone el método ANY o GET en el recurso principal, (/), la llamada devolverá
una respuesta 404 Not Found con el mensaje Cannot GET /petstore, tal y como se devuelve desde el
backend.
119
Para cualquier solicitud cliente, si la URL del punto de enlace de destino no es válida o el verbo HTTP es
válido pero no es compatible, el backend devuelve una respuesta 404 Not Found. Para un método HTTP
no admitido, se devuelve una respuesta 403 Forbidden.
Configurar un recurso de proxy con la integración de proxy

Lambda
Para configurar un recurso de proxy con el tipo de integración de proxy Lambda, cree un
recurso de API con el parámetro de ruta expansiva (p. ej., /parent/{proxy+}) e integre
este recurso con un backend de función Lambda (por ejemplo, arn:aws:lambda:us-
west-2:123456789012:function:SimpleLambda4ProxyResource) en el método ANY. El parámetro de ruta
expansiva debe estar al final de la ruta del recurso de la API. Al igual que con un recurso que no es de
proxy, puede configurar el recurso de proxy mediante la consola de API Gateway importando un archivo de
definición de Swagger o llamando directamente a la API REST de API Gateway.
Para obtener instrucciones detalladas acerca de cómo utilizar la consola de API Gateway para configurar
un recurso de proxy con la integración de proxy Lambda, consulte Crear una API con la integración de
proxy Lambda a través de un Recurso de proxy (p. 59).
El siguiente archivo de definición de API de Swagger muestra un ejemplo de una API con un recurso de
proxy que se integra con la función Lambda SimpleLambda4ProxyResource (p. 60).
{
"swagger": "2.0",
"info": {
"version": "2016-09-12T17:50:37Z",
"title": "ProxyIntegrationWithLambda"
},
"host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
"basePath": "/testStage",
"schemes": [
"https"
],
"paths": {
"/{proxy+}": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "proxy",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {},
"responses": {
"default": {
"statusCode": "200"
}
},
arn:aws:lambda:us-east-1:123456789012:function:SimpleLambda4ProxyResource/invocations",
"cacheNamespace": "roq9wj",
"cacheKeyParameters": [
"method.request.path.proxy"
],
120
"type": "aws_proxy"
}
}
}
}
}
Con la integración de proxy Lambda, API Gateway asigna en tiempo de ejecución una solicitud entrante
en el parámetro de entrada event de la función Lambda. La entrada incluye el método de solicitud, la
ruta, los encabezados, todos los parámetros de consulta, todas las cargas, el contexto asociado y todas
las variables de etapa definidas. El formato de entrada se explica en Formato de entrada de una función
Lambda para la integración de proxy (p. 121). Para que API Gateway asigne la salida de Lambda a
respuestas HTTP correctamente, la función Lambda debe producir el resultado en el formato que se
explica en Formato de salida de una función Lambda para la integración de proxy (p. 123).
Con la integración de proxy Lambda de un recurso de proxy a través del método ANY, la función Lambda
del backend actúa como el controlador de eventos de todas las solicitudes a través del recurso de proxy.
Por ejemplo, para registrar patrones de tráfico, puede hacer que el dispositivo móvil envíe su ubicación en
cuanto al país, la ciudad, la calle y el edificio enviando una solicitud con /state/city/street/house en la
ruta URL del recurso de proxy. La función Lambda del backend puede analizar la ruta URL e insertar tuplas
de ubicación en una tabla de DynamoDB.
Formato de entrada de una función Lambda para la integración

de proxy
Con la integración de proxy Lambda, API Gateway mapea toda la solicitud cliente al parámetro de entrada
event de la función Lambda del backend de la siguiente manera:
{
"resource": "Resource path",
"path": "Path parameter",
"httpMethod": "Incoming request's method name"
"headers": {Incoming request headers}
"queryStringParameters": {query string parameters }
"pathParameters": {path parameters}
"stageVariables": {Applicable stage variables}
"requestContext": {Request context, including authorizer-returned key-value pairs}
"body": "A JSON string of the request payload."
"isBase64Encoded": "A boolean flag to indicate if the applicable request payload is
Base64-encode"
}
Vamos a ilustrar esto utilizando la siguiente solicitud POST con una API implementada en testStage con
una variable de etapa de stageVariableName=stageVariableValue:
POST /testStage/hello/world?name=me HTTP/1.1

Host: gy415nuibc.execute-api.us-east-1.amazonaws.com
headerName: headerValue
{
"a": 1
}
La solicitud anterior produce la siguiente carga de respuesta que contiene la salida devuelta por la función
Lambda del backend, donde input se ha establecido en el parámetro event de la función Lambda.
121
"message": "Hello me!",

"input": {
"resource": "/{proxy+}",
"path": "/hello/world",
"headers": {
"Accept": "*/*",
"Accept-Encoding": "gzip, deflate",
"cache-control": "no-cache",
"Content-Type": "application/json",
"headerName": "headerValue",
"Host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
"Postman-Token": "9f583ef0-ed83-4a38-aef3-eb9ce3f7a57f",
"User-Agent": "PostmanRuntime/2.4.5",
"Via": "1.1 d98420743a69852491bbdea73f7680bd.cloudfront.net (CloudFront)",
"X-Amz-Cf-Id": "pn-PWIJc6thYnZm5P0NMgOUglL1DYtl0gdeJky8tqsg8iS_sgsKD1A==",
"X-Forwarded-For": "54.240.196.186, 54.182.214.83",
"X-Forwarded-Proto": "https"
},
"queryStringParameters": {
"name": "me"
},
"pathParameters": {
"proxy": "hello/world"
},
"stageVariables": {
"stageVariableName": "stageVariableValue"
},
"requestContext": {
"accountId": "12345678912",
"resourceId": "roq9wj",
"stage": "testStage",
"requestId": "deef4878-7910-11e6-8f14-25afc3e9ae33",
"identity": {
"cognitoIdentityPoolId": null,
"accountId": null,
"cognitoIdentityId": null,
"caller": null,
"apiKey": null,
"sourceIp": "192.168.196.186",
"cognitoAuthenticationType": null,
"cognitoAuthenticationProvider": null,
"userArn": null,
"userAgent": "PostmanRuntime/2.4.5",
"user": null
},
"resourcePath": "/{proxy+}",
"apiId": "gy415nuibc"
},
"body": "{\r\n\t\"a\": 1\r\n}",
"isBase64Encoded": false
}
}
En la entrada de Lambda, el objeto requestContext es un mapa de pares de clave-valor, en el que la

clave es un nombre de propiedad de la variable $context (p. 158) y el valor es el valor de propiedad de
la variable $context correspondiente. API Gateway puede añadir nuevas claves al mapa. En función de
122
Después de configurar métodos e integraciones
las características habilitadas, el mapa requestContext puede variar de API en API. Por ejemplo, en el
ejemplo anterior, las propiedades $context.authorizer.* no están presentes porque no se ha habilitado
ningún autorizador personalizado para la API.
Note
API Gateway establece determinadas restricciones y limitaciones al manipular métodos con una
integración de proxy Lambda o una integración de proxy HTTP. Para obtener más información,
consulte Problemas conocidos (p. 474).
Formato de salida de una función Lambda para la integración de

proxy
Con la integración de proxy Lambda, API Gateway requiere que la función Lambda del backend devuelva
la salida de acuerdo con el siguiente formato JSON:
{
"isBase64Encoded": true|false,
"statusCode": httpStatusCode,
"headers": { "headerName": "headerValue", ... },
"body": "..."
}
donde headers puede no estar especificado si no se van a devolver más encabezados de respuesta. body
se serializará en el frontend como la carga de respuesta del método. Si body es un blob binario, puede
codificarlo como una cadena codificada en Base64 y establecer isBase64Encoded en true. De lo contrario,
puede establecerlo en false o dejarlo sin especificar.
Si la salida de la función tiene un formato diferente, API Gateway devolverá la respuesta de error 502 Bad
Gateway.
En una función Lambda de Node.js, para devolver una respuesta correcta, llame a callback(null,
{"statusCode": 200, "body": "results"}). Para producir una excepción, llame a callback(new
Error('internal server error')). En caso de un error del lado del cliente, por ejemplo, cuando falta
un parámetro necesario, puede llamar a callback(null, {"statusCode": 400, "body": "Missing
parameters of ..."}) para devolver el error sin producir una excepción.
Después de configurar métodos e integraciones

El siguiente paso consiste en implementar la API para abrir el acceso. Para obtener instrucciones, consulte
Implementar una API (p. 294).
Para configurar el control del acceso a la API, consulte Controlar el acceso en API Gateway (p. 221).
Crear modelos y plantillas de asignación para las

asignaciones de solicitud y respuesta
En API Gateway, una solicitud de método de API puede tomar una carga en un formato diferente de la
carga de solicitud de integración correspondiente que requiere el backend. Del mismo modo, el backend
puede devolver una carga de respuesta de integración diferente de la carga de respuesta del método que
espera el frontend. API Gateway le permite utilizar plantillas de asignación para asignar la carga de una
solicitud de método a la solicitud de integración correspondiente y de una respuesta de integración a la
respuesta del método correspondiente.
123
Modelos
Una plantilla de asignación es un script expresado en Velocity Template Language (VTL) que se aplica
a la carga mediante expresiones JSONPath. La carga puede tener un modelo de datos de acuerdo con
el esquema JSON. Debe definir el modelo para que API Gateway genere un SDK o para permitir la
validación de la solicitud básica para la API. No tiene que definir ningún modelo para crear una plantilla de
asignación. Sin embargo, un modelo puede ayudarle a crear una plantilla porque API Gateway generará un
esquema de plantilla basado en un modelo proporcionado.
En esta sección se explica cómo asignar la carga de solicitud y respuesta de la API mediante modelos y
plantillas de asignación.
Temas
• Modelos (p. 124)
• Plantillas de asignación (p. 127)
• Tareas de modelos y plantillas de asignación (p. 129)
• Crear un modelo en API Gateway (p. 130)
• Ver una lista de modelos en API Gateway (p. 130)
• Eliminar un modelo en API Gateway (p. 131)
• Ejemplo de fotos (modelos y plantillas de asignación de API Gateway) (p. 131)
• Ejemplo de artículo periodístico (modelos y plantillas de asignación de API Gateway) (p. 134)
• Ejemplo de factura de ventas (modelos y plantillas de asignación de API Gateway) (p. 138)
• Ejemplo de registro de empleado (modelos y plantillas de asignación de API Gateway) (p. 142)
Modelos
En API Gateway, un modelo define la estructura de datos de una carga. En API Gateway los modelos se
definen mediante el esquema JSON.
El siguiente objeto JSON describe datos de ejemplo que describen el inventario de frutas o verduras del
departamento de productos de un supermercado:
Supongamos que tenemos una API para administrar el inventario de frutas y verduras del departamento
de productos de un supermercado. Cuando un director consulte el backend para el inventario actual, el
servidor enviará la siguiente carga de respuesta:
{
"department": "produce",
"categories": [
"fruit",
"vegetables"
],
"bins": [
{
"category": "fruit",
"type": "apples",
"price": 1.99,
"unit": "pound",
"quantity": 232
},
{
"category": "fruit",
"type": "bananas",
"price": 0.19,
"unit": "each",
"quantity": 112
},
{
124
Modelos
"category": "vegetables",
"type": "carrots",
"price": 1.29,
"unit": "bag",
"quantity": 57
}
]
}
El objeto JSON tiene tres propiedades
• La propiedad department tiene un valor de cadena (produce).

• La propiedad categories es una matriz de dos cadenas: fruit y vegetables.
• La propiedad bins es un matriz de objetos, cada uno de los cuales tiene las propiedades de cadena o
número de category, type, price, unit y quantity.
Podemos utilizar el siguiente esquema JSON para definir el modelo de los datos anteriores:
{
"title": "GroceryStoreInputModel",
"type": "object",
"properties": {
"department": { "type": "string" },
"categories": {
"type": "array",
"items": { "type": "string" }
},
"bins": {
"type": "array",
"items": {
"type": "object",
"properties": {
"category": { "type": "string" },
"price": { "type": "number" },
"unit": { "type": "string" },
"quantity": { "type": "integer" }
}
}
}
}
}
En el modelo de ejemplo anterior:
• El objeto $schema representa un identificador de versión válido del esquema JSON. En este ejemplo, se
hace referencia al esquema JSON, borrador v4.
• El objeto title es un identificador descriptivo del modelo. En este ejemplo, es
GroceryStoreInputModel.
• La construcción de nivel superior o raíz de los datos JSON es un objeto.
• El objeto raíz de los datos JSON contiene las propiedades department, categories, y bins.
• La propiedad department es un objeto de cadena en los datos JSON.
• La propiedad categories es una matriz de los datos JSON. La matriz contiene valores de cadena de los
datos JSON.
• La propiedad bins es una matriz de los datos JSON. La matriz contiene objetos de los datos JSON.
Cada uno de estos objetos de los datos JSON contiene una cadena category, una cadena type, un
número price, una cadena unit y un entero quantity (un número sin fracción ni exponente).
125
Modelos
También puede incluir parte de este esquema, por ejemplo, la definición de elementos de la matriz bins,
en una sección independiente del mismo archivo y utilizar el elemento primitivo $ref para hacer referencia
a esta definición reutilizable en otras partes del esquema. Mediante $ref, el archivo de definición del
modelo anterior se puede expresar de la forma siguiente:
{
"type": "object",
"properties": {
"categories": {
"type": "array",
},
"bins": {
"type": "array",
"items": {
"$ref": "#/definitions/Bin"
}
}
},
"definitions": {
"Bin" : {
"type": "object",
"properties": {
}
}
}
}
La sección definitions contiene la definición de esquema del elemento Bin al que se hace referencia en
la matriz bins con "ref": "#/definitions/Bin". El uso de estas definiciones reutilizables permite que la
definición del modelo sea más fácil de leer.
Además, también puede hacer referencia a otro esquema de modelo definido en un archivo de modelo
externo configurando la URL de ese modelo como el valor de la propiedad $ref: "$ref": "https://
apigateway.amazonaws.com/restapis/{restapi_id}/models/{model_name}". Suponga, por ejemplo,
que tiene el siguiente modelo completo denominado Bin2 creado en una API con un identificador de
fugvjdxtri:
{
"type": "object",
"properties": {
"Bin" : {
"type": "object",
"properties": {
}
}
}
126
Plantillas de asignación
Puede hace referencia a él desde GroceryStoreInputModel desde la misma API, tal y como se muestra a
continuación:
{
"type": "object",
"properties": {
"categories": {
"type": "array",
},
"bins": {
"type": "array",
"items": {
"$ref": "https://apigateway.amazonaws.com/restapis/fugvjdxtri/models/Bin2"
}
}
}
}
El modelo que hace la referencia y el modelo al que se hace referencia deben proceder de la misma API.
Los ejemplos no utilizan características avanzadas del esquema JSON, como la especificación de
elementos necesarios; las longitudes de cadena mínimas y máximas, los valores numéricos y las
longitudes de los elementos de matriz; expresiones regulares; etc. Para obtener más información, consulte
Introducing JSON y JSON Schema.
Para ver formatos de datos JSON más complejos y sus modelos, consulte los siguientes ejemplos:
• Modelo de entrada (ejemplo de fotos) (p. 132) y Modelo de salida (ejemplo de fotos) (p. 133) en el
Ejemplo de fotos (p. 131)
• Modelo de entrada (ejemplo de artículo periodístico) (p. 135) y Modelo de salida (ejemplo de artículo
periodístico) (p. 137) en el Ejemplo de artículo periodístico (p. 134)
• Modelo de entrada (ejemplo de factura de ventas) (p. 139) y Modelo de salida (ejemplo de factura de
ventas) (p. 141) en el Ejemplo de factura de ventas (p. 138)
• Modelo de entrada (ejemplo de registro de empleado) (p. 143) y Modelo de salida (ejemplo de registro
de empleado) (p. 145) en el Ejemplo de registro de empleado (p. 142)
Para experimentar con modelos en API Gateway, siga las instrucciones de Asignar la carga de
respuesta (p. 33), en concreto Paso 1: Crear Modelos (p. 35).
Cuando el backend devuelve los resultados de la consulta (mostrados en la sección Modelos (p. 124)), al
director del departamento de productos tal vez le interese leerlos del siguiente modo:
{
"choices": [
{
"kind": "apples",
"suggestedPrice": "1.99 per pound",
"available": 232
},
{
"kind": "bananas",
127
"suggestedPrice": "0.19 per each",

"available": 112
},
{
"kind": "carrots",
"suggestedPrice": "1.29 per bag",
"available": 57
}
]
}
Para permitir esto, debemos proporcionar a API Gateway una plantilla de asignación que traduzca los
datos del formato del backend. La siguiente plantilla de asignación hará justamente eso.
{
"choices": [
#foreach($elem in $inputRoot.bins)
{
"kind": "$elem.type",
"suggestedPrice": "$elem.price per $elem.unit",
"available": $elem.quantity
#end
]
}
Analicemos ahora algunos detalles de la plantilla de asignación de salida anterior:
• La variable $inputRoot representa el objeto raíz en los datos JSON originales de la sección anterior. Las
variables de una plantilla de asignación de salida se asignan a los datos JSON originales, no al esquema
de datos JSON transformado deseado.
• La matriz choices de la plantilla de asignación de salida se asigna desde la matriz bins con el objeto
raíz de los datos JSON originales ($inputRoot.bins).
• En la plantilla de asignación de salida, cada uno de los objetos de la matriz choices (representados
por $elem) se asigna desde los objetos correspondientes de la matriz bins dentro del objeto raíz de los
datos JSON originales.
• En la plantilla de asignación de salida, para cada uno de los objetos del objeto choices, los valores de
los objetos kind y available (representados por $elem.type y $elem.quantity) se asignan desde los
valores correspondientes de los objetos type y value de cada uno de los objetos de la matriz bins de los
datos JSON originales, respectivamente.
• En la plantilla de asignación de salida, para cada uno de los objetos del objeto choices, el valor del
objeto suggestedPrice es una concatenación del valor correspondiente de los objetos price y unit de
cada uno de los objetos de los datos JSON originales, respectivamente, con cada valor separado por la
palabra per.
Para obtener más información sobre Velocity Template Language, consulte Apache Velocity - VTL
Reference. Para obtener más información sobre JSONPath, consulte JSONPath - XPath for JSON.
En la plantilla de asignación se asume que los datos subyacentes son de un objeto JSON. No se requiere
definir un modelo para los datos. Como desarrollador de API, conoce los formatos de los datos en el
frontend y en el backend. Ese conocimiento puede guiarle para definir las asignaciones necesarias sin
ambigüedad.
Para que se genere un SDK para la API, los datos anteriores se devolverán como un objeto específico
del lenguaje. Para lenguajes con establecimiento inflexible de tipos, como Java, Objective-C o Swift, el
objeto se corresponde con un tipo de datos definido por el usuario (UDT). API Gateway creará un UDT si
128
Tareas de modelos y plantillas de asignación
se le facilita con un modelo de datos. Para el ejemplo de respuesta del método anterior, puede definir el
siguiente modelo de carga en la respuesta de integración:
{
"title": "GroceryStoreOutputModel",
"type": "object",
"properties": {
"choices": {
"type": "array",
"items": {
"type": "object",
"properties": {
"kind": { "type": "string" },
"suggestedPrice": { "type": "string" },
"available": { "type": "integer" }
}
}
}
}
}
En este modelo, el esquema JSON se expresa del modo siguiente:
• El objeto $schema representa un identificador de versión válido del esquema JSON. En este ejemplo, se
hace referencia al esquema JSON, borrador v4.
• El objeto title es un identificador descriptivo del modelo. En este ejemplo, es
GroceryStoreOutputModel.
• La construcción de nivel superior o raíz de los datos JSON es un objeto.
• El objeto raíz de los datos JSON contiene una matriz de objetos.
• Cada objeto de la matriz de objetos contiene una cadena kind, una cadena suggestedPrice y un entero
available (un número sin fracción ni exponente).
Con este modelo, puede llamar a un SDK para recuperar los valores de las propiedades kind,
suggestedPrice y available leyendo las propiedades GroceryStoreOutputModel.kind,
GroceryStoreOutputModel.suggestedPrice y GroceryStoreOutputModel.available, respectivamente. Si
no se proporciona un modelo, API Gateway utilizará el modelo Empty para crear un UDT predeterminado.
En este caso, no podrá leer estas propiedades con un SDK con establecimiento inflexible de tipos.
Para examinar plantillas de asignación más complejas, consulte los siguientes ejemplos:
• Plantilla de asignación de entrada (ejemplo de fotos) (p. 132) y Plantilla de asignación de salida
(ejemplo de fotos) (p. 134) en el Ejemplo de fotos (p. 131)
• Plantilla de asignación de entrada (ejemplo de artículo periodístico) (p. 136) y Plantilla de asignación
de salida (ejemplo de artículo periodístico) (p. 137) en el Ejemplo de artículo periodístico (p. 134)
• Plantilla de asignación de entrada (ejemplo de factura de ventas) (p. 140) y Plantilla de asignación de
salida (ejemplo de factura de ventas) (p. 141) en el Ejemplo de factura de ventas (p. 138)
• Plantilla de asignación de entrada (ejemplo de registro de empleado) (p. 144) y Plantilla de asignación
de salida (ejemplo de registro de empleado) (p. 146) en el Ejemplo de registro de empleado (p. 142)
Para experimentar con plantillas de asignación en API Gateway, siga las instrucciones de Asignar la carga
de respuesta (p. 33), en concreto Paso 5: Configurar y probar los métodos (p. 40).
Tareas de modelos y plantillas de asignación

Para saber qué otras cosas puede hacer con los modelos y plantillas de asignación, consulte lo siguiente:
129
Crear un modelo
• Crear un modelo (p. 130)

• Ver una lista de modelos (p. 130)
• Eliminar un modelo (p. 131)
Crear un modelo en API Gateway

Utilice la consola de API Gateway para crear un modelo para una API.
Temas
• Crear un modelo con la consola de API Gateway (p. 130)
Requisitos previos
• Debe tener una API disponible en API Gateway. Siga las instrucciones en Crear una API (p. 73).
Crear un modelo con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API donde desee crear el modelo, elija Models.
4. En Model Name, escriba un nombre único para el modelo.
5. En Content Type, escriba el tipo de contenido del modelo (por ejemplo, application/json para
JSON).
6. (Opcional) En Model description, escriba una descripción para el modelo.
7. En Model schema, escriba el esquema del modelo. Para obtener más información sobre los
esquemas de modelo, consulte Crear modelos y plantillas de asignación para las cargas de solicitud y
respuesta (p. 123).
Ver una lista de modelos en API Gateway

Usar la consola de API Gateway para ver una lista de modelos.
Temas
• Ver una lista de modelos con la consola de API Gateway (p. 130)
Requisitos previos
• Debe tener al menos un modelo en API Gateway. Siga las instrucciones en Crear un
modelo (p. 130).
Ver una lista de modelos con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API, elija Modelos.
130
Eliminar un modelo
Eliminar un modelo en API Gateway

Use la consola de API Gateway para eliminar un modelo.
Warning
La eliminación de un modelo puede provocar que parte o la totalidad de la API correspondiente

quede inservible para los intermediarios de la API. La eliminación de un modelo no se puede
deshacer.
Eliminar un modelo con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API para el modelo, elija Models.
3. En el panel Models, elija el modelo que desea eliminar y, a continuación, elija Delete Model.
4. Cuando se le pregunte, elija Delete.
Ejemplo de fotos (modelos y plantillas de asignación

de API Gateway)
En las secciones siguientes se proporcionan ejemplos de modelos y plantillas de asignación que pueden
utilizarse para una API de fotos de ejemplo en API Gateway. Para obtener más información sobre los
modelos y plantillas de asignación en API Gateway, consulte Crear modelos y plantillas de asignación para
las cargas de solicitud y respuesta (p. 123).
Temas
• Datos originales (ejemplo de fotos) (p. 131)
• Modelo de entrada (ejemplo de fotos) (p. 132)
• Plantilla de asignación de entrada (ejemplo de fotos) (p. 132)
• Datos transformados (ejemplo de fotos) (p. 133)
• Modelo de salida (ejemplo de fotos) (p. 133)
• Plantilla de asignación de salida (ejemplo de fotos) (p. 134)
Datos originales (ejemplo de fotos)

A continuación se muestran los datos JSON originales para el ejemplo de fotos:
{
"photos": {
"page": 1,
"pages": "1234",
"perpage": 100,
"total": "123398",
"photo": [
{
"id": "12345678901",
"owner": "23456789@A12",
"secret": "abc123d456",
"server": "1234",
"farm": 1,
"title": "Sample photo 1",
131
Ejemplo de fotos
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "23456789012",
"owner": "34567890@B23",
"secret": "bcd234e567",
"server": "2345",
"farm": 2,
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
}
]
}
}
Modelo de entrada (ejemplo de fotos)

A continuación, se muestra el modelo de entrada que se corresponde con los datos JSON originales para
el ejemplo de fotos:
{
"title": "PhotosInputModel",
"type": "object",
"properties": {
"photos": {
"type": "object",
"properties": {
"page": { "type": "integer" },
"pages": { "type": "string" },
"perpage": { "type": "integer" },
"total": { "type": "string" },
"photo": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"owner": { "type": "string" },
"secret": { "type": "string" },
"server": { "type": "string" },
"farm": { "type": "integer" },
"title": { "type": "string" },
"ispublic": { "type": "integer" },
"isfriend": { "type": "integer" },
"isfamily": { "type": "integer" }
}
}
}
}
}
}
}
Plantilla de asignación de entrada (ejemplo de fotos)

A continuación, se muestra la plantilla de asignación de entrada que se corresponde con los datos JSON
originales para el ejemplo de fotos:
132
Ejemplo de fotos
{
"photos": {
"page": $inputRoot.photos.page,
"pages": "$inputRoot.photos.pages",
"perpage": $inputRoot.photos.perpage,
"total": "$inputRoot.photos.total",
"photo": [
#foreach($elem in $inputRoot.photos.photo)
{
"id": "$elem.id",
"owner": "$elem.owner",
"secret": "$elem.secret",
"server": "$elem.server",
"farm": $elem.farm,
"title": "$elem.title",
"ispublic": $elem.ispublic,
"isfriend": $elem.isfriend,
"isfamily": $elem.isfamily
#end
]
}
}
Datos transformados (ejemplo de fotos)

A continuación, se muestra un ejemplo de cómo se pueden transformar los datos JSON del ejemplo de
fotos original para producir el resultado:
{
"photos": [
{
"id": "12345678901",
"owner": "23456789@A12",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "23456789012",
"owner": "34567890@B23",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
}
]
}
Modelo de salida (ejemplo de fotos)

A continuación, se muestra el modelo de salida que se corresponde con el formato de datos JSON
transformados:
{
"title": "PhotosOutputModel",
"type": "object",
133
Ejemplo de artículo periodístico
"properties": {
"photos": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"owner": { "type": "string" },
"ispublic": { "type": "integer" },
"isfriend": { "type": "integer" },
"isfamily": { "type": "integer" }
}
}
}
}
}
Plantilla de asignación de salida (ejemplo de fotos)

A continuación, se muestra la plantilla de asignación de salida que se corresponde con el formato de datos
JSON transformados. Las variables de plantilla aquí se basan en el formato de datos JSON original, no en
el transformado:
{
"photos": [
#foreach($elem in $inputRoot.photos.photo)
{
"id": "$elem.id",
"owner": "$elem.owner",
"ispublic": $elem.ispublic,
"isfriend": $elem.isfriend,
"isfamily": $elem.isfamily
#end
]
}
Ejemplo de artículo periodístico (modelos y plantillas

de asignación de API Gateway)
utilizarse para una API de artículo periodístico de ejemplo en API Gateway. Para obtener más información
sobre los modelos y plantillas de asignación en API Gateway, consulte Crear modelos y plantillas de
asignación para las cargas de solicitud y respuesta (p. 123).
Temas
• Datos originales (ejemplo de artículo periodístico) (p. 135)
• Modelo de entrada (ejemplo de artículo periodístico) (p. 135)
• Plantilla de asignación de entrada (ejemplo de artículo periodístico) (p. 136)
• Datos transformados (ejemplo de artículo periodístico) (p. 136)
• Modelo de salida (ejemplo de artículo periodístico) (p. 137)
• Plantilla de asignación de salida (ejemplo de artículo periodístico) (p. 137)
134
Datos originales (ejemplo de artículo periodístico)

A continuación se presentan los datos JSON originales del ejemplo de artículo periodístico:
{
"count": 1,
"items": [
{
"last_updated_date": "2015-04-24",
"expire_date": "2016-04-25",
"author_first_name": "John",
"description": "Sample Description",
"creation_date": "2015-04-20",
"title": "Sample Title",
"allow_comment": "1",
"author": {
"last_name": "Doe",
"email": "[email protected]",
"first_name": "John"
},
"body": "Sample Body",
"publish_date": "2015-04-25",
"version": "1",
"author_last_name": "Doe",
"parent_id": 2345678901,
"article_url": "http://www.example.com/articles/3456789012"
}
],
"version": 1
}
Modelo de entrada (ejemplo de artículo periodístico)

el ejemplo de artículo periodístico:
{
"title": "NewsArticleInputModel",
"type": "object",
"properties": {
"count": { "type": "integer" },
"items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"last_updated_date": { "type": "string" },
"expire_date": { "type": "string" },
"author_first_name": { "type": "string" },
"description": { "type": "string" },
"creation_date": { "type": "string" },
"allow_comment": { "type": "string" },
"author": {
"type": "object",
"properties": {
"last_name": { "type": "string" },
"email": { "type": "string" },
"first_name": { "type": "string" }
}
},
135
"body": { "type": "string" },

"publish_date": { "type": "string" },
"version": { "type": "string" },
"author_last_name": { "type": "string" },
"parent_id": { "type": "integer" },
"article_url": { "type": "string" }
}
}
},
"version": { "type": "integer" }
}
}
Plantilla de asignación de entrada (ejemplo de artículo

periodístico)
originales para el ejemplo de artículo periodístico:
{
"count": $inputRoot.count,
"items": [
#foreach($elem in $inputRoot.items)
{
"last_updated_date": "$elem.last_updated_date",
"expire_date": "$elem.expire_date",
"author_first_name": "$elem.author_first_name",
"description": "$elem.description",
"creation_date": "$elem.creation_date",
"allow_comment": "$elem.allow_comment",
"author": {
"last_name": "$elem.author.last_name",
"email": "$elem.author.email",
"first_name": "$elem.author.first_name"
},
"body": "$elem.body",
"publish_date": "$elem.publish_date",
"version": "$elem.version",
"author_last_name": "$elem.author_last_name",
"parent_id": $elem.parent_id,
"article_url": "$elem.article_url"
#end
],
"version": $inputRoot.version
}
Datos transformados (ejemplo de artículo periodístico)

artículo periodístico original para producir el resultado:
{
"count": 1,
"items": [
{
"creation_date": "2015-04-20",
136
"title": "Sample Title",

"author": "John Doe",
"body": "Sample Body",
"publish_date": "2015-04-25",
"article_url": "http://www.example.com/articles/3456789012"
}
],
"version": 1
}
Modelo de salida (ejemplo de artículo periodístico)

transformados:
{
"title": "NewsArticleOutputModel",
"type": "object",
"properties": {
"count": { "type": "integer" },
"items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"creation_date": { "type": "string" },
"author": { "type": "string" },
"body": { "type": "string" },
"publish_date": { "type": "string" },
"article_url": { "type": "string" }
}
}
},
"version": { "type": "integer" }
}
}
Plantilla de asignación de salida (ejemplo de artículo periodístico)

el transformado:
{
"count": $inputRoot.count,
"items": [
#foreach($elem in $inputRoot.items)
{
"creation_date": "$elem.creation_date",
"author": "$elem.author.first_name $elem.author.last_name",
"body": "$elem.body",
"publish_date": "$elem.publish_date",
"article_url": "$elem.article_url"
#end
],
137
Ejemplo de factura de ventas
"version": $inputRoot.version
}
Ejemplo de factura de ventas (modelos y plantillas de

asignación de API Gateway)
utilizarse para una API de factura de ventas de ejemplo en API Gateway. Para obtener más información
sobre los modelos y plantillas de asignación en API Gateway, consulte Crear modelos y plantillas de
asignación para las cargas de solicitud y respuesta (p. 123).
Temas
• Datos originales (ejemplo de factura de ventas) (p. 138)
• Modelo de entrada (ejemplo de factura de ventas) (p. 139)
• Plantilla de asignación de entrada (ejemplo de factura de ventas) (p. 140)
• Datos transformados (ejemplo de factura de ventas) (p. 140)
• Modelo de salida (ejemplo de factura de ventas) (p. 141)
• Plantilla de asignación de salida (ejemplo de factura de ventas) (p. 141)
Datos originales (ejemplo de factura de ventas)

A continuación, se presentan los datos JSON originales del ejemplo de factura de ventas:
{
"DueDate": "2013-02-15",
"Balance": 1990.19,
"DocNumber": "SAMP001",
"Status": "Payable",
"Line": [
{
"Description": "Sample Expense",
"Amount": 500,
"DetailType": "ExpenseDetail",
"ExpenseDetail": {
"Customer": {
"value": "ABC123",
"name": "Sample Customer"
},
"Ref": {
"value": "DEF234",
"name": "Sample Construction"
},
"Account": {
"value": "EFG345",
"name": "Fuel"
},
"LineStatus": "Billable"
}
}
],
"Vendor": {
"value": "GHI456",
"name": "Sample Bank"
},
"APRef": {
"value": "HIJ567",
138
"name": "Accounts Payable"

},
"TotalAmt": 1990.19
}
Modelo de entrada (ejemplo de factura de ventas)

el ejemplo de factura de ventas:
{
"title": "InvoiceInputModel",
"type": "object",
"properties": {
"DueDate": { "type": "string" },
"Balance": { "type": "number" },
"DocNumber": { "type": "string" },
"Status": { "type": "string" },
"Line": {
"type": "array",
"items": {
"type": "object",
"properties": {
"Description": { "type": "string" },
"Amount": { "type": "integer" },
"DetailType": { "type": "string" },
"ExpenseDetail": {
"type": "object",
"properties": {
"Customer": {
"type": "object",
"properties": {
"value": { "type": "string" },
"name": { "type": "string" }
}
},
"Ref": {
"type": "object",
"properties": {
}
},
"Account": {
"type": "object",
"properties": {
}
},
"LineStatus": { "type": "string" }
}
}
}
}
},
"Vendor": {
"type": "object",
"properties": {
}
},
139
"APRef": {
"type": "object",
"properties": {
}
},
"TotalAmt": { "type": "number" }
}
}
Plantilla de asignación de entrada (ejemplo de factura de ventas)

originales para el ejemplo de factura de ventas:
{
"DueDate": "$inputRoot.DueDate",
"Balance": $inputRoot.Balance,
"DocNumber": "$inputRoot.DocNumber",
"Status": "$inputRoot.Status",
"Line": [
#foreach($elem in $inputRoot.Line)
{
"Description": "$elem.Description",
"Amount": $elem.Amount,
"DetailType": "$elem.DetailType",
"ExpenseDetail": {
"Customer": {
"value": "$elem.ExpenseDetail.Customer.value",
"name": "$elem.ExpenseDetail.Customer.name"
},
"Ref": {
"value": "$elem.ExpenseDetail.Ref.value",
"name": "$elem.ExpenseDetail.Ref.name"
},
"Account": {
"value": "$elem.ExpenseDetail.Account.value",
"name": "$elem.ExpenseDetail.Account.name"
},
"LineStatus": "$elem.ExpenseDetail.LineStatus"
}
#end
],
"Vendor": {
"value": "$inputRoot.Vendor.value",
"name": "$inputRoot.Vendor.name"
},
"APRef": {
"value": "$inputRoot.APRef.value",
"name": "$inputRoot.APRef.name"
},
"TotalAmt": $inputRoot.TotalAmt
}
Datos transformados (ejemplo de factura de ventas)

factura de ventas original para producir el resultado:
140
{
"DueDate": "2013-02-15",
"Balance": 1990.19,
"DocNumber": "SAMP001",
"Status": "Payable",
"Line": [
{
"Description": "Sample Expense",
"Amount": 500,
"DetailType": "ExpenseDetail",
"Customer": "ABC123 (Sample Customer)",
"Ref": "DEF234 (Sample Construction)",
"Account": "EFG345 (Fuel)",
"LineStatus": "Billable"
}
],
"TotalAmt": 1990.19
}
Modelo de salida (ejemplo de factura de ventas)

transformados:
{
"title": "InvoiceOutputModel",
"type": "object",
"properties": {
"DueDate": { "type": "string" },
"Balance": { "type": "number" },
"DocNumber": { "type": "string" },
"Status": { "type": "string" },
"Line": {
"type": "array",
"items": {
"type": "object",
"properties": {
"Description": { "type": "string" },
"Amount": { "type": "integer" },
"DetailType": { "type": "string" },
"Customer": { "type": "string" },
"Ref": { "type": "string" },
"Account": { "type": "string" },
"LineStatus": { "type": "string" }
}
}
},
"TotalAmt": { "type": "number" }
}
}
Plantilla de asignación de salida (ejemplo de factura de ventas)

el transformado:
{
141
Ejemplo de registro de empleado
"DueDate": "$inputRoot.DueDate",
"Balance": $inputRoot.Balance,
"DocNumber": "$inputRoot.DocNumber",
"Status": "$inputRoot.Status",
"Line": [
#foreach($elem in $inputRoot.Line)
{
"Description": "$elem.Description",
"Amount": $elem.Amount,
"DetailType": "$elem.DetailType",
"Customer": "$elem.ExpenseDetail.Customer.value ($elem.ExpenseDetail.Customer.name)",
"Ref": "$elem.ExpenseDetail.Ref.value ($elem.ExpenseDetail.Ref.name)",
"Account": "$elem.ExpenseDetail.Account.value ($elem.ExpenseDetail.Account.name)",
"LineStatus": "$elem.ExpenseDetail.LineStatus"
#end
],
"TotalAmt": $inputRoot.TotalAmt
}
Ejemplo de registro de empleado (modelos y plantillas

de asignación de API Gateway)
utilizarse para una API de registro de un empleado de ejemplo en API Gateway. Para obtener más
información sobre los modelos y plantillas de asignación en API Gateway, consulte Crear modelos y
plantillas de asignación para las cargas de solicitud y respuesta (p. 123).
Temas
• Datos originales (ejemplo de registro de empleado) (p. 142)
• Modelo de entrada (ejemplo de registro de empleado) (p. 143)
• Plantilla de asignación de entrada (ejemplo de registro de empleado) (p. 144)
• Datos transformados (ejemplo de registro de empleado) (p. 145)
• Modelo de salida (ejemplo de registro de empleado) (p. 145)
• Plantilla de asignación de salida (ejemplo de registro de empleado) (p. 146)
Datos originales (ejemplo de registro de empleado)

A continuación se presentan los datos JSON originales para el ejemplo de registro de empleado:
{
"QueryResponse": {
"maxResults": "1",
"startPosition": "1",
"Employee": {
"Organization": "false",
"Title": "Mrs.",
"GivenName": "Jane",
"MiddleName": "Lane",
"FamilyName": "Doe",
"DisplayName": "Jane Lane Doe",
"PrintOnCheckName": "Jane Lane Doe",
"Active": "true",
"PrimaryPhone": { "FreeFormNumber": "505.555.9999" },
"PrimaryEmailAddr": { "Address": "[email protected]" },
142
"EmployeeType": "Regular",
"status": "Synchronized",
"Id": "ABC123",
"SyncToken": "1",
"MetaData": {
"CreateTime": "2015-04-26T19:45:03Z",
"LastUpdatedTime": "2015-04-27T21:48:23Z"
},
"PrimaryAddr": {
"Line1": "123 Any Street",
"City": "Any City",
"CountrySubDivisionCode": "WA",
"PostalCode": "01234"
}
}
},
"time": "2015-04-27T22:12:32.012Z"
}
Modelo de entrada (ejemplo de registro de empleado)

el ejemplo de registro de empleado:
{
"title": "EmployeeInputModel",
"type": "object",
"properties": {
"QueryResponse": {
"type": "object",
"properties": {
"maxResults": { "type": "string" },
"startPosition": { "type": "string" },
"Employee": {
"type": "object",
"properties": {
"Organization": { "type": "string" },
"Title": { "type": "string" },
"GivenName": { "type": "string" },
"MiddleName": { "type": "string" },
"FamilyName": { "type": "string" },
"DisplayName": { "type": "string" },
"PrintOnCheckName": { "type": "string" },
"Active": { "type": "string" },
"PrimaryPhone": {
"type": "object",
"properties": {
"FreeFormNumber": { "type": "string" }
}
},
"PrimaryEmailAddr": {
"type": "object",
"properties": {
"Address": { "type": "string" }
}
},
"EmployeeType": { "type": "string" },
"status": { "type": "string" },
"Id": { "type": "string" },
"SyncToken": { "type": "string" },
"MetaData": {
"type": "object",
"properties": {
143
"CreateTime": { "type": "string" },

"LastUpdatedTime": { "type": "string" }
}
},
"PrimaryAddr": {
"type": "object",
"properties": {
"Line1": { "type": "string" },
"City": { "type": "string" },
"CountrySubDivisionCode": { "type": "string" },
"PostalCode": { "type": "string" }
}
}
}
}
}
},
"time": { "type": "string" }
}
}
Plantilla de asignación de entrada (ejemplo de registro de

empleado)
originales para el ejemplo de registro de empleado:
{
"QueryResponse": {
"maxResults": "$inputRoot.QueryResponse.maxResults",
"startPosition": "$inputRoot.QueryResponse.startPosition",
"Employee": {
"Organization": "$inputRoot.QueryResponse.Employee.Organization",
"Title": "$inputRoot.QueryResponse.Employee.Title",
"GivenName": "$inputRoot.QueryResponse.Employee.GivenName",
"MiddleName": "$inputRoot.QueryResponse.Employee.MiddleName",
"FamilyName": "$inputRoot.QueryResponse.Employee.FamilyName",
"DisplayName": "$inputRoot.QueryResponse.Employee.DisplayName",
"PrintOnCheckName": "$inputRoot.QueryResponse.Employee.PrintOnCheckName",
"Active": "$inputRoot.QueryResponse.Employee.Active",
"PrimaryPhone": { "FreeFormNumber":
"$inputRoot.QueryResponse.Employee.PrimaryPhone.FreeFormNumber" },
"PrimaryEmailAddr": { "Address":
"$inputRoot.QueryResponse.Employee.PrimaryEmailAddr.Address" },
"EmployeeType": "$inputRoot.QueryResponse.Employee.EmployeeType",
"status": "$inputRoot.QueryResponse.Employee.status",
"Id": "$inputRoot.QueryResponse.Employee.Id",
"SyncToken": "$inputRoot.QueryResponse.Employee.SyncToken",
"MetaData": {
"CreateTime": "$inputRoot.QueryResponse.Employee.MetaData.CreateTime",
"LastUpdatedTime": "$inputRoot.QueryResponse.Employee.MetaData.LastUpdatedTime"
},
"PrimaryAddr" : {
"Line1": "$inputRoot.QueryResponse.Employee.PrimaryAddr.Line1",
"City": "$inputRoot.QueryResponse.Employee.PrimaryAddr.City",
"CountrySubDivisionCode":
"$inputRoot.QueryResponse.Employee.PrimaryAddr.CountrySubDivisionCode",
"PostalCode": "$inputRoot.QueryResponse.Employee.PrimaryAddr.PostalCode"
}
}
},
"time": "$inputRoot.time"
144
Datos transformados (ejemplo de registro de empleado)

A continuación se muestra un ejemplo de cómo se pueden transformar los datos JSON del ejemplo de
registro de empleado original para producir el resultado:
{
"QueryResponse": {
"maxResults": "1",
"startPosition": "1",
"Employees": [
{
"Title": "Mrs.",
"GivenName": "Jane",
"MiddleName": "Lane",
"FamilyName": "Doe",
"DisplayName": "Jane Lane Doe",
"PrintOnCheckName": "Jane Lane Doe",
"Active": "true",
"PrimaryPhone": "505.555.9999",
"Email": [
{
"type": "primary",
"Address": "[email protected]"
}
],
"EmployeeType": "Regular",
"PrimaryAddr": {
"Line1": "123 Any Street",
"City": "Any City",
"CountrySubDivisionCode": "WA",
"PostalCode": "01234"
}
}
]
},
"time": "2015-04-27T22:12:32.012Z"
}
Modelo de salida (ejemplo de registro de empleado)

transformados:
{
"title": "EmployeeOutputModel",
"type": "object",
"properties": {
"QueryResponse": {
"type": "object",
"properties": {
"maxResults": { "type": "string" },
"startPosition": { "type": "string" },
"Employees": {
"type": "array",
"items": {
"type": "object",
"properties": {
"Title": { "type": "string" },
145
"GivenName": { "type": "string" },

"MiddleName": { "type": "string" },
"FamilyName": { "type": "string" },
"DisplayName": { "type": "string" },
"PrintOnCheckName": { "type": "string" },
"Active": { "type": "string" },
"PrimaryPhone": { "type": "string" },
"Email": {
"type": "array",
"items": {
"type": "object",
"properties": {
"Address": { "type": "string" }
}
}
},
"EmployeeType": { "type": "string" },
"PrimaryAddr": {
"type": "object",
"properties": {
"Line1": {"type": "string" },
"City": { "type": "string" },
"CountrySubDivisionCode": { "type": "string" },
"PostalCode": { "type": "string" }
}
}
}
}
}
}
},
"time": { "type": "string" }
}
}
Plantilla de asignación de salida (ejemplo de registro de

empleado)
el transformado:
{
"QueryResponse": {
"maxResults": "$inputRoot.QueryResponse.maxResults",
"startPosition": "$inputRoot.QueryResponse.startPosition",
"Employees": [
{
"Title": "$inputRoot.QueryResponse.Employee.Title",
"GivenName": "$inputRoot.QueryResponse.Employee.GivenName",
"MiddleName": "$inputRoot.QueryResponse.Employee.MiddleName",
"FamilyName": "$inputRoot.QueryResponse.Employee.FamilyName",
"DisplayName": "$inputRoot.QueryResponse.Employee.DisplayName",
"PrintOnCheckName": "$inputRoot.QueryResponse.Employee.PrintOnCheckName",
"Active": "$inputRoot.QueryResponse.Employee.Active",
"PrimaryPhone": "$inputRoot.QueryResponse.Employee.PrimaryPhone.FreeFormNumber",
"Email" : [
{
"type": "primary",
"Address": "$inputRoot.QueryResponse.Employee.PrimaryEmailAddr.Address"
}
146
Asignación de datos de solicitud y respuesta
],
"EmployeeType": "$inputRoot.QueryResponse.Employee.EmployeeType",
"PrimaryAddr": {
"Line1": "$inputRoot.QueryResponse.Employee.PrimaryAddr.Line1",
"City": "$inputRoot.QueryResponse.Employee.PrimaryAddr.City",
"CountrySubDivisionCode":
"$inputRoot.QueryResponse.Employee.PrimaryAddr.CountrySubDivisionCode",
"PostalCode": "$inputRoot.QueryResponse.Employee.PrimaryAddr.PostalCode"
}
}
]
},
"time": "$inputRoot.time"
}
Asignación de datos de solicitud y respuesta de API

de Amazon API Gateway
En esta sección se explica cómo configurar asignaciones de datos desde los datos de solicitud de método
de una API, incluidos otros datos almacenados en las variables context (p. 158), stage (p. 164)
o util (p. 164), a los parámetros de solicitud de integración correspondientes y desde los datos de
respuesta de integración, incluidos los demás datos, a los parámetros de respuesta de método. Los datos
de la solicitud de método incluyen parámetros de solicitud (ruta, cadena de consulta, encabezados) y el
cuerpo. Los datos de la respuesta de integración incluyen parámetros de respuesta (encabezados) y el
cuerpo. Para obtener más información sobre el uso de las variables de etapa, consulte Referencia de
variables de etapa de Amazon API Gateway (p. 316).
Temas
• Asignar datos de solicitud de método a parámetros de solicitud de integración (p. 147)
• Asignar datos de respuesta de integración a encabezados de respuesta de método (p. 149)
• Asignar cargas de solicitud y respuesta entre método e integración (p. 149)
• Comportamiento del acceso directo a la integración (p. 150)
• Asignar datos de solicitud de método para personalizar recursos de gateway (p. 151)
Asignar datos de solicitud de método a parámetros de

solicitud de integración
Los parámetros de solicitud de integración, en forma de variables de ruta, cadenas de consulta o
encabezados, se pueden asignar desde cualquier parámetro de solicitud de método definido y la carga.
Expresiones de asignación de datos de solicitud de integración
Origen de datos asignado Expresión de asignación
Ruta de solicitud de método method.request.path.PARAM_NAME
Cadena de consulta de solicitud de método method.request.querystring.PARAM_NAME
Encabezado de solicitud de método method.request.header.PARAM_NAME
Cuerpo de solicitud de método method.request.body
Cuerpo de solicitud de método (JsonPath) method.request.body.JSONPath_EXPRESSION.
147
Asignar datos de solicitud de método a
parámetros de solicitud de integración
Variables de etapa stageVariables.VARIABLE_NAME
Variables de contexto context.VARIABLE_NAME que debe ser alguna de

las variables de contexto admitidas (p. 158).
Valor estático 'STATIC_VALUE'. STATIC_VALUE es un literal de

cadena que se debe incluir entre comillas simples.
Aquí, PARAM_NAME es el nombre de un parámetro de solicitud de método del tipo de parámetro especificado.
Debe haberse definido para que se pueda hacer referencia a él. JSONPath_EXPRESSION es una expresión
JSONPath para un campo JSON del cuerpo de una solicitud o respuesta. Sin embargo, el prefijo "$." se
omite en esta sintaxis.
Example Asignaciones de ejemplo de parámetros de solicitud de método en Swagger
El siguiente ejemplo muestra un fragmento de Swagger que asigna 1) el encabezado de la solicitud

de método, denominado methodRequestHeadParam, al parámetro de ruta de solicitud de integración,
denominado integrationPathParam; 2) la cadena de consulta de solicitud de método, denominada
methodRequestQueryParam, a la cadena de consulta de solicitud de integración, denominada
integrationQueryParam.
...
"requestParameters" : {
"integration.request.path.integrationPathParam" :
"method.request.header.methodRequestHeaderParam",
"integration.request.querystring.integrationQueryParam" :
"method.request.querystring.methodRequestQueryParam"
}
...
Los parámetros de solicitud de integración también se pueden asignar desde campos del cuerpo de la
solicitud JSON mediante una expresión JSONPath. En la siguiente tabla se muestran las expresiones de
asignación de un cuerpo de solicitud de método y sus campos JSON.
Example Asignación de ejemplo desde el cuerpo de solicitud de método en Swagger
El siguiente ejemplo muestra un fragmento de Swagger que asigna 1) el cuerpo de solicitud de método
al encabezado de solicitud de integración, denominado body-header, y 2) un campo JSON del cuerpo,
expresado por una expresión JSON (petstore.pets[0].name, sin el prefijo $.).
...
"integration.request.header.body-header" : "method.request.body",
"integration.request.path.pet-name" : "method.request.body.petstore.pets[0].name",
}
...
148
Asignar datos de respuesta de integración
a encabezados de respuesta de método
Asignar datos de respuesta de integración a

encabezados de respuesta de método
Los parámetros de encabezado de respuesta de método se pueden asignar desde cualquier encabezado
de respuesta de integración o cuerpo de respuesta de integración, variables $context o valores estáticos.
Expresiones de asignación de encabezado de respuesta de método
Encabezado de respuesta de integración integration.response.header.PARAM_NAME
Cuerpo de respuesta de integración integration.response.body
Cuerpo de respuesta de integración (JsonPath) integration.response.body.JSONPath_EXPRESSION
Variable de etapa stageVariables.VARIABLE_NAME
Variable de contexto context.VARIABLE_NAME que debe ser alguna de

las variables de contexto admitidas (p. 158).
Valor estático 'STATIC_VALUE'. STATIC_VALUE es un literal de

cadena que se debe incluir entre comillas simples.
Example Asignación de datos de ejemplo desde una respuesta de integración en Swagger

El siguiente ejemplo muestra un fragmento de Swagger que asigna 1) el campo JSONPath redirect.url
de la respuesta de integración al encabezado location de la respuesta de solicitud; y 2) el encabezado x-
app-id de la respuesta de integración al encabezado id de la respuesta de método.
...
"responseParameters" : {
"method.response.header.location" : "integration.response.body.redirect.url",
"method.response.header.id" : "integration.response.header.x-app-id",
}
...
Asignar cargas de solicitud y respuesta entre método

e integración
API Gateway utiliza el motor Velocity Template Language (VTL) para procesar las plantillas de
asignación (p. 127) de cuerpo para la solicitud de integración y la respuesta de integración. Las plantillas
de asignación traducen las cargas de solicitud de método en las cargas de solicitud de integración
correspondientes y los cuerpos de respuesta de integración en los cuerpos de respuesta de método.
Las plantillas de VTL usan expresiones JSONPath, otros parámetros como los contextos de llamada y las
variables de etapa, y funciones de utilidad para procesar los datos JSON.
Si se define un modelo para describir la estructura de datos de una carga, API Gateway puede utilizar el
modelo para generar una plantilla de asignación básica para una solicitud de integración o una respuesta
de integración. Puede utilizar la plantilla básica como ayuda para personalizar y ampliar el script VTL de
149
Comportamiento del acceso directo a la integración
asignación. Sin embargo, puede crear una plantilla de asignación desde cero sin definir un modelo para la
estructura de datos de la carga.
Seleccionar una plantilla de asignación VTL

API Gateway utiliza la siguiente lógica para seleccionar una plantilla de asignación, en Velocidad Template
Language (VTL), para asignar la carga desde una solicitud de método a la solicitud de integración
correspondiente o para asignar la carga desde una respuesta de integración a la respuesta de método
correspondiente.
Para una carga de solicitud, API Gateway utiliza el valor del encabezado Content-Type de la solicitud
como la clave para seleccionar la plantilla de asignación para la carga de la solicitud. Para una carga de
respuesta, API Gateway utiliza el valor del encabezado Accept de la solicitud entrante como la clave para
seleccionar la plantilla de asignación.
Cuando el encabezado Content-Type no está presente en la solicitud, API Gateway asume que el valor
predeterminado es application/json. Para dicha solicitud, API Gateway utiliza application/json
como la clave predeterminada para seleccionar la plantilla de asignación, si se define una. Cuando
ninguna plantilla coincide con esta clave, API Gateway transfiere la carga sin asignar si la propiedad
passthroughBehavior está establecida en WHEN_NO_MATCH o WHEN_NO_TEMPLATES.
Cuando no se especifica el encabezado Accept en la solicitud, API Gateway asume que el valor
predeterminado es application/json. En este caso, API Gateway selecciona una plantilla de asignación
de application/json para asignar la carga de la respuesta. Si no se define ninguna plantilla para
application/json, API Gateway selecciona la primera plantilla existente y la utiliza como la opción
predeterminada para asignar la carga de la respuesta. Del mismo modo, API Gateway utiliza la primera
plantilla existente cuando el valor del encabezado Accept especificado no coincide con ninguna clave de
plantilla existente. Si no se define ninguna plantilla, API Gateway simplemente transfiere la carga de la
respuesta sin asignar.
Suponga, por ejemplo, que una API tiene una plantilla application/json definida para una carga de
solicitud y una plantilla application/xml definida para la carga de la respuesta. Si el cliente configura los
encabezados "Content-Type : application/json"y "Accept : application/xml" en la solicitud, las
cargas de la solicitud y la respuesta se procesarán con las plantillas de asignación correspondientes. Si
el encabezado Accept:application/xml no está presente, la plantilla de asignación application/xml se
usará para asignar la carga de la respuesta. Para devolver la carga de la respuesta sin asignar en su lugar,
debe configurar una plantilla vacía para application/json.
Solo se utiliza el tipo MIME de los encabezados Accept y Content-Type cuando se selecciona una plantilla
de asignación. Por ejemplo, un encabezado "Content-Type: application/json; charset=UTF-8" tendrá
una plantilla de solicitud con la clave application/json seleccionada.
Comportamiento del acceso directo a la integración

Cuando una solicitud de método contiene una carga y el encabezado Content-Type no coincide con
ninguna de las plantillas de mapeo especificadas o no se ha definido ninguna plantilla de mapeo, puede
optar por transmitir la carga de solicitud suministrada por el cliente a través de una solicitud de integración
al backend sin transformación. Este proceso se denomina "acceso directo a la integración".
En el caso de integraciones de proxy (p. 115), API Gateway transmite toda la solicitud a través de
backend y no tiene ninguna opción de modificar los comportamientos de "acceso directo" (o passthrough).
El comportamiento real del acceso directo de una solicitud entrante se determina en función de la
opción elegida para una plantilla de asignación especificada, durante la configuración de la solicitud de
integración (p. 87), y del encabezado Content Type que un cliente establece en la solicitud entrante. Los
siguientes ejemplos ilustran los posibles comportamientos del acceso directo.
Ejemplo 1: Se define una plantilla de asignación en la solicitud de integración para el tipo de contenido
application/json.
150
Asignar datos de solicitud de método
para personalizar recursos de gateway
Encabezado Content- WHEN_NO_MATCH WHEN_NO_TEMPLATE NEVER

Type\Opción de acceso
directo seleccionada
Ninguno (se usa el La carga de solicitud se La carga de solicitud se La carga de solicitud se

valor predeterminado transforma mediante la transforma mediante la transforma mediante la
application/json) plantilla. plantilla. plantilla.
application/json La carga de solicitud se La carga de solicitud se La carga de solicitud se

transforma mediante la transforma mediante la transforma mediante la
plantilla. plantilla. plantilla.
application/xml La carga de solicitud no La solicitud se rechaza La solicitud se rechaza

se transforma y se envía con una respuesta con una respuesta
al backend tal como HTTP 415 Unsupported HTTP 415 Unsupported
está. Media Type. Media Type.
Ejemplo 2: Se define una plantilla de asignación en la solicitud de integración para el tipo de contenido
application/xml.
Encabezado Content- WHEN_NO_MATCH WHEN_NO_TEMPLATE NEVER

Type\Opción de acceso
directo seleccionada
Ninguno (se usa el La carga de solicitud no La solicitud se rechaza La solicitud se rechaza

valor predeterminado se transforma y se envía con una respuesta con una respuesta
application/json) al backend tal como HTTP 415 Unsupported HTTP 415 Unsupported
application/json La carga de solicitud no La solicitud se rechaza La solicitud se rechaza

se transforma y se envía con una respuesta con una respuesta
al backend tal como HTTP 415 Unsupported HTTP 415 Unsupported
application/xml La carga de solicitud se La carga de solicitud se La carga de solicitud se

transforma mediante la transforma mediante la transforma mediante la
plantilla. plantilla. plantilla.
Asignar datos de solicitud de método para

personalizar recursos de gateway
Si API Gateway no puede procesar una solicitud entrante, devuelve al cliente una respuesta de error sin
reenviar la solicitud al backend de integración. De forma predeterminada, la respuesta de error contiene
un breve mensaje de error descriptivo. Por ejemplo, si intenta llamar a una operación en un recurso de
API no definido, recibe una respuesta de error con el mensaje { "message": "Missing Authentication
Token" }. Si es la primera vez que utiliza API Gateway, es posible que le resulte difícil entender qué es lo
que ha ocurrido.
Para algunas de las respuestas de error, API Gateway permite a los desarrolladores de API que
personalicen las respuestas de forma que devuelvan las respuestas en formatos diferentes. Para el
ejemplo de Missing Authentication Token, puede añadir una pista a la carga de respuesta original con
la posible causa, como en este ejemplo: {"message":"Missing Authentication Token", "hint":"The
HTTP method or resources may not be supported."}.
151
Cuando la API es un mediador entre un intercambio externo y la nube de AWS, se utilizan plantillas de
asignación de VTL para la solicitud de integración o la respuesta de integración para asignar la carga de
un formato a otro. Sin embargo, las plantillas de asignación de VTL solo funcionan para solicitudes válidas
con respuestas correctas. En el caso de las solicitudes no válidas, API Gateway omite la integración
en su totalidad y devuelve una respuesta de error. Debe utilizar la personalización para representar las
respuestas de error en un formato compatible con el intercambio. Aquí, la personalización se presenta en
una plantilla de asignación que no es de VTL que solo admite sustituciones de variables sencillas.
Con el fin de generalizar la respuesta de error generada por API Gateway a cualquier respuesta generada
por API Gateway, nos referimos a estas respuestas como respuesta de gateway. Esto permite distinguir
las respuestas generadas por API Gateway de las respuestas de integración. Una plantilla de asignación
de respuesta de gateway puede tener acceso a los valores de la variable $context y a los valores
de la propiedad $stageVariables, así como a los parámetros de solicitud de método, con el formato
method.request.param-position.param-name. Para obtener más información acerca de las variables
$context, consulte Acceso a la variable $context (p. 158). Para obtener más información acerca de
$stageVariables, consulte Acceso a la variable $stageVariables (p. 164). Para obtener más información
acerca de los parámetros de solicitud de método, consulte Parámetros de solicitud accesibles para una
plantilla de asignación (p. 147).
Respuestas de API Gateway

Una respuesta de API Gateway se identifica mediante un tipo de respuesta definido por API Gateway.
La respuesta se compone de un código de estado HTTP, un conjunto de encabezados adicionales
especificados mediante asignaciones de parámetros y una carga generada por una plantilla de asignación
distinta de VTL.
En la API REST de API Gateway, una respuesta de gateway se representa mediante GatewayResponse.
En Swagger, una instancia de GatewayResponse se describe mediante la extensión x-amazon-apigateway-
gateway-responses.gatewayResponse (p. 380).
Para habilitar una respuesta de gateway, debe configurar una para un tipo de respuesta admitido (p. 152)
en el nivel de API. Siempre que API Gateway devuelve una respuesta de este tipo, se aplican las plantillas
de asignación de encabezados y cargas definidas en la respuesta de gateway para devolver los resultados
asignados al intermediario de la API.
En la siguiente sección, le mostramos cómo configurar respuestas de gateway mediante la consola de API
Gateway y la API REST de API Gateway.
Tipos de respuesta de gateway admitidos por API Gateway

API Gateway expone las siguientes respuestas de gateway para su personalización por desarrolladores de
la API.
Tipo de respuesta de gateway Código de estado Descripción

predeterminado
DEFAULT_4XX Null La respuesta de gateway

predeterminada para un tipo
de respuesta sin especificar
con el código de estado 4XX. Si
se cambia el código de estado
de esta respuesta de gateway,
se cambian los códigos de
estado de todas las demás
respuestas 4XX al nuevo valor.
Si se restablece este código de
estado a null, se revierten los
152

predeterminado
códigos de estado de todas las
demás respuestas 4XX a sus
valores originales.
DEFAULT_5XX Null La respuesta de gateway

predeterminada para un tipo de
respuesta sin especificar con
un código de estado 5XX. Si se
cambia el código de estado de
esta respuesta de gateway ,
se cambian los códigos de
estado de todas las demás
respuestas 5XX al nuevo valor.
Si se restablece este código de
estado a null, se revierten los
códigos de estado de todas las
demás respuestas 5XX a sus
valores originales.
ACCESS_DENIED 403 La respuesta de gateway

para un error de autorización
(por ejemplo, cuando un
autorizador de Amazon Cognito
o personalizado deniega el
acceso). Si no se especifica el
tipo de respuesta, se asigna el
tipo DEFAULT_4XX.
API_CONFIGURATION_ERROR 500 La respuesta de gateway para

una configuración de API no
válida, incluida una dirección
de punto de enlace no válida
enviada, un error al descodificar
en Base64 datos binarios
cuando no se ha habilitado la
compatibilidad con los datos
binarios o una asignación de
respuesta de integración que no
coincide con ninguna plantilla y
no se ha configurado ninguna
plantilla predeterminada. Si no se
especifica el tipo de respuesta,
se asigna el tipo DEFAULT_5XX.
AUTHORIZER_CONFIGURATION_ERROR 500 La respuesta de gateway por

no poder conectarse a un
autorizador de Amazon Cognito
o personalizado. Si no se
153

predeterminado
AUTHORIZER_FAILURE 500 La respuesta de gateway cuando

un autorizador de Amazon
Cognito o personalizado no
puede autenticar al intermediario.
Si no se especifica el tipo de
respuesta, se asigna el tipo
DEFAULT_5XX.
BAD_REQUEST_PARAMETERS 400 La respuesta de gateway cuando

el parámetro de la solicitud no
se puede validar de acuerdo
con un validador de solicitudes
habilitado. Si no se especifica el
tipo DEFAULT_4XX.
BAD_REQUEST_BODY 400 La respuesta de gateway cuando

el cuerpo de la solicitud no se
puede validar de acuerdo con
un validador de solicitudes
habilitado. Si no se especifica el
tipo DEFAULT_4XX.
EXPIRED_TOKEN 403 La respuesta de gateway para un

error de token de autenticación
de AWS caducado. Si no se
INTEGRATION_FAILURE 504 La respuesta de gateway para

un error de integración. Si no se
INTEGRATION_TIMEOUT 504 La respuesta de gateway para

un error de tiempo de espera de
la integración agotado. Si no se
INVALID_API_KEY 403 La respuesta de gateway para

una clave de API no válida
enviada para un método que
requiere una clave de API.
Si no se especifica el tipo de
respuesta, se asigna el tipo
DEFAULT_4XX.
INVALID_SIGNATURE 403 La respuesta de gateway para

un error de firma de AWS no
válida. Si no se especifica el tipo
de respuesta, se asigna el tipo
DEFAULT_4XX.
154

predeterminado
MISSING_AUTHENTICATION_TOKEN 403 La respuesta de gateway para un

error de token de autenticación
que falta, incluidos los casos en
los que el cliente intenta invocar
un método o recurso de API no
admitido. Si no se especifica el
tipo DEFAULT_4XX.
QUOTA_EXCEEDED 429 La respuesta de gateway para

el error de cuota del plan de uso
superada. Si no se especifica el
tipo DEFAULT_4XX.
REQUEST_TOO_LARGE 413 La respuesta de gateway para

el error de solicitud demasiado
grande. Si no se especifica el tipo
DEFAULT_4XX.
RESOURCE_NOT_FOUND 404 La respuesta de gateway cuando

API Gateway no puede encontrar
el recurso especificado después
de que la solicitud de API supera
la autenticación y autorización,
excepto para la autenticación
y autorización de la clave de
API. Si no se especifica el tipo
DEFAULT_4XX.
THROTTLED 429 La respuesta de gateway

cuando se exceden los límites
de solicitudes de nivel de plan,
método, etapa o cuenta. Si no se
UNAUTHORIZED 401 La respuesta de gateway cuando

el autorizador de Amazon
Cognito o personalizado no
puede autenticar al intermediario.
UNSUPPORTED_MEDIA_TYPE 415 La respuesta de gateway cuando

una carga es de un tipo de medio
no admitido, si se ha habilitado el
comportamiento de paso a través
estricto. Si no se especifica el
tipo DEFAULT_4XX.
155
Usar la consola de API Gateway para personalizar una respuesta

de gateway
Para personalizar una respuesta de gateway mediante la consola de API Gateway

2. Elija su API existente o cree una nueva.
3. Expanda la API en el panel de navegación principal y elija Gateway Responses en la API.
4. En el panel Gateway Responses, elija un tipo de respuesta. En este tutorial, utilizamos Missing
Authentication Token (403) como ejemplo.
5. Puede cambiar el Status Code generado por API Gateway para devolver un código de estado
diferente acorde con los requisitos de su API. En este ejemplo, la personalización cambia el código
de estado del valor predeterminado (403) a 404, porque este mensaje de error se produce cuando un
cliente llama a un recurso no admitido o no válido que se considera no encontrado.
6. Para devolver encabezados personalizados, elija Add Header en Response Headers. Con fines
ilustrativos, añadimos los siguientes encabezados personalizados:
Access-Control-Allow-Origin:'a.b.c'
x-request-id:method.request.header.x-amzn-RequestId
x-request-path:method.request.path.petId
x-request-query:method.request.querystring.q
En las asignaciones de encabezado anteriores, un nombre de dominio estático ('a.b.c') se asigna al

encabezado Allow-Control-Allow-Origin para permitir el acceso de CORS a la API; el encabezado
de solicitud de entrada x-amzn-RequestId se asigna a request-id en la respuesta, la variable de ruta
petId de la solicitud entrante se asigna al encabezado request-path de la respuesta y el parámetro
de consulta q de la solicitud original se asigna al encabezado request-query de la respuesta.
7. En Body Mapping Templates, deje application/json para Content Type y especifique la siguiente
plantilla de mapeo de cuerpo en el editor Body Mapping Template:
{
"message":"$context.error.messageString",
"type": "$context.error.responseType",
"statusCode": "'404'",
"stage": "$context.stage",
"resourcePath": "$context.resourcePath",
"stageVariables.a": "$stageVariables.a"
}
Este ejemplo muestra cómo asignar las propiedades $context y $stageVariables a propiedades del
cuerpo de la respuesta de gateway.
8. Seleccione Save.
9. Implemente la API en una etapa nueva o existente.
10. Pruébela llamando a los siguientes comandos CURL si la URL de invocación del método de API
correspondiente es https://o81lxisefl.execute-api.us-east-1.amazonaws.com/custErr/pets/
{petId}:
curl -v -H 'x-amnz-RequestId:123344566' https://o81lxisefl.execute-api.us-

east-1.amazonaws.com/custErr/pets/5/type?q=1
Como el parámetro de cadena de consulta adicional q=1 no es compatible con la API, se devuelve
un error que desencadena la respuesta de gateway especificada. Debería obtener una respuesta de
gateway similar a la siguiente:
156
> GET /custErr/pets/5?q=1 HTTP/1.1

Host: o81lxisefl.execute-api.us-east-1.amazonaws.com
User-Agent: curl/7.51.0
Accept: */*
HTTP/1.1 404 Not Found

Content-Length: 334
Connection: keep-alive
Date: Tue, 02 May 2017 03:15:47 GMT
x-amzn-RequestId: a2be05a4-2ee5-11e7-bbf2-df131ec50ae6
Access-Control-Allow-Origin: a.b.c
x-amzn-ErrorType: MissingAuthenticationTokenException
header-1: static
x-request-query: 1
x-request-path: 5
X-Cache: Error from cloudfront
Via: 1.1 441811a054e8d055b893175754efd0c3.cloudfront.net (CloudFront)
X-Amz-Cf-Id: nNDR-fX4csbRoAgtQJ16u0rTDz9FZWT-Mk93KgoxnfzDlTUh3flmzA==
{
"message":"Missing Authentication Token",
"type": MISSING_AUTHENTICATION_TOKEN,
"statusCode": '404',
"stage": custErr,
"resourcePath": /pets/{petId},
"stageVariables.a": a
}
En el ejemplo anterior se presupone que el backend de la API es Pet Store y que la API tiene un
variable de etapa, a, definida.
Usar la API REST de API Gateway para personalizar una

respuesta de gateway
Antes de personalizar un respuesta de gateway mediante la API REST de API Gateway, debe haber
creado una API y haber obtenido su identificador. Para recuperar el identificador de la API, puede seguir la
relación del enlace restapi:gateway-responses y examinar el resultado.
Para personalizar una respuesta de gateway mediante la API REST de API Gateway
1. Para sobrescribir una instancia de GatewayResponse en su totalidad, llame a la acción

gatewayresponse:put, especificando el responseType que desee en el parámetro de ruta URL
y proporcionando en la carga de solicitud las asignaciones statusCode, responseParameters y
responseTemplates.
2. Para actualizar parte de una instancia de GatewayResponse, llame a la acción
gatewayresponse:update, especificando el responseType deseado en el parámetro de ruta URL y
proporcionando en la carga de solicitud las distintas propiedades de GatewayResponse como, por
ejemplo, la asignación responseParameters o responseTemplates.
Configurar la personalización de respuestas de gateway en

Swagger
Puede utilizar la extensión x-amazon-apigateway-gateway-responses en el nivel de raíz de la API para
personalizar respuestas de gateway en Swagger. La siguiente definición de Swagger muestra un ejemplo
de personalización de GatewayResponse del tipo MISSING_AUTHENTICATION_TOKEN .
157
Funciones y variables integradas
en la plantilla de asignación
"x-amazon-apigateway-gateway-responses": {
"MISSING_AUTHENTICATION_TOKEN": {
"statusCode": 404,
"gatewayresponse.header.x-request-path": "method.input.params.petId",
"gatewayresponse.header.x-request-query": "method.input.params.q",
"gatewayresponse.header.Access-Control-Allow-Origin": "'a.b.c'",
"gatewayresponse.header.x-request-header": "method.input.params.Accept"
},
"application/json": "{\n \"message\": $context.error.messageString,\n
\"type\": \"$context.error.responseType\",\n \"stage\": \"$context.stage
\",\n \"resourcePath\": \"$context.resourcePath\",\n \"stageVariables.a\":
\"$stageVariables.a\",\n \"statusCode\": \"'404'\"\n}"
}
}
En este ejemplo, la personalización cambia el código de estado del valor predeterminado (403) a 404.
También añade a la respuesta de gateway cuatro parámetros de encabezado y una plantilla de asignación
de cuerpo para el tipo de medio application/json.
Funciones y variables integradas en la plantilla de

asignación de API Gateway
Amazon API Gateway define un conjunto de variables y funciones para trabajar con modelos y plantillas de
asignación. En este documento se describen las funciones y se proporcionan ejemplos para trabajar con
cargas de entrada.
Temas
• Acceso a la variable $context (p. 158)
• Acceso a la variable $input (p. 161)
• Acceso a la variable $stageVariables (p. 164)
• Acceso a la variable $util (p. 164)
Acceso a la variable $context

La variable $context contiene toda la información contextual de la llamada a la API.
Referencia de la variable $context
Parámetro Descripción
$context.apiId El identificador que API Gateway asigna a la API.
$context.authorizer.claims.property Una propiedad de las notificaciones devueltas

por el conjunto de usuarios de Amazon Cognito
una vez que se ha autenticado correctamente al
intermediario del método.
Note
La llamada a
$context.authorizer.claims devuelve
null.
158
$context.authorizer.principalId La identificación de usuario principal asociada con

el token enviado por el cliente y devuelto por la
función de Lambda del autorizador personalizado
de API Gateway.
$context.authorizer.property El valor en forma de cadena del par de clave-

valor especificado de la asignación de context
devuelta por la función de Lambda del autorizador
predeterminado de API Gateway. Por ejemplo, si
el autorizador devuelve la siguiente asignación de
context:
"context" : {
"key": "value",
"numKey": 1,
"boolKey": true
}
la llamada a $context.authorizer.key
devuelve la cadena "value", la llamada a
$context.authorizer.numKey devuelve la cadena
"1" y la llamada a $context.authorizer.boolKey
devuelve la cadena "true".
$context.httpMethod El método HTTP utilizado. Los valores válidos son:

DELETE, GET, HEAD, OPTIONS, PATCH, POST y PUT.
$context.error.message Una cadena de un mensaje de error de API

Gateway personalizable. Esta variable solo se
puede usar para una sustitución sencilla de
variables en una plantilla de asignación de cuerpo
GatewayResponse, que no procesa el motor de
Velocity Template Language.
$context.error.responseType Un tipo de GatewayResponse. Esta variable solo

se puede usar para una sustitución sencilla de
variables en una plantilla de asignación de cuerpo
GatewayResponse, que no procesa el motor de
Velocity Template Language.
$context.identity.accountId El ID de cuenta de AWS asociado con la solicitud.
$context.identity.apiKey La clave del propietario de la API asociada a la

API.
$context.identity.caller El identificador principal del intermediario que

realiza la solicitud.
159
El proveedor de autenticación de Amazon Cognito

$context.identity.cognitoAuthenticationProvider
utilizado por el intermediario que realiza la
solicitud. Solo está disponible si la solicitud se
firma con credenciales de Amazon Cognito.
Para obtener información acerca de esta y de otras

variables $context de Amazon Cognito, consulte
Using Federated Identities en la Amazon Cognito
Developer Guide.
$context.identity.cognitoAuthenticationType El tipo de autenticación de Amazon Cognito del

intermediario que realiza la solicitud. Solo está
disponible si la solicitud se firma con credenciales
de Amazon Cognito.
$context.identity.cognitoIdentityId El ID de identidad de Amazon Cognito del

intermediario que realiza la solicitud. Solo está
de Amazon Cognito.
$context.identity.cognitoIdentityPoolId El ID de grupo de identidades de Amazon Cognito

del intermediario que realiza la solicitud. Solo está
de Amazon Cognito.
$context.identity.sourceIp La dirección IP de origen de la conexión TCP que

realiza la solicitud de API Gateway.
$context.identity.user El identificador principal del usuario que realiza la

solicitud.
$context.identity.userAgent El agente de usuario del intermediario de la API.
$context.identity.userArn El Nombre de recurso de Amazon (ARN) del

usuario identificado después de la autenticación.
$context.requestId Un ID generado de forma automática para la

llamada a la API.
$context.resourceId El identificador que API Gateway asigna a su

recurso.
$context.resourcePath La ruta a su recurso. Para obtener más

información, consulte Cree una API de API
Gateway para exponer un punto de enlace
HTTP (p. 8).
$context.stage La etapa de implementación de la llamada a la API

(por ejemplo, Beta o Prod).
Ejemplo
Quizás le interese utilizar la variable $context si va a usar AWS Lambda como el backend de destino
al que llama el método de la API. Por ejemplo, es posible que desee realizar dos acciones diferentes en
función de si la etapa está en Beta o en Producción.
160
Acceso a la variable $input
Ejemplo de plantilla de variables de contexto

El siguiente ejemplo muestra cómo obtener variables de contexto:
{
"stage" : "$context.stage",
"request_id" : "$context.requestId",
"api_id" : "$context.apiId",
"resource_path" : "$context.resourcePath",
"resource_id" : "$context.resourceId",
"http_method" : "$context.httpMethod",
"source_ip" : "$context.identity.sourceIp",
"user-agent" : "$context.identity.userAgent",
"account_id" : "$context.identity.accountId",
"api_key" : "$context.identity.apiKey",
"caller" : "$context.identity.caller",
"user" : "$context.identity.user",
"user_arn" : "$context.identity.userArn"
}

La variable $input representa la carga de entrada y los parámetros que va a procesar la plantilla.
Proporciona cuatro funciones:
Referencia de funciones
Variable y función Descripción
$input.body Devuelve la carga bruta como una cadena.
$input.json(x) Esta función evalúa una expresión JSONPath y

devuelve los resultados como una cadena JSON.
Por ejemplo, $input.json('$.pets') devolverá

una cadena JSON que representa la estructura de
"pets" (mascotas).
Para obtener más información acerca de

JSONPath, consulte JSONPath o JSONPath for
Java.
$input.params() Devuelve una asignación de todos los parámetros

de solicitud de la llamada a la API.
$input.params(x) Devuelve el valor de un parámetro de solicitud de

método de la ruta, cadena de consulta o valor de
encabezado (en este orden) dada una cadena de
nombre de parámetro x.
$input.path(x) Toma una cadena de expresión JSONPath (x)

y devuelve una representación del resultado en
forma de objeto. Esto le permite tener acceso y
manipular los elementos de la carga de forma
nativa en Apache Velocity Template Language
(VTL).
Por ejemplo, $input.path('$.pets').size()
161
Variable y función Descripción

Para obtener más información acerca de
JSONPath, consulte JSONPath o JSONPath for
Java.
Ejemplos
Tal vez desee utilizar la variable $input para obtener las cadenas de consulta y el cuerpo de la solicitud
con o sin el uso de modelos. Es posible que también desee obtener el parámetro y la carga, o bien una
subsección de la carga, en su función de AWS Lambda. Los siguientes ejemplos muestran cómo hacerlo.
Plantilla de asignación JSON de ejemplo

El siguiente ejemplo muestra cómo utilizar una asignación para leer un nombre de la cadena de consulta y
después incluir todo el cuerpo de POST en un elemento:
{
"name" : "$input.params('name')",
"body" : $input.json('$')
}
Si la entrada JSON contiene caracteres sin escape que no puede analizar JavaScript, es posible que se
devuelva una respuesta 400. Si aplica $util.escapeJavaScript($input.json('$')) arriba se asegurará
de que la entrada JSON se pueda analizar correctamente.
Plantilla de asignación de entradas de ejemplo

El siguiente ejemplo muestra cómo pasar una expresión JSONPath al método json(). También puede leer
una propiedad específica del objeto del cuerpo de la solicitud utilizando un punto (.), seguido del nombre
de la propiedad:
{
"body" : $input.json('$.mykey')
}
Si una carga de solicitud de método contiene caracteres sin escape que no puede analizar JavaScript, es
posible que obtenga la respuesta 400. En este caso, debe llamar a la función $util.escapeJavaScript()
en la plantilla de asignación, tal y como se muestra a continuación:
{
"body" : $util.escapeJavaScript($input.json('$.mykey'))
}
Ejemplo de plantilla de asignación de parámetros

El siguiente ejemplo de asignación de parámetros pasa todos los parámetros, incluida la ruta, la cadena de
consulta y el encabezado, a través del punto de enlace de integración mediante una carga JSON.
#set($allParams = $input.params())
{
"params" : {
#foreach($type in $allParams.keySet())
#set($params = $allParams.get($type))
"$type" : {
#foreach($paramName in $params.keySet())
162
"$paramName" : "$util.escapeJavaScript($params.get($paramName))"
#if($foreach.hasNext),#end
#end
}
#if($foreach.hasNext),#end
#end
}
}
De hecho, esta plantilla de asignación muestra todos los parámetros de solicitud de la carga tal y como se
describe a continuación:
{
"parameters" : {
"path" : {
"path_name" : "path_value",
...
}
"header" : {
"header_name" : "header_value",
...
}
"querystring" : {
"querystring_name" : "querystring_value",
...
}
}
}
Solicitud y respuesta de ejemplo

A continuación se muestra un ejemplo que utiliza las tres funciones:
Request Template:
Resource: /things/{id}
With input template:

{
"id" : "$input.params('id')",
"count" : "$input.path('$.things').size()",
"things" : $util.escapeJavaScript($input.json('$.things'))
}
POST /things/abc
{
"things" : {
"1" : {},
"2" : {},
"3" : {}
}
}
Respuesta:
{
"id": "abc",
"count": "3",
"things": {
"1": {},
"2": {},
"3": {}
163
Acceso a la variable $stageVariables
}
}
Para obtener más ejemplos de asignación, consulte Crear modelos y plantillas de asignación para las
cargas de solicitud y respuesta (p. 123).
Acceso a la variable $stageVariables

La sintaxis para insertar una variable de etapa tiene este aspecto: $stageVariables.
Referencia de $stageVariables
Sintaxis Descripción
$stageVariables.<variable_name> <variable_name > representa un nombre de

variable de etapa.
$stageVariables['<variable_name>'] <variable_name> representa cualquier nombre de

variable de etapa.
${stageVariables['<variable_name>']} <variable_name> representa cualquier nombre de

variable de etapa.
Acceso a la variable $util

La variable $util contiene funciones de utilidad para su uso en plantillas de asignación.
Note
A menos que se especifique lo contrario, el conjunto de caracteres predeterminado es UTF-8.
Referencia de la variable $util
Función Descripción
$util.escapeJavaScript() Aplica caracteres de escape a los caracteres

de una cadena usando reglas de cadena de
JavaScript.
Note
Esta función convertirá todas las comillas

simples (') en caracteres de escape (\').
Sin embargo, JSON no admite comillas
simples con caracteres de escape. Por lo
tanto, cuando la salida de esta función se
utiliza en una propiedad de JSON, debe
convertir todas las comillas simples con
caracteres de escape (\') en comillas
simples normales ('). Esto se muestra en
el siguiente ejemplo:
$util.escapeJavaScript(data).replaceAll("\
\'","'")
$util.parseJson() Toma un elemento JSON en forma de cadena

y devuelve una representación del resultado en
164
Habilitar la validación básica de solicitudes para una API
Función Descripción
forma de objeto. Puede utilizar el resultado de
esta función para tener acceso y manipular los
elementos de la carga de forma nativa en Apache
Velocity Template Language (VTL). Por ejemplo, si
tiene la siguiente carga:
{"errorMessage":"{\"key1\":\"var1\",
\"key2\":{\"arr\":[1,2,3]}}"}
y usa la siguiente plantilla de asignación
#set ($errorMessageObj =
$util.parseJson($input.path('$.errorMessage')))
{
"errorMessageObjKey2ArrVal" :
$errorMessageObj.key2.arr[0]
}
Obtendrá el siguiente resultado:
{
"errorMessageObjKey2ArrVal" : 1
}
$util.urlEncode() Convierte una cadena en formato "application/x-

www-form-urlencoded".
$util.urlDecode() Descodifica una cadena "application/x-www-form-

urlencoded".
$util.base64Encode() Codifica los datos en una cadena codificada en

base64.
$util.base64Decode() Descodifica los datos de una cadena codificada en

base64.
Habilitar la validación básica de solicitudes para

una API en API Gateway
Puede configurar API Gateway para que realice una validación básica de una solicitud de API antes
de continuar con la solicitud de integración. Cuando no se supera la validación, API Gateway invalida
inmediatamente la solicitud, devuelve una respuesta de error 400 al intermediario y publica los resultados
de la validación en logs de CloudWatch. Esto reduce las llamadas innecesarias al backend. Y lo que es
más importante, le permite centrarse en el trabajo de validación específico de su aplicación.
Temas
• Descripción general de la validación básica de solicitudes en API Gateway (p. 166)
• Configurar la validación básica de solicitudes en API Gateway (p. 166)
• Probar la validación básica de solicitudes en API Gateway (p. 171)
• Definiciones de Swagger de una API de ejemplo con la validación básica de solicitudes (p. 174)
165
Descripción general de la validación
básica de solicitudes en API Gateway
Descripción general de la validación básica de

solicitudes en API Gateway
API Gateway puede realizar una validación básica. Este le permite a usted, como desarrollador de la API,
centrarse en una validación más detallada específica de su aplicación en el backend. Para la validación
básica, API Gateway verifica una o ambas de las condiciones siguientes:
• Los parámetros de la solicitud necesarios en el URI, cadena de consulta y encabezados de una solicitud
de entrada están presentes y no están vacíos.
• La carga de la solicitud aplicable sigue el modelo (p. 130) de solicitud del esquema JSON del método.
Para habilitar la validación básica, especifica reglas de validación en un validador de solicitudes, añade
el validador al mapa de validadores de solicitudes de la API y asigna el validador a métodos de la API
individuales.
Note
Solicitar la validación del cuerpo y solicitar el "acceso directo" (o passthrough) al cuerpo (p. 150)
son dos cosas distintas. Cuando una carga de solicitud no se puede validar porque no se
encuentra un esquema de modelo coincidente, puede elegir acceder directamente a ella
(passthrough) o bloquear la carga original. Por ejemplo, cuando se habilita la validación de
solicitudes con una plantilla de mapeo para el tipo de medios application/json, es posible
que desee transmitir una carga XML a través del backend aún sabiendo que la validación de
solicitudes habilitada devolverá un error. Este puede ser el caso si espera que la carga XML sea
compatible con el método en el futuro. Para que la solicitud con una carga XML devuelva un
error, debe elegir la opción NEVER en el comportamiento de "acceso directo" (o passthrough) del
contenido.
Configurar la validación básica de solicitudes en API

Gateway
Puede configurar validadores de solicitudes en un archivo de definición de Swagger de la API y después
importar las definiciones de Swagger en API Gateway. También puede configurarlas en la consola de API
Gateway o llamando a la API REST de API Gateway, la CLI de AWS o uno de los SDK de AWS. Aquí,
le mostramos cómo hacer esto con un archivo de Swagger, en la consola, y usando la API REST de API
Gateway.
Temas
• Configurar la validación básica de solicitudes importando la definición de Swagger de la API (p. 166)
• Configurar validadores de solicitudes mediante la API REST de API Gateway (p. 169)
• Configurar la validación básica de solicitudes mediante la consola de API Gateway (p. 170)
Configurar la validación básica de solicitudes importando la

definición de Swagger de la API
Los siguientes pasos describen cómo habilitar la validación básica de solicitudes importando un archivo de
Swagger.
Para habilitar la validación de solicitudes importando un archivo de Swagger en API Gateway
1. Declare los validadores de solicitudes en Swagger especificando un conjunto de los objetos Objeto
x-amazon-apigateway-request-validators.requestValidator (p. 392) en el mapa Objeto x-amazon-
166
Configurar la validación básica
de solicitudes en API Gateway
apigateway-request-validators (p. 391) en el nivel de API. Por ejemplo, el archivo de Swagger de

la API de ejemplo (p. 174) contiene el mapa x-amazon-apigateway-request-validators, con los
nombres de los validadores como claves.
{
"swagger": "2.0",
"info": {
"title": “ReqValidation Sample",
"version": "1.0.0"
},
"schemes": [
"https"
],
"basePath": "/v1",
"produces": [
"application/json"
],
"x-amazon-apigateway-request-validators" : {
"all" : {
"validateRequestBody" : true,
"validateRequestParameters" : true
},
"params-only" : {
"validateRequestBody" : false,
}
},
...
}
El nombre de un validador se selecciona cuando se habilita el validador en la API o en un método, tal

y como se muestra en el siguiente paso.
2. Para habilitar un validador de solicitudes en todos los métodos de una API, especifique una propiedad
Propiedad x-amazon-apigateway-request-validator (p. 391) en el nivel de API del archivo de
definición de Swagger de la API. Para habilitar un validador de solicitudes para un método individual,
especifique la propiedad x-amazon-apigateway-request-validator en el nivel de método. Por
ejemplo, la siguiente propiedad x-amazon-apigateway-request-validator habilita el validador
params-only en todos los métodos de la API, a menos que se invalide de otro modo.
{
"swagger": "2.0",
"info": {
"version": "1.0.0"
},
"schemes": [
"https"
],
"basePath": "/v1",
"produces": [
"application/json"
],
...
"x-amazon-apigateway-request-validator" : "params-only",
...
}
Para habilitar un validador de solicitudes para un método individual, especifique la propiedad x-

amazon-apigateway-request-validator en el nivel de método. Por ejemplo, la siguiente propiedad
x-amazon-apigateway-request-validator habilita el validador all en el método POST /validation.
Este validador invalida el validador params-only que se hereda de la API.
167
{
"swagger": "2.0",
"info": {
"version": "1.0.0"
},
"schemes": [
"https"
],
"basePath": "/v1",
"produces": [
"application/json"
],
...
"paths": {
"/validation": {
"post": {
"x-amazon-apigateway-request-validator" : "all",
...
},
...
}
}
...
}
3. En API Gateway, cree la API con validadores de solicitudes habilitados importando esta definición de
Swagger de la API de ejemplo (p. 174):
POST /restapis?mode=import&failonwarning=true HTTP/1.1

Host: apigateway.us-east-1.amazonaws.com
X-Amz-Date: 20170306T234936Z
Authorization: AWS4-HMAC-SHA256 Credential={access_key_ID}/20170306/us-east-1/
Signature={sig4_hash}
Copy the JSON object from this API Swagger Definition (p. 174) and paste it here.
4. Implemente la API recién creada (fjd6crafxc) en una etapa específica (testStage).
POST /restapis/fjd6crafxc/deployments HTTP/1.1

X-Amz-Date: 20170306T234936Z
{
"stageName" : "testStage",
"stageDescription" : "Test stage",
"description" : "First deployment",
"cacheClusterEnabled" : "false"
}
Para obtener instrucciones sobre cómo probar la validación de solicitudes mediante la API REST
de API Gateway, consulte Probar la validación básica de solicitudes mediante la API REST de API
Gateway (p. 171). Para obtener instrucciones sobre cómo realizar las pruebas mediante la consola
168
de API Gateway, consulte Probar la validación básica de solicitudes mediante la consola de API
Gateway (p. 173).
Configurar validadores de solicitudes mediante la API REST de

API Gateway
En la API REST de API Gateway, un validador de solicitudes se representa mediante un recurso
RequestValidator. Para que una API admita los mismos validadores de solicitudes que la API de
ejemplo (p. 174), añada la colección RequestValidators como un validador de solo parámetros con
params-only como la clave y añada un validador completo con all como su clave.
Para habilitar la validación básica de solicitudes mediante la API REST de API Gateway
Suponemos que tiene una API similar a la API de ejemplo (p. 174), pero que no ha configurado
validadores de solicitudes. Si su API ya tiene validadores de solicitudes, llame a la acción
requestvalidator:update o method:put correspondiente en lugar de a requestvalidator:create o
method:put.
1. Para configurar el validador de solicitudes params-only, llame a la acción requestvalidator:create de la

siguiente manera:
POST /restapis/restapi-id/requestvalidators HTTP/1.1

Host: apigateway.region.amazonaws.com
X-Amz-Date: 20170223T172652Z
Authorization: AWS4-HMAC-SHA256 Credential={access_key_ID}/20170223/region/apigateway/
aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature={sig4_hash}
{
"name" : "params-only",
"validateRequestBody" : "false",
"validateRequestParameters" : "true"
}
2. Para configurar el validador de solicitudes all, llame a la acción requestvalidator:create del

siguiente modo:
POST /restapis/restapi-id/requestvalidators HTTP/1.1

X-Amz-Date: 20170223T172652Z
{
"name" : "all",
"validateRequestBody" : "true",
"validateRequestParameters" : "true"
}
Si las claves del validador anteriores ya existen en el mapa RequestValidators, llame a la acción
requestvalidator:update en lugar de restablecer las reglas de validación.
3. Para aplicar el validador de solicitudes all al método POST, llame a method:put para habilitar el
validador especificado (identificado por la propiedad requestValidatorId) o llame a method:update para
actualizar el validador habilitado.
PUT /restapis/restapi-id/resources/resource-id/methods/POST HTTP/1.1

169
X-Amz-Date: 20170223T172652Z
{
"authorizationType" : "NONE",
...,
"requestValidatorId" : "all"
}
Configurar la validación básica de solicitudes mediante la consola

de API Gateway
La consola de API Gateway le permite configurar la validación básica de solicitudes en un método
mediante uno de estos tres validadores:
• Validate body: este es el validador de solo el cuerpo.

• Validate query string parameters and headers: este es el validador de solo los parámetros.
• Validate body, query string parameters, and headers: este es el validador del cuerpo y de los
parámetros.
Cuando elige uno de los validadores anteriores para habilitarlo en un método de la API, la consola de API
Gateway lo añade al mapa RequestValidators de la API, si aún no se ha añadido al mapa de validadores
de la API.
Para habilitar un validador de solicitudes en un método
1. Inicie sesión en la consola API Gateway, si aún no lo ha hecho.

2. Cree una nueva API o elija una existente.
3. Cree un nuevo recurso de la API o elija uno existente.
4. Cree un nuevo método o elija uno existente para el recurso.
5. Elija Method Request.
6. Elija el icono de lápiz de Request Validator en Settings.
7. Elija Validate body, Validate query string parameters and headers o Validate body, query
string parameters, and headers en la lista desplegable Request Validator y, a continuación, elija el
icono de marca de verificación para guardar la selección.
170
Probar la validación básica de solicitudes en API Gateway
Para probar y utilizar el validador de solicitudes en la consola, siga las instrucciones de Probar la validación
básica de solicitudes mediante la consola de API Gateway (p. 173).
Probar la validación básica de solicitudes en API

Gateway
Elija uno de los siguientes temas para obtener instrucciones sobre cómo probar la validación básica de
solicitudes en la API de ejemplo (p. 174).
Temas
• Probar la validación básica de solicitudes mediante la API REST de API Gateway (p. 171)
• Probar la validación básica de solicitudes mediante la consola de API Gateway (p. 173)
Probar la validación básica de solicitudes mediante la API REST

de API Gateway
Para ver la URL de invocación de la API implementada, puede exportar la API desde la etapa,
asegurándose de incluir el encabezado Accept: application/json o Accept: application/yaml:
GET /restapis/fjd6crafxc/stages/testStage/exports/swagger?extensions=validators HTTP/1.1

X-Amz-Date: 20170306T234936Z
Puede omitir el parámetro de consulta ?extensions=validators, si no desea descargar las

especificaciones de Swagger relacionadas con la validación de solicitudes.
Para probar la validación de solicitudes mediante llamadas a la API REST de API Gateway
1. Llame a GET /validation?q1=cat.
GET /testStage/validation?q1=cat HTTP/1.1

Host: fjd6crafxc.execute-api.us-east-1.amazonaws.com
Como el parámetro obligatorio q1 está establecido y no está en blanco, la solicitud supera la

validación. API Gateway devuelve la siguiente respuesta 200 OK:
[
{
"id": 1,
"type": "cat",
"price": 249.99
},
{
"id": 2,
"type": "cat",
"price": 124.99
},
{
171
"id": 3,
"type": "cat",
"price": 0.99
}
]
2. Llame a GET /validation.
GET /testStage/validation HTTP/1.1

Host: fjd6crafxc.beta.execute-api.us-east-1.amazonaws.com
Como el parámetro obligatorio q1 no está establecido, la solicitud no supera la validación. API

Gateway devuelve la siguiente respuesta 400 Bad Request:
{
"message": "Missing required request parameters: [q1]"
}
3. Llame a GET /validation?q1=.
GET /testStage/validation?q1= HTTP/1.1

Como el parámetro obligatorio q1 está en blanco, la solicitud no supera la validación. API Gateway
devuelve la misma respuesta 400 Bad Request que en el ejemplo anterior.
4. Llame a POST /validation.
POST /testStage/validation HTTP/1.1

h1: v1
{
"name" : "Marco",
"type" : "dog",
"price" : 260
}
Como que el parámetro de encabezado obligatorio h1 está establecido y no está en blanco y el

formato de la carga se atiene a las propiedades RequestDataModel necesarias y las restricciones
asociadas, la solicitud supera la validación. API Gateway devuelve la siguiente respuesta correcta.
{
"pet": {
"name": "Marco",
"type": "dog",
"price": 260
},
}
5. Llame a POST /validation, sin especificar el encabezado h1 o dejando su valor en blanco.
172
{
"name" : "Marco",
"type" : "dog",
"price" : 260
}
Como el parámetro de encabezado obligatorio h1 no está presente o está en blanco, la solicitud no

supera la validación. API Gateway devuelve la siguiente respuesta 400 Bad Request:
{
"message": "Missing required request parameters: [h1]"
}
6. Llame POST /validation, estableciendo la propiedad type de la carga en bird.

X-Amz-Date: 20170309T000215Z
h1: v1
{
"name" : "Molly",
"type" : "bird",
"price" : 269
}
Como el valor de la propiedad type no es miembro de la enumeración ["dog", "cat", "fish"], la

solicitud no supera la validación. API Gateway devuelve la siguiente respuesta 400 Bad Request:
{
"message": "Invalid request body"
}
El establecimiento de price en 501 infringe la restricción de la propiedad. Esto hace que no se supere
la validación y que se devuelva la misma respuesta 400 Bad Request.
Probar la validación básica de solicitudes mediante la consola de

API Gateway
Los siguientes pasos describen cómo probar la validación básica de solicitudes en la consola de API
Gateway.
Para probar la validación de solicitudes en un método utilizando TestInvoke en la consola de API

Gateway
Con una sesión iniciada en la consola de API Gateway, haga lo siguiente:
1. Elija Resources para la API para la que ha configurado un mapa de validadores de solicitudes.
2. Elija un método para el que haya habilitado la validación de solicitudes con un validador de solicitudes
especificado.
3. En Method Execution, en el cuadro Client, elija Test.
173
Definiciones de Swagger de una API de
ejemplo con la validación básica de solicitudes
4. Pruebe diferentes valores para el parámetro de solicitud obligatorio o el cuerpo aplicable y, a

continuación, elija Test para ver la respuesta.
Cuando la llamada al método supere la validación, debe obtener las respuestas esperadas. Si no se
supera la validación, se devuelve el siguiente mensaje de error si la carga no tiene el formato correcto:
{
"message": "Invalid request body"
}
Si los parámetros de solicitud no son válidos, se devuelve el siguiente mensaje de error:
{
"message": "Missing required request parameters: [p1]"
}
Definiciones de Swagger de una API de ejemplo con

la validación básica de solicitudes
La siguiente definición de Swagger define una API de ejemplo con la validación de solicitudes habilitada.
La API es un subconjunto de la API PetStore. Expone un método POST para añadir una mascota a la
colección pets y un método GET para consultar las mascotas de un tipo especificado.
Hay dos validadores de solicitudes declarados en el mapa x-amazon-apigateway-request-validators

en el nivel de API. El validador params-only está habilitado en la API y lo hereda el método GET. Este
validador permite a API Gateway verificar que el parámetro de consulta obligatorio (q1) está incluido y no
está en blanco en la solicitud de entrada. El validador all está habilitado en el método POST. Este validador
verifica que el parámetro de encabezado obligatorio (h1) está establecido y no está en blanco. También
verifica que el formato de la carga sigue el esquema RequestBodyModel especificado. Este modelo exige
que el objeto JSON de entrada contenga las propiedades name, type y price. La propiedad name puede
ser cualquier cadena, type debe ser uno de los campos de la enumeración especificada (["dog", "cat",
"fish"]) y price debe estar comprendido entre 25 y 500. El parámetro id no es obligatorio.
Para obtener más información sobre el comportamiento de esta API, consulte Habilitar la validación básica
de solicitudes para una API en API Gateway (p. 165).
{
"swagger": "2.0",
"info": {
"title": "ReqValidators Sample",
"version": "1.0.0"
},
"schemes": [
"https"
],
"basePath": "/v1",
"produces": [
"application/json"
],
"all" : {
},
"params-only" : {
174
}
},
"paths": {
"/validation": {
"post": {
"x-amazon-apigateway-request-validator" : "all",
"parameters": [
{
"in": "header",
"name": "h1",
"required": true
},
{
"in": "body",
"name": "RequestBodyModel",
"required": true,
"schema": {
"$ref": "#/definitions/RequestBodyModel"
}
}
],
"responses": {
"200": {
"schema": {
"type": "array",
"items": {
"$ref": "#/definitions/Error"
}
},
"headers" : {
"test-method-response-header" : {
"type" : "string"
}
}
}
},
"security" : [{
"api_key" : []
}],
"x-amazon-apigateway-auth" : {
"type" : "none"
},
"x-amazon-apigateway-integration" : {
"type" : "http",
"uri" : "http://petstore-demo-endpoint.execute-api.com/petstore/pets",
"httpMethod" : "POST",
"integration.request.header.custom_h1": "method.request.header.h1"
},
"responses" : {
"2\\d{2}" : {
"statusCode" : "200"
},
"default" : {
"statusCode" : "400",
"method.response.header.test-method-response-header" : "'static value'"
},
"responseTemplates" : {
"application/json" : "json 400 response template",
"application/xml" : "xml 400 response template"
}
}
}
175
}
},
"get": {
"parameters": [
{
"name": "q1",
"in": "query",
"required": true
}
],
"responses": {
"200": {
"schema": {
"type": "array",
"items": {
"$ref": "#/definitions/Error"
}
},
"headers" : {
"test-method-response-header" : {
"type" : "string"
}
}
}
},
"security" : [{
"api_key" : []
}],
"x-amazon-apigateway-auth" : {
"type" : "none"
},
"type" : "http",
"uri" : "http://petstore-demo-endpoint.execute-api.com/petstore/pets",
"integration.request.querystring.type": "method.request.querystring.q1"
},
"responses" : {
"2\\d{2}" : {
},
"default" : {
},
"application/json" : "json 400 response template",
"application/xml" : "xml 400 response template"
}
}
}
}
}
}
},
"definitions": {
"RequestBodyModel": {
"type": "object",
"properties": {
"id": { "type": "integer" },
"type": { "type": "string", "enum": ["dog", "cat", "fish"] },
"name": { "type": "string" },
"price": { "type": "number", "minimum": 25, "maximum": 500 }
},
176
Documentar una API
"required": ["type", "name", "price"]

},
"Error": {
"type": "object",
"properties": {
}
}
}
}
Documentar una API de API Gateway

Para ayudar a los clientes a comprender y utilizar la API, debe documentar la API. Para ayudar a
documentar su API, API Gateway le permite añadir y actualizar el contenido de la ayuda de las distintas
entidades de API como parte integral de su proceso de desarrollo de la API. API Gateway almacena
el contenido de origen y le permite archivar diferentes versiones de la documentación. Puede asociar
una versión de la documentación a una etapa de la API, exportar una snapshot de documentación
específica de la etapa a un archivo de Swagger externo y distribuir el archivo como una publicación de la
documentación.
Para documentar la API, puede llamar a la API REST de API Gateway, utilizar uno de los SDK de AWS
o la AWS CLI de API Gateway o usar la consola de API Gateway. Además, puede importar o exportar
las piezas de la documentación definidas en un archivo de Swagger externo. Antes de explicar cómo
documentar su API, le mostraremos cómo se representa la documentación de la API en API Gateway.
Temas
• Representación de la documentación de la API en API Gateway (p. 177)
• Documentar una API mediante la consola de API Gateway (p. 185)
• Documentar una API mediante la API REST de API Gateway (p. 193)
• Publicar la documentación de API (p. 209)
• Importar la documentación de API (p. 214)
• Controlar el acceso a la documentación de la API (p. 216)
Representación de la documentación de la API en API

Gateway
La documentación de la API de API Gateway consta de piezas de documentación individuales asociadas
a entidades de API específicas que incluyen la API, el recurso, el método, la solicitud, las respuestas, los
parámetros de mensaje (como ruta, consulta, encabezado), así como autorizadores y modelos.
En API Gateway, una pieza de documentación se representa mediante un recurso DocumentationPart. La

documentación de la API en su conjunto se representa mediante la colección DocumentationParts.
Documentar una API implica crear instancias de DocumentationPart, añadirlas a la colección

DocumentationParts y mantener versiones de las piezas de la documentación a medida que evolucione la
API.
Temas
• Piezas de la documentación (p. 178)
• Versiones de la documentación (p. 185)
177
Representación de la documentación
de la API en API Gateway
Piezas de la documentación
Un recurso DocumentationPart es un objeto JSON que almacena el contenido de la documentación
aplicable a una entidad de API determinada. Su campo properties incluye el contenido de la
documentación como un mapa de pares de clave-valor. Su propiedad location identifica la entidad de API
asociada.
La forma de un mapa de contenido lo determina usted, el desarrollador de la API. El valor del par de clave-
valor puede ser una cadena, un número, un valor booleano, un objeto o una matriz. La forma del objeto
location depende del tipo de entidad de destino.
El recurso DocumentationPart admite la herencia de contenido: el contenido de documentación de una

entidad de API se aplica a los elementos secundarios de dicha entidad. Para obtener más información
sobre la definición de entidades secundarias y la herencia de contenido, consulte Heredar contenido de
una entidad de API de especificación más general (p. 179).
Ubicación de una pieza de documentación

La propiedad location de una instancia DocumentationPart identifica una entidad de API a la que se
aplica el contenido asociado. La entidad de la API puede un recurso de API REST de API Gateway,
como RestApi, Resource, Method, MethodResponse, Authorizer o Model. La entidad también puede ser
un parámetro de mensaje, como un parámetro de ruta URL, un parámetro de cadena de consulta, un
parámetro de encabezado de solicitud o respuesta, una solicitud o cuerpo de respuesta o un código de
estado de respuesta.
Para especificar una entidad de API, establezca el atributo type del objeto location en API, AUTHORIZER,
MODEL, RESOURCE, METHOD, PATH_PARAMETER, QUERY_PARAMETER, REQUEST_HEADER, REQUEST_BODY, RESPONSE,
RESPONSE_HEADER o RESPONSE_BODY.
En función del type de una entidad de API, puede especificar otros atributos location, incluidos method,
name, path y statusCode. No todos estos atributos son válidos para una determinada entidad de API. Por
ejemplo, type, path, name y statusCode son atributos válidos de la entidad RESPONSE; solo type y path son
atributos de ubicación válidos de la entidad RESOURCE. Es un error incluir un campo no válido en el atributo
location de un recurso DocumentationPart para una determinada entidad de API.
No todos los campos location válidos son obligatorios. Por ejemplo, type es el campo location válido
y obligatorio para todas las entidades de API. Sin embargo, method, path y statusCode son válidos, pero
no son atributos obligatorios para la entidad RESPONSE. Cuando no se especifica explícitamente, un campo
location válido asume el valor predeterminado. El valor path predeterminado es /, es decir, el recurso
raíz de una API. El valor predeterminado de method o statusCode es *, que indica cualquier método o
valores de código de estado, respectivamente.
Contenido de una pieza de documentación

El valor properties está codificado como una cadena JSON. El valor properties contiene la información
que elija para satisfacer sus necesidades de documentación. Por ejemplo, el siguiente es un mapa de
contenido válido:
{
"info": {
"description": "My first API with Amazon API Gateway."
},
"x-custom-info" : "My custom info, recognized by Swagger.",
"my-info" : "My custom info not recognized by Swagger."
}
Para establecerlo como un valor de properties mediante la API REST de API Gateway codifique este
objeto como una cadena JSON:
178
"{\n\t\"info\": {\n\t\t\"description\": \"My first API with Amazon API Gateway.\"\n\t}, …

\n}"
Aunque API Gateway admite cualquier cadena JSON válida como mapa de contenido, los atributos de
contenido se tratan como dos categorías: los que reconoce Swagger y los que no. En el ejemplo anterior,
info, description y x-custom-info son atributos reconocidos por Swagger como un objeto, propiedad o
extensión estándar de Swagger. En cambio, my-info no es compatible con la especificación de Swagger.
API Gateway propaga los atributos de contenido compatibles con Swagger a las definiciones de entidad
de API de las instancias de DocumentationPart asociadas. API Gateway no propaga los atributos de
contenido no compatibles a las definiciones de entidad de API.
Veamos otro ejemplo; aquí DocumentationPart es el destino de una entidad Resource:
{
"location" : {
"type" : "RESOURCE",
"path": "/pets"
},
"properties" : {
"summary" : "The /pets resource represents a collection of pets in PetStore.",
"description": "... a child resource under the root...",
}
}
Tanto type como path son campos válidos para identificar el destino del tipo RESOURCE. Para el recurso
raíz (/), puede omitir el campo path.
{
"location" : {
"type" : "RESOURCE"
},
"properties" : {
"description" : "The root resource with the default path specification."
}
}
Es el mismo que la siguiente instancia de DocumentationPart:
{
"location" : {
"path": "/"
},
"properties" : {
"description" : "The root resource with an explicit path specification"
}
}
Heredar contenido de una entidad de API de especificaciones más generales

El valor predeterminado de un campo location opcional proporciona una descripción de los patrones de
una entidad de API. Con el valor predeterminado en el objeto location, puede añadir una descripción
general en el mapa properties a una instancia de DocumentationPart con este tipo de patrón location.
API Gateway extrae los atributos de documentación de Swagger aplicables de DocumentationPart de
la entidad de API genérica y los inserta en una entidad de API específica con los campos location con
valores que coinciden con el patrón location general o con el valor exacto, a menos que la entidad
especificada ya tenga una instancia de DocumentationPart asociada. Este comportamiento se denomina
también "herencia de contenido de una entidad de API de especificaciones más generales".
179
La herencia de contenido no se aplica a las entidades de API de tipo API, AUTHORIZER, METHOD, MODEL,
REQUEST_BODY o RESOURCE.
Cuando una entidad de API coincide con más de un patrón de ubicación de DocumentationPart, la entidad
heredará la pieza de documentación con los campos de ubicación que tengan mayor prioridad y sean más
específicos. El orden de prioridad es path > statusCode. Para la correspondencia con el campo path, API
Gateway elige la entidad con el valor de ruta más específico. En la siguiente tabla se muestra esto con
algunos ejemplos.
Caso path statusCode name Observaciones
1 /pets * id La
documentación
asociada
a
este
patrón
de
ubicación
la
heredarán
las
entidades
que
coincidan
con el
patrón
de
ubicación.
2 /pets 200 id La
documentación
asociada
a
este
patrón
de
ubicación
la
heredarán
las
entidades
que
coincidan
con el
patrón
de
ubicación
cuando
coincidan
tanto
Caso
1
como
Caso
2, ya
que
180
Caso path statusCode name Observaciones

Caso
2 es
más
específico
que
Caso
1.
3 /pets/ * id La
petId documentación
asociada
a
este
patrón
de
ubicación
la
heredarán
las
entidades
que
coincidan
con el
patrón
de
ubicación
cuando
los
tres
casos
coincidan,
ya
que
Caso
3
tiene
más
prioridad
que
Caso
2 y es
más
específico
que
Caso
1.
Este es otro ejemplo en el que se compara una instancia de DocumentationPart más genérica con
una más específica. El siguiente mensaje de error general "Invalid request error" se inserta en las
definiciones de Swagger de las respuestas de error 400, a menos que se invalide.
{
"location" : {
"type" : "RESPONSE",
"statusCode": "400"
181
},
"properties" : {
"description" : "Invalid request error."
}"
}
Con la siguiente invalidación, las respuestas 400 a cualquier método del recurso /pets tienen una
descripción de "Invalid petId specified" en su lugar.
{
"location" : {
"type" : "RESPONSE",
"path": "/pets",
"statusCode": "400"
},
"properties" : "{
"description" : "Invalid petId specified."
}"
}
Campos de ubicación válidos de DocumentationPart

En la siguiente tabla se muestran los campos válidos y obligatorios, así como los valores predeterminados
aplicables, de un recurso DocumentationPart asociado a un tipo de entidades de API determinado.
Entidad de Campos de ubicación válidos Campos de Valores de campo Contenido

API ubicación predeterminados heredable
obligatorios
API type N/D No

{
"location": {
"type": "API"
},
...
}
Recurso type El valor No

{
"location": { predeterminado de
"type": "RESOURCE", path es /.
"path":
"resource_path"
},
...
}
Método type Los valores Sí, buscando

{
"location": { predeterminados coincidencias
"type": "METHOD", de path y method de path por
"path": son / y *, prefijo y
"resource_path", respectivamente. buscando
"method": coincidencias
"http_verb" del elemento
},
method de
...
} cualquier
valor.
182

obligatorios
Parámetros type Los valores Sí, buscando

{
de "location": { predeterminados coincidencias
consulta "type": de path y method de path por
"QUERY_PARAMETER", son / y *, prefijo y
"path": respectivamente. buscando
"resource_path", coincidencias
"method": del elemento
"HTTP_verb",
method por
"name":
"query_parameter_name" los valores
}, exactos.
...
}
Cuerpo de type Los valores Sí, buscando

{
la solicitud "location": { predeterminados coincidencias
"type": "REQUEST", de path y method de path por
"path": son / y *, prefijo y
"resource_path", respectivamente. buscando
"method": coincidencias
"http_verb" del elemento
},
method por
...
} los valores
exactos.
Parámetro type, name Los valores Sí, buscando

{
encabezado "type": de path y method de path por
de "REQUEST_HEADER", son / y *, prefijo y
solicitud "path": respectivamente. buscando
"resource_path", coincidencias
"HTTP_verb",
method por
"name":
"header_name" los valores
}, exactos.
...
}
Parámetros type, name Los valores Sí, buscando

{
de ruta de "location": { predeterminados coincidencias
solicitud "type": de path y method de path por
"PATH_PARAMETER", son / y *, prefijo y
"path": "resource/ respectivamente. buscando
{path_parameter_name}", coincidencias
"HTTP_verb",
method por
"name":
"path_parameter_name" los valores
}, exactos.
...
}
183

obligatorios
Respuesta type Los valores Sí, buscando

{
"location": { predeterminados coincidencias
"type": "RESPONSE", de path, method de path por
"path": y statusCode prefijo y
"resource_path", son /, * y *, buscando
"method": respectivamente. coincidencias
"http_verb", de los
"statusCode":
elementos
"status_code"
}, method y
... statusCode
} por los valores
exactos.
Encabezado type, name Los valores Sí, buscando

{
respuesta "type": de path, method de path por
"RESPONSE_HEADER", y statusCode prefijo y
"path": son /, * y *, buscando
"resource_path", respectivamente. coincidencias
"method": de los
"http_verb",
elementos
"statusCode":
"status_code", method y
"name": statusCode
"header_name" por los valores
}, exactos.
...
}
Cuerpo de type Los valores Sí, buscando

{
respuesta "location": { predeterminados coincidencias
"type": de path, method de path por
"RESPONSE_BODY", y statusCode prefijo y
"path": son /, * y *, buscando
"resource_path", respectivamente. coincidencias
"method": de los
"http_verb",
elementos
"statusCode":
"status_code" method y
}, statusCode
... por los valores
} exactos.
Authorizer type N/D No

{
"location": {
"type":
"AUTHORIZER",
"name":
"authorizer_name"
},
...
}
184
Documentar una API mediante la consola de API Gateway

obligatorios
Model type N/D No

{
"location": {
"type": "MODEL",
"name": "model_name"
},
...
}
Versiones de la documentación
Una versión de documentación es una snapshot de la colección DocumentationParts de una API, que
está etiquetada con un identificador de versión. Publicar la documentación de una API implica crear una
versión de documentación, asociarla a una etapa de la API y exportar esa versión específica de la etapa
de la documentación de la API a un archivo de Swagger externo. En API Gateway, una snapshot de
documentación se representa como un recurso DocumentationVersion.
Cuando se actualiza una API, se crean nuevas versiones de la API. En API Gateway, todas las versiones
de documentación se mantienen mediante la colección DocumentationVersions.
Documentar una API mediante la consola de API

Gateway
En esta sección se describe cómo crear y mantener piezas de documentación de una API mediante la
Un requisito previo para crear y editar la documentación de una API es que ya debe haber creado la API.
En esta sección, usaremos la API PetStore como ejemplo. Para crear una API mediante la consola de API
Gateway, siga las instrucciones de Crear una API de API Gateway a partir de un ejemplo (p. 9).
Temas
• Documentar la entidad API (p. 185)
• Documentar una entidad RESOURCE (p. 188)
• Documentar una entidad METHOD (p. 188)
• Documentar una entidad QUERY_PARAMETER (p. 189)
• Documentar una entidad PATH_PARAMETER (p. 190)
• Documentar una entidad REQUEST_HEADER (p. 190)
• Documentar una entidad REQUEST_BODY (p. 191)
• Documentar una entidad RESPONSE (p. 191)
• Documentar una entidad RESPONSE_HEADER (p. 191)
• Documentar una entidad RESPONSE_BODY (p. 192)
• Documentar una entidad MODEL (p. 192)
• Documentar una entidad AUTHORIZER (p. 193)
Documentar la entidad API

Para añadir una parte de documentación para la entidad API, elija Resources desde la API PetStore. Elija
el elemento de menú Actions → Edit API Documentation.
185
Si no se creó una pieza de documentación para la API, verá el editor del mapa properties de la pieza
de documentación. Escriba el siguiente mapa properties en el editor de texto y, a continuación, elija la
opción Save para crear la parte de documentación.
{
"info": {
"description": "Your first API Gateway API.",
"contact": {
"name": "John Doe",
"email": "[email protected]"
}
}
}
Note
No codifique el mapa properties en una cadena JSON, como cuando usa la API REST
de API Gateway. La consola de API Gateway representa el objeto JSON en una cadena
automáticamente.
186
Si ya se ha creado una pieza de documentación, primero verá el visor del mapa properties, que se
muestra a continuación.
187
Al elegir Edit se abre el editor del mapa properties que se mostró anteriormente.
Documentar una entidad RESOURCE

Para añadir o editar la parte de documentación del recurso raíz de la API, elija / en el árbol Resource y, a
continuación, elija el elemento de menú Actions → Edit Resource Documentation.
Si no se han creado partes de documentación para esta entidad, verá la ventana Documentation.
Especifique un mapa properties válido en el editor. A continuación, elija Save y Close.
{
"description": "The PetStore's root resource."
}
Si ya se ha definido una pieza de documentación para la entidad RESOURCE, verá el visor de

documentación. Elija Edit para abrir el editor Documentation. Modifique el mapa properties existente. Elija
Save y, a continuación, elija Close.
Si es necesario, repita estos pasos para añadir una pieza de documentación a otras entidades RESOURCE.
Documentar una entidad METHOD

Para añadir o editar la documentación de una entidad METHOD, utilizando el método GET en el recurso
raíz como ejemplo, elija GET en el recurso / y después elija el elemento de menú Actions → Edit Method
Documentation.
188
Para la nueva parte de documentación, especifique el siguiente mapa properties en el editor

Documentation en la ventana Documentation. A continuación, elija Save y Close.
{
"tags" : [ "pets" ],
"description" : "PetStore HTML web page containing API usage information"
}
Para la documentación existente, elija Edit desde el visor Documentation. Edite el contenido de la
documentación en el editor Documentation y elija Save. Seleccione la opción Close.
Desde el visor Documentation, también puede eliminar la parte de documentación.
Si es necesario, repita estos pasos para añadir una pieza de documentación a otros métodos.
Documentar una entidad QUERY_PARAMETER

Para añadir o editar una parte de documentación para un parámetro de consulta de solicitud, utilizando el
método GET /pets?type=...&page=... como ejemplo, elija GET en /pets desde el árbol Resources. Elija
Method Request en la ventana Method Execution. Amplíe la sección URL Query String Parameters. Elija el
parámetro de consulta page, por ejemplo, y elija el icono de libro para abrir el visor o editor Documentation.
También puede elegir Documentation en la API PetStore desde el panel de navegación principal. A
continuación, elija Query Parameter para Type. Para la API de ejemplo PetStore, se muestran las piezas
de documentación para los parámetros de consulta page y type.
189
Para una API con los parámetros de consulta definidos para otros métodos, puede filtrar la selección
especificando el elemento path del recurso afectado para Path, eligiendo el método HTTP deseado de
Method o especificando el nombre de parámetro de consulta en Name.
Por ejemplo, elija el parámetro de consulta page. Elija Edit para modificar la documentación existente. Elija
Save para guardar el cambio.
Para añadir una nueva parte de documentación para una entidad QUERY_PARAMETER, elija Create
Documentation Part. Elija Query Parameter para Type. Escriba una ruta de recurso (p. ej., /pets) en Path.
Elija un verbo HTTP (p. ej., GET) para Method. Escriba una descripción de properties en el editor de texto.
A continuación, elija Save.
Si es necesario, repita estos pasos para añadir una pieza de documentación a otros parámetros de
consulta de solicitud.
Documentar una entidad PATH_PARAMETER

Para añadir o editar la documentación de un parámetro de ruta, vaya a Method Request del método en
el recurso especificado mediante el parámetro de ruta. Amplíe la sección Request Paths. Elija el icono de
libro del parámetro de ruta para abrir el visor o editor Documentation. Añada o modifique las propiedades
de la pieza de documentación.
También puede elegir Documentation en la API PetStore desde el panel de navegación principal. Elija
Path Parameter para Type. Elija Edit en un parámetro de ruta de la lista. Modifique el contenido y, a
continuación, elija Save.
Para añadir documentación para un parámetro de ruta no mostrado, elija Create Documentation Part. Elija
Path Parameter para Type. Defina una ruta de recurso en Path, elija un método de Method y defina un
nombre de parámetro de ruta en Name. Añada las propiedades de la documentación y elija Save.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación a otros parámetros de
ruta.
Documentar una entidad REQUEST_HEADER

Para añadir o editar la documentación de un encabezado de solicitud, vaya a Method Request del método
con el parámetro de encabezado. Amplíe la sección HTTP Request Headers. Elija el icono de libro del
encabezado para abrir el visor o editor Documentation. Añada o modifique las propiedades de la pieza de
documentación.
190
También puede elegir Documentation en la API desde el panel de navegación principal. A continuación,
elija Request Header para Type. Elija Edit en un encabezado de solicitud mostrado para cambiar la
documentación. Para añadir documentación para un encabezado de solicitud no mostrado, elija Create
Documentation Part. Elija Request Header para Type. Especifique una ruta de recurso en Path. Elija un
método para Method. Escriba un nombre de encabezado en Name. A continuación, añada y guarde un
mapa properties.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación para otros
encabezados de solicitud.
Documentar una entidad REQUEST_BODY

Para añadir o editar documentación para un cuerpo de solicitud, vaya a Method Request para un método.
Elija el icono de libro de Request Body para abrir el visor y después el editor Documentation. Añada o
modifique las propiedades de la pieza de documentación.
elija Request Body para Type. Elija Edit en un cuerpo de solicitud mostrado para cambiar la
documentación. Para añadir documentación para un cuerpo de solicitud no mostrado, elija Create
Documentation Part. Elija Request Body para Type. Establezca una ruta de recurso en Path. Elija un verbo
HTTP para Method. A continuación, añada y guarde un mapa properties.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación para otros cuerpos de
solicitud.
Documentar una entidad RESPONSE

Para añadir o editar documentación para un cuerpo de respuesta, vaya a Method Response para un
método. Elija el icono de libro de Method Response para abrir el visor y después el editor Documentation.
Añada o modifique las propiedades de la pieza de documentación.
elija Response (status code) para Type. Elija Edit en una respuesta mostrada de un código de estado
HTTP especificado para cambiar la documentación. Para añadir documentación para una respuesta
de solicitud no mostrado, elija Create Documentation Part. Elija Response (status code) para Type.
Establezca una ruta de recurso en Path. Elija un verbo HTTP para Method. Especifique un código
de estado HTTP en Status Code. A continuación, añada y guarde las propiedades de la pieza de
documentación.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación para otras respuestas
de solicitud.
Documentar una entidad RESPONSE_HEADER

Para añadir o editar documentación para un encabezado de respuesta, vaya a Method Response para un
método. Expanda una sección de respuesta de un determinado estado HTTP. Elija el icono de libro para
191
un encabezado de respuesta en Response Headers for StatusCode para abrir el visor y después el editor
Documentation. Añada o modifique las propiedades de la pieza de documentación.
elija Response Header para Type. Elija Edit en una respuesta de solicitud mostrada para cambiar la
documentación. Para añadir documentación para una respuesta de solicitud no mostrada, elija Create
Documentation Part. Elija Response Header para Type. Establezca una ruta de recurso en Path. Elija
un verbo HTTP para Method. Especifique un código de estado HTTP en Status Code. Escriba el nombre
de encabezado de respuesta en Name. A continuación, añada y guarde las propiedades de la pieza de
documentación.
encabezados de respuesta.
Documentar una entidad RESPONSE_BODY

Para añadir o editar documentación para un cuerpo de respuesta, vaya a Method Response para un
método. Expanda la sección de respuesta de un determinado estado HTTP. Elija el icono de libro de
Response Body for StatusCode para abrir el visor y después el editor Documentation Añada o modifique
las propiedades de la pieza de documentación.
elija Response Body para Type. Elija Edit en un cuerpo de respuesta mostrada para cambiar la
documentación. Para añadir documentación para una respuesta de solicitud no mostrado, elija Create
Documentation Part. Elija Response Body para Type. Establezca una ruta de recurso en Path. Elija un
verbo HTTP para Method. Especifique un código de estado HTTP en Status Code. A continuación, añada y
guarde las propiedades de la pieza de documentación.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación para otros cuerpos de
respuesta.
Documentar una entidad MODEL

Documentar una entidad MODEL implica crear y administrar instancias de DocumentPart para el modelo y
para todas las properties del modelo. Por ejemplo, el modelo Error integrado con cada API de manera
predeterminada tiene la siguiente definición de esquema
{
"$schema" : "http://json-schema.org/draft-04/schema#",
"title" : "Error Schema",
"type" : "object",
"properties" : {
"message" : { "type" : "string" }
}
}
y requiere dos instancias de DocumentationPart, una para Model y otra para su propiedad message:
{
"location": {
"type": "MODEL",
"name": "Error"
},
"properties": {
"title": "Error Schema",
"description": "A description of the Error model"
}
}
192
Documentar una API mediante
la API REST de API Gateway
{
"location": {
"type": "MODEL",
"name": "Error.message"
},
"properties": {
"description": "An error message."
}
}
Cuando se exporta la API, las propiedades de DocumentationPart invalidarán los valores del esquema
original.
Para añadir o editar la documentación para un modelo, vaya a Modelos de la API en el panel de
navegación principal. Elija el icono de libro para el nombre de un modelo mostrado para abrir el visor y
después el editor Documentation. Añada o modifique las propiedades de la pieza de documentación.
elija Model para Type. Elija Edit en un modelo mostrado para cambiar la documentación. Para añadir
documentación para un modelo no mostrado, elija Create Documentation Part. Elija Model para Type.
Especifique un nombre para el modelo en Nombre. A continuación, añada y guarde las propiedades de la
pieza de documentación.
Si es necesario, repita estos pasos para añadir o editar una pieza de documentación para otros modelos.
Documentar una entidad AUTHORIZER

Para añadir o editar la documentación para un autorizador, vaya a Authorizers para la API en el panel de
navegación principal. Elija el icono de libro para el autorizador mostrado para abrir el visor y después el
editor Documentation. Añada o modifique las propiedades de la pieza de documentación.
elija Authorizer para Type. Elija Edit en un autorizador mostrado para cambiar la documentación. Para
añadir documentación para un autorizador no mostrado, elija Create Documentation Part. Elija Authorizer
para Type. Especifique un nombre para el autorizador en Nombre. A continuación, añada y guarde las
propiedades de la pieza de documentación.
autorizadores.
Para añadir una parte de documentación para un autorizador, elija Create Documentation Part. Elija
Authorizer para Type. Especifique un valor para el campo location válido de Name para el autorizador.
Añada y guarde el contenido de la documentación en el editor del mapa properties.
Si es necesario, repita estos pasos para añadir una pieza de documentación a otro autorizador.
Documentar una API mediante la API REST de API

Gateway
En esta sección se describe cómo crear y mantener piezas de documentación de una API mediante la API
REST de API Gateway.
Antes de crear y editar la documentación de una API, primero debe crear la API. En esta sección,
usaremos la API PetStore como ejemplo. Para crear una API mediante la consola de API Gateway, siga
las instrucciones de Crear una API de API Gateway a partir de un ejemplo (p. 9).
193
Temas
• Documentar la entidad API (p. 194)
• Documentar una entidad RESOURCE (p. 195)
• Documentar una entidad METHOD (p. 198)
• Documentar una entidad QUERY_PARAMETER (p. 200)
• Documentar una entidad PATH_PARAMETER (p. 201)
• Documentar una entidad REQUEST_BODY (p. 202)
• Documentar una entidad REQUEST_HEADER (p. 203)
• Documentar una entidad RESPONSE (p. 203)
• Documentar una entidad RESPONSE_HEADER (p. 204)
• Documentar una entidad AUTHORIZER (p. 205)
• Documentar una entidad MODEL (p. 206)
• Actualizar piezas de documentación (p. 208)
• Mostrar piezas de documentación (p. 208)
Documentar la entidad API

Para añadir documentación para una API, añada un recurso DocumentationPart a la entidad de API:
POST /restapis/restapi_id/documentation/parts HTTP/1.1

X-Amz-Date: YYYYMMDDTttttttZ
Authorization: AWS4-HMAC-SHA256 Credential=access_key_id/YYYYMMDD/region/
Signature=sigv4_secret
{
"location" : {
"type" : "API"
},
"properties": "{\n\t\"info\": {\n\t\t\"description\" : \"Your first API with Amazon API
Gateway.\"\n\t}\n}"
}
Si es correcta, la operación devuelve una respuesta 201 Created que contiene la instancia
DocumentationPart recién creada en la carga. Por ejemplo:
{
...
"id": "s2e5xf",
"location": {
"path": null,
"method": null,
"name": null,
"statusCode": null,
"type": "API"
},
"properties": "{\n\t\"info\": {\n\t\t\"description\" : \"Your first API with Amazon API
Gateway.\"\n\t}\n}"
}
Si ya se ha añadido la pieza de documentación, se devuelve una respuesta 409 Conflict, que contiene
el mensaje de error de Documentation part already exists for the specified location: type
'API'." En este caso, debe llamar a la operación documentationpart:update.
194
PATCH /restapis/4wk1k4onj3/documentation/parts/part_id HTTP/1.1

{
"op" : "replace",
"path" : "/properties",
"value" : "{\n\t\"info\": {\n\t\t\"description\" : \"Your first API with Amazon API
Gateway.\"\n\t}\n}"
} ]
}
La respuesta correcta devuelve un código de estado 200 OK con la carga que contiene la instancia
DocumentationPart actualizada en la carga.
Documentar una entidad RESOURCE

Para añadir documentación para el recurso raíz de una API, añada el recurso DocumentationPart de
destino para el recurso Resource correspondiente:

{
"location" : {
},
"properties" : "{\n\t\"description\" : \"The PetStore root resource.\"\n}"
}
{
"_links": {
"curies": {
documentationpart-{rel}.html",
"name": "documentationpart",
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/p76vqo"
},
"documentationpart:delete": {
},
"documentationpart:update": {
}
},
195
"id": "p76vqo",
"location": {
"path": "/",
"method": null,
"name": null,
"statusCode": null,
"type": "RESOURCE"
},
"properties": "{\n\t\"description\" : \"The PetStore root resource.\"\n}"
}
Cuando no se especifica la ruta del recurso, se considera que el recurso es el recurso raíz. Puede añadir
"path": "/" a properties para que la especificación sea explícita.
Para crear documentación para un recurso secundario de una API, añada el recurso DocumentationPart de
destino para el recurso Resource correspondiente:

{
"location" : {
"path" : "/pets"
},
"properties": "{\n\t\"description\" : \"A child resource under the root of PetStore.
\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/qcht86"
},
},
}
},
"id": "qcht86",
"location": {
"path": "/pets",
"method": null,
"name": null,
"statusCode": null,
"type": "RESOURCE"
},
196
"properties": "{\n\t\"description\" : \"A child resource under the root of PetStore.

\"\n}"
}
Para agregar documentación para un recurso secundario especificado por un parámetro de ruta, añada un
recurso DocumentationPart de destino para el recurso Resource correspondiente:

{
"location" : {
"path" : "/pets/{petId}"
},
"properties": "{\n\t\"description\" : \"A child resource specified by the petId path
parameter.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/k6fpwb"
},
},
}
},
"id": "k6fpwb",
"location": {
"path": "/pets/{petId}",
"method": null,
"name": null,
"statusCode": null,
"type": "RESOURCE"
},
"properties": "{\n\t\"description\" : \"A child resource specified by the petId path
parameter.\"\n}"
}
Note
La instancia de DocumentationPart de una entidad RESOURCE no la pueden heredar sus recursos

secundarios.
197
Documentar una entidad METHOD

Para agregar documentación para un método de una API, añada un recurso DocumentationPart de destino
para el recurso Method correspondiente:

{
"location" : {
"type" : "METHOD",
"path" : "/pets",
"method" : "GET"
},
"properties": "{\n\t\"summary\" : \"List all pets.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/o64jbj"
},
},
}
},
"id": "o64jbj",
"location": {
"path": "/pets",
"method": "GET",
"name": null,
"statusCode": null,
"type": "METHOD"
},
}
{
"_links": {
"curies": {
198
"templated": true
},
"self": {
},
},
}
},
"id": "o64jbj",
"location": {
"path": "/pets",
"method": "GET",
"name": null,
"statusCode": null,
"type": "METHOD"
},
}
Si no se especifica el campo location.method en la solicitud anterior, se supone que se trata del método
ANY, representado por un carácter comodín: *.
Para actualizar el contenido de documentación de una entidad METHOD, llame a la operación

documentationpart:update, proporcionando un nuevo mapa properties:

{
"op" : "replace",
"path" : "/properties",
"value" : "{\n\t\"tags\" : [ \"pets\" ], \n\t\"summary\" : \"List all pets.\"\n}"
} ]
}
DocumentationPart actualizada en la carga. Por ejemplo:
{
"_links": {
"curies": {
"templated": true
},
"self": {
},
},
199
}
},
"id": "o64jbj",
"location": {
"path": "/pets",
"method": "GET",
"name": null,
"statusCode": null,
"type": "METHOD"
},
"properties": "{\n\t\"tags\" : [ \"pets\" ], \n\t\"summary\" : \"List all pets.\"\n}"
}
Documentar una entidad QUERY_PARAMETER

Para agregar documentación para un parámetro de consulta de solicitud, añada un recurso
DocumentationPart de destino para el tipo QUERY_PARAMETER, con los campos válidos de path y name.

{
"location" : {
"type" : "QUERY_PARAMETER",
"path" : "/pets",
"method" : "GET",
"name" : "page"
},
"properties": "{\n\t\"description\" : \"Page number of results to return.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/h9ht5w"
},
},
}
},
"id": "h9ht5w",
"location": {
"path": "/pets",
200
"method": "GET",
"name": "page",
"statusCode": null,
"type": "QUERY_PARAMETER"
},
"properties": "{\n\t\"description\" : \"Page number of results to return.\"\n}"
}
El mapa properties de la pieza de documentación de una entidad QUERY_PARAMETER lo pueden heredar

alguna de sus entidades QUERY_PARAMETER secundarias. Por ejemplo, si añade un recurso treats detrás
de /pets/{petId}, habilita el método GET en /pets/{petId}/treats y expone el parámetro de consulta
page, este parámetro de consulta secundario hereda el mapa properties de DocumentationPart desde
el parámetro de consulta de igual nombre del método GET /pets, a menos que añada explícitamente un
recurso DocumentationPart al parámetro de consulta page del método GET /pets/{petId}/treats.
Documentar una entidad PATH_PARAMETER

Para agregar documentación para un parámetro de ruta, añada un recurso DocumentationPart a la entidad
PATH_PARAMETER.

{
"location" : {
"type" : "PATH_PARAMETER",
"path" : "/pets/{petId}",
"method" : "*",
"name" : "petId"
},
"properties": "{\n\t\"description\" : \"The id of the pet to retrieve.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/ckpgog"
},
},
}
},
"id": "ckpgog",
"location": {
201
"path": "/pets/{petId}",
"method": "*",
"name": "petId",
"statusCode": null,
"type": "PATH_PARAMETER"
},
"properties": "{\n \"description\" : \"The id of the pet to retrieve\"\n}"
}
Documentar una entidad REQUEST_BODY

Para agregar documentación para un cuerpo de solicitud, añada un recurso DocumentationPart al cuerpo
de solicitud.

{
"location" : {
"type" : "REQUEST_BODY",
"path" : "/pets",
"method" : "POST"
},
"properties": "{\n\t\"description\" : \"A Pet object to be added to PetStore.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/kgmfr1"
},
},
}
},
"id": "kgmfr1",
"location": {
"path": "/pets",
"method": "POST",
"name": null,
"statusCode": null,
"type": "REQUEST_BODY"
},
"properties": "{\n\t\"description\" : \"A Pet object to be added to PetStore.\"\n}"
}
202
Documentar una entidad REQUEST_HEADER

Para añadir documentación para un encabezado de solicitud, añada un recurso DocumentationPart al
encabezado de solicitud.

{
"location" : {
"type" : "REQUEST_HEADER",
"path" : "/pets",
"method" : "GET",
"name" : "x-my-token"
},
"properties": "{\n\t\"description\" : \"A custom token used to authorization the method
invocation.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/h0m3uf"
},
},
}
},
"id": "h0m3uf",
"location": {
"path": "/pets",
"method": "GET",
"name": "x-my-token",
"statusCode": null,
"type": "REQUEST_HEADER"
},
"properties": "{\n\t\"description\" : \"A custom token used to authorization the method
invocation.\"\n}"
}
Documentar una entidad RESPONSE

Para agregar documentación para una respuesta de un código de estado, añada un recurso
DocumentationPart de destino al recurso MethodResponse correspondiente.
203

{
"location": {
"path": "/",
"method": "*",
"name": null,
"type": "RESPONSE"
},
"properties": "{\n \"description\" : \"Successful operation.\"\n}"
}
{
"_links": {
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/lattew"
},
},
}
},
"id": "lattew",
"location": {
"path": "/",
"method": "*",
"name": null,
"type": "RESPONSE"
},
"properties": "{\n \"description\" : \"Successful operation.\"\n}"
}
Documentar una entidad RESPONSE_HEADER

Para agregar documentación para un encabezado de respuesta, añada un recurso DocumentationPart al
encabezado de respuesta.

"location": {
"path": "/",
"method": "GET",
"name": "Content-Type",
204
"type": "RESPONSE_HEADER"
},
"properties": "{\n \"description\" : \"Media type of request\"\n}"
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/fev7j7"
},
},
}
},
"id": "fev7j7",
"location": {
"path": "/",
"method": "GET",
"type": "RESPONSE_HEADER"
},
"properties": "{\n \"description\" : \"Media type of request\"\n}"
}
La documentación de este encabezado de respuesta Content-Type es la documentación predeterminada

para los encabezados Content-Type de todas las respuestas de la API.
Documentar una entidad AUTHORIZER

Para agregar documentación para un autorizador de API, añada un recurso DocumentationPart de destino
al autorizador especificado.

{
"location" : {
"type" : "AUTHORIZER",
"name" : "myAuthorizer"
},
"properties": "{\n\t\"description\" : \"Authorizes invocations of configured methods.
\"\n}"
}
205
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/pw3qw3"
},
},
}
},
"id": "pw3qw3",
"location": {
"path": null,
"method": null,
"name": "myAuthorizer",
"statusCode": null,
"type": "AUTHORIZER"
},
"properties": "{\n\t\"description\" : \"Authorizes invocations of configured methods.
\"\n}"
}
Note
La instancia de DocumentationPart de una entidad AUTHORIZER no la pueden heredar sus recursos

secundarios.
Documentar una entidad MODEL

Documentar una entidad MODEL implica crear y administrar instancias de DocumentPart para el modelo y
para todas las properties del modelo. Por ejemplo, el modelo Error integrado con cada API de manera
predeterminada tiene la siguiente definición de esquema
{
"$schema" : "http://json-schema.org/draft-04/schema#",
"title" : "Error Schema",
"type" : "object",
"properties" : {
"message" : { "type" : "string" }
}
}
y requiere dos instancias de DocumentationPart, una para Model y otra para su propiedad message:
{
"location": {
"type": "MODEL",
"name": "Error"
},
"properties": {
206
"title": "Error Schema",

"description": "A description of the Error model"
}
}
{
"location": {
"type": "MODEL",
"name": "Error.message"
},
"properties": {
"description": "An error message."
}
}
Cuando se exporta la API, las propiedades de DocumentationPart invalidarán los valores del esquema
original.
Para agregar documentación para un modelo de API, añada un recurso DocumentationPart de destino al
modelo especificado.

{
"location" : {
"type" : "MODEL",
"name" : "Pet"
},
"properties": "{\n\t\"description\" : \"Data structure of a Pet object.\"\n}"
}
{
"_links": {
"curies": {
"templated": true
},
"self": {
"href": "/restapis/4wk1k4onj3/documentation/parts/lkn4uq"
},
},
}
},
"id": "lkn4uq",
"location": {
207
"path": null,
"method": null,
"name": "Pet",
"statusCode": null,
"type": "MODEL"
},
"properties": "{\n\t\"description\" : \"Data structure of a Pet object.\"\n}"
}
Repita el mismo paso para crear una instancia de DocumentationPart para cualquiera de las propiedades
del modelo.
Note
La instancia de DocumentationPart de una entidad MODEL no la pueden heredar sus recursos

secundarios.
Actualizar piezas de documentación

Para actualizar las piezas de documentación de cualquier tipo de entidad de API, envíe una solicitud
PATCH en una instancia de DocumentationPart de un identificador de pieza especificado para reemplazar
el mapa properties existente por uno nuevo.

{
"op" : "replace",
"path" : "RESOURCE_PATH",
"value" : "NEW_properties_VALUE_AS_JSON_STRING"
} ]
}
DocumentationPart actualizada en la carga.
Puede actualizar varias piezas de documentación en una sola solicitud PATCH.
Mostrar piezas de documentación

Para mostrar las piezas de documentación de cualquier entidad de API, envíe una solicitud GET en una
colección DocumentationParts.
GET /restapis/restapi_id/documentation/parts HTTP/1.1

La respuesta correcta devuelve un código de estado 200 OK con la carga que contiene las instancias
DocumentationPart disponibles en la carga.
208
Publicar la documentación de API

Para publicar la documentación de una API, cree, actualice u obtenga una snapshot de documentación
y después asóciela a una etapa de API. Cuando crea una snapshot de documentación, también puede
asociarla a una etapa de API al mismo tiempo.
Temas
• Crear una snapshot de documentación y asociarla a una etapa de API (p. 209)
• Crear una snapshot de documentación (p. 209)
• Actualizar una snapshot de documentación (p. 210)
• Obtener una snapshot de documentación (p. 210)
• Asociar un snapshot de documentación con una etapa de API (p. 210)
• Descargar una snapshot de documentación asociada a una etapa (p. 211)
Crear una snapshot de documentación y asociarla a una etapa

de API
Para crear una snapshot de piezas de documentación de una API y asociarla a una etapa de API al mismo
tiempo, envíe la siguiente solicitud POST:
POST /restapis/restapi_id/documentation/versions HTTP/1.1

{
"documentationVersion" : "1.0.0",
"stageName": "prod",
"description" : "My API Documentation v1.0.0"
}
Si es correcta, la operación devuelve una respuesta 200 OK que contiene la instancia

DocumentationVersion recién creada como la carga.
También puede crear una snapshot de documentación sin asociarla primero a una etapa de API y después
llamar a restapi:update para asociar la snapshot a una etapa de API especificada. También puede
actualizar o consultar una snapshot de documentación existente y después actualizar su asociación de
etapa. Le mostramos los pasos en las próximas cuatro secciones.
Crear una snapshot de documentación

Para crear una snapshot de piezas de documentación de una API, cree un nuevo recurso
DocumentationVersion y añádalo a la colección DocumentationVersions de la API:
POST /restapis/restapi_id/documentation/versions HTTP/1.1

209
{
"documentationVersion" : "1.0.0",
"description" : "My API Documentation v1.0.0"
}

DocumentationVersion recién creada como la carga.
Actualizar una snapshot de documentación

Solo puede actualizar una snapshot de documentación modificando la propiedad description del recurso
DocumentationVersion correspondiente. El siguiente ejemplo muestra cómo actualizar la descripción de la
snapshot de documentación identificada por su identificador de versión, version (p. ej., 1.0.0).
PATCH /restapis/restapi_id/documentation/versions/version HTTP/1.1

{
"patchOperations": [{
"op": "replace",
"path": "/description",
"value": "My API for testing purposes."
}]
}

DocumentationVersion actualizada como la carga.
Obtener una snapshot de documentación

Para obtener una snapshot de documentación, envíe una solicitud GET al recurso DocumentationVersion
especificado. El siguiente ejemplo muestra cómo obtener una snapshot de documentación de un
identificador de versión determinado, 1.0.0.
GET /restapis/<restapi_id>/documentation/versions/1.0.0 HTTP/1.1

Asociar un snapshot de documentación con una etapa de API

Para publicar la documentación de la API, asocie una snapshot de documentación a una etapa de API.
Debe haber creado una etapa de API antes de asociar la versión de documentación a la etapa.
Para asociar una snapshot de documentación a una etapa de API, mediante la API REST de API Gateway,
llame a la operación stage:update para establecer la versión de documentación que desee en la propiedad
stage.documentationVersion:
PATCH /restapis/RESTAPI_ID/stages/STAGE_NAME
210
{
"patchOperations": [{
"op": "replace",
"path": "/documentationVersion",
"value": "VERSION_IDENTIFIER"
}]
}
El procedimiento siguiente describe cómo publicar una versión de la documentación.
Para publicar una versión de la documentación mediante la consola de API Gateway
1. Elija Documentation para la API desde el panel de navegación principal de la consola de API Gateway.
2. Elija Publish Documentation en el panel Documentation.
3. Configure la publicación:
a. Elija un nombre disponible para Stage.

b. Escriba un identificador de versión (por ejemplo, 1.0.0) en Version.
c. Si lo desea, proporcione una descripción sobre la publicación en Description.
4. Elija Publish.
Ahora puede empezar a descargar la documentación publicada exportando la documentación a un archivo

de Swagger externo.
Descargar una snapshot de documentación asociada a una etapa

Una vez asociada una versión de la pieza de documentación a una etapa, puede exportar las piezas de
documentación junto con las definiciones de la entidad de API a un archivo externo mediante la consola de
API Gateway, la API REST de API Gateway uno de sus SDK o la AWS CLI de API Gateway. El proceso es
el mismo que para exportar la API. El formato del archivo exportado puede ser JSON o YAML.
Mediante la API REST de API Gateway, también puede establecer explícitamente el parámetro de
consulta extension=documentation,integrations,authorizers para incluir las piezas de documentación
de la API, las integraciones de la API y los autorizadores en una exportación de la API. De forma
predeterminada, se incluyen las piezas de documentación, pero se excluyen las integraciones y los
autorizadores cuando se exporta una API. La salida predeterminada de la exportación de API es adecuada
para la distribución de la documentación.
Para exportar la documentación de la API en un archivo JSON de Swagger externo mediante la API REST
de API Gateway, envíe la siguiente solicitud GET:
GET /restapis/restapi_id/stages/stage_name/exports/swagger?extensions=documentation
HTTP/1.1
Aquí, el objeto x-amazon-apigateway-documentation contiene las piezas de documentación y las

definiciones de la entidad de API contienen las propiedades de documentación admitidas por Swagger. La
211
salida no incluye los detalles de la integración ni de los autorizadores personalizados. Para incluir ambos
detalles, establezca extensions=integrations,authorizers,documentation. Para incluir los detalles de
las integraciones pero no de los autorizadores, establezca extensions=integrations,documentation.
Debe definir el encabezado Accept:application/json en la solicitud para mostrar el resultado en

un archivo JSON. Para producir la salida en formato YAML, cambie el encabezado de la solicitud a
Accept:application/yaml.
A modo de ejemplo, vamos a examinar una API que expone un método GET sencillo en el recurso raíz
(/). Esta API tiene cuatro entidades de API definidas en un archivo de definición de Swagger, una para
cada uno de los tipos API, MODEL, METHOD y RESPONSE. Se ha añadido una pieza de documentación a cada
una de las entidades API, METHOD y RESPONSE. Al llamar al comando de exportación de la documentación
anterior, obtenemos el siguiente resultado, con las piezas de documentación mostradas dentro del objeto
x-amazon-apigateway-documentation como una extensión a un archivo de Swagger estándar.
{
"swagger" : "2.0",
"info" : {
"description" : "API info description",
"version" : "2016-11-22T22:39:14Z",
"title" : "doc",
"x-bar" : "API info x-bar"
},
"host" : "rznaap68yi.execute-api.ap-southeast-1.amazonaws.com",
"basePath" : "/test",
"schemes" : [ "https" ],
"paths" : {
"/" : {
"get" : {
"description" : "Method description.",
"produces" : [ "application/json" ],
"responses" : {
"200" : {
"description" : "200 response",
"schema" : {
"$ref" : "#/definitions/Empty"
}
}
},
"x-example" : "x- Method example"
},
"x-bar" : "resource x-bar"
}
},
"definitions" : {
"Empty" : {
"type" : "object",
"title" : "Empty Schema"
}
},
"x-amazon-apigateway-documentation" : {
"version" : "1.0.0",
"createdDate" : "2016-11-22T22:41:40Z",
"documentationParts" : [ {
"location" : {
"type" : "API"
},
"properties" : {
"description" : "API description",
"foo" : "API foo",
"x-bar" : "API x-bar",
"info" : {
"description" : "API info description",
"version" : "API info version",
212
"foo" : "API info foo",

"x-bar" : "API info x-bar"
}
}
}, {
"location" : {
"type" : "METHOD",
"method" : "GET"
},
"properties" : {
"description" : "Method description.",
"x-example" : "x- Method example",
"foo" : "Method foo",
"info" : {
"version" : "method info version",
"description" : "method info description",
"foo" : "method info foo"
}
}
}, {
"location" : {
"type" : "RESOURCE"
},
"properties" : {
"description" : "resource description",
"foo" : "resource foo",
"x-bar" : "resource x-bar",
"info" : {
"description" : "resource info description",
"version" : "resource info version",
"foo" : "resource info foo",
"x-bar" : "resource info x-bar"
}
}
} ]
},
"x-bar" : "API x-bar"
}
Para un atributo compatible con Swagger definido en el mapa properties de una pieza de documentación,
API Gateway inserta el atributo en la definición de la entidad de API asociada. Un atributo de x-something
es una extensión de Swagger estándar. Esta extensión se propaga a la definición de la entidad de API.
Véase, por ejemplo, el atributo x-example del método GET. Un atributo como foo no forma parte de la
especificación de Swagger y no se incluye en sus definiciones de entidad de API asociadas.
Si una herramienta de representación de la documentación (por ejemplo, la interfaz de usuario de

Swagger) analiza las definiciones de la entidad de API para extraer los atributos de documentación,
ninguno de los atributos properties que no sean compatibles con Swagger de una instancia de
DocumentationPart estará disponible para la herramienta. Sin embargo, si una herramienta de
representación de la documentación analiza el objeto x-amazon-apigateway-documentation para
obtener contenido, o si la herramienta llama a restapi:documentation-parts y documenationpart:by-id para
recuperar piezas de documentación de API Gateway, la herramienta podrá mostrar todos los atributos de
la documentación.
Para exportar la documentación con definiciones de entidad de API que contengan detalles de la
integración en un archivo JSON de Swagger, envíe la siguiente solicitud GET:
GET /restapis/restapi_id/stages/stage_name/exports/swagger?
extensions=integrations,documentation HTTP/1.1
213
Importar la documentación de API

Para exportar la documentación con definiciones de entidad de API que contengan detalles de las
integraciones y autorizadores a un archivo YAML de Swagger, envíe la siguiente solicitud GET:
GET /restapis/restapi_id/stages/stage_name/exports/swagger?
extensions=integrations,authorizers,documentation HTTP/1.1
Accept: application/yaml
Para utilizar la consola de API Gateway para exportar y descargar la documentación publicada de una API,
siga las instrucciones de Exportar la API mediante la consola de API Gateway (p. 318).

Al igual que con la importación de definiciones de entidad de API, puede importar piezas de
documentación de un archivo de Swagger externo en una API en API Gateway. Las piezas de
documentación que se van a importar se especifican en la extensión Objeto x-amazon-apigateway-
documentation (p. 378) en un archivo de definición de Swagger 2.0 válido. La importación de la
documentación no modifica las definiciones de entidad de API existentes.
Tiene la opción de combinar las piezas de documentación recién especificadas en piezas de

documentación existentes en API Gateway o de sobrescribir las piezas de documentación existentes.
En el modo MERGE, una nueva pieza de documentación definida en el archivo de Swagger se añade a
la colección DocumentationParts de la API. Si ya existe un elemento DocumentationPart importado,
el atributo importado reemplaza al existente si los dos son diferentes. Todos los demás atributos de
documentación existentes permanecen tal como están. En el modo OVERWRITE, toda la colección
DocumentationParts se reemplaza de acuerdo con el archivo de definición de Swagger importado.
Importar piezas de documentación mediante la API REST de API

Gateway
Para importar la documentación de API mediante la API REST de API Gateway, llame a la operación
documentationpart:import. El siguiente ejemplo muestra cómo sobrescribir piezas de documentación
existentes de una API con un único método GET / , que devuelve una respuesta 200 OK si se ejecuta
correctamente.
PUT /restapis/<restapi_id>/documentation/parts&mode=overwrite&failonwarnings=true
{
"swagger": "2.0",
"info": {
"description": "description",
"version": "1",
214
"title": "doc"
},
"host": "",
"basePath": "/",
"schemes": [
"https"
],
"paths": {
"/": {
"get": {
"description": "Method description.",
"produces": [
"application/json"
],
"responses": {
"200": {
"schema": {
}
}
}
}
}
},
"definitions": {
"Empty": {
"type": "object",
}
},
"x-amazon-apigateway-documentation": {
"version": "1.0.3",
"documentationParts": [
{
"location": {
"type": "API"
},
"properties": {
"description": "API description",
"info": {
"description": "API info description 4",
"version": "API info version 3"
}
}
},
{
"location": {
"type": "METHOD",
"method": "GET"
},
"properties": {
"description": "Method description."
}
},
{
"location": {
"type": "MODEL",
"name": "Empty"
},
"properties": {
}
},
{
"location": {
215
Controlar el acceso a la documentación de la API
"type": "RESPONSE",
"method": "GET",
"statusCode": "200"
},
"properties": {
}
}
]
}
}
Cuando se ejecuta correctamente, esta solicitud devuelve una respuesta 200 OK que contiene el elemento
DocumentationPartId importado en la carga.
{
"ids": [
"kg3mth",
"796rtf",
"zhek4p",
"5ukm9s"
]
}
Además, también puede llamar a restapi:import o restapi:put, proporcionando las piezas de documentación
en el objeto x-amazon-apigateway-documentation como parte del archivo de Swagger de entrada
de la definición de la API. Para excluir piezas de documentación de la importación de API, establezca
ignore=documentation en los parámetros de consulta de la solicitud.
Importar piezas de documentación mediante la consola de API

Gateway
Las siguientes instrucciones describen cómo importar piezas de documentación.
Para utilizar la consola para importar piezas de documentación de una API desde un archivo
externo
1. Elija Documentation para la API desde el panel de navegación principal de la consola.

2. Elija Import Documentation en el panel Documentation.
3. Elija Select Swagger File para cargar un archivo de una unidad o para copiar y pegar el contenido del
archivo en la vista de archivo. Para ver un ejemplo, consulte la carga de la solicitud de ejemplo de
Importar piezas de documentación mediante la API REST de API Gateway (p. 214).
4. Si lo desea, elija Fail on warnings o Ignore warnings, y elija Merge u Overwrite desde Import mode.
5. Elija Import.
Controlar el acceso a la documentación de la API

Si tiene un equipo de documentación dedicado a escribir y editar la documentación de la API, puede
configurar permisos de acceso distintos para los desarrolladores (para el desarrollo de la API) y para los
redactores o editores (para el desarrollo de contenido). Esto resulta especialmente útil para un proveedor
externo encargado de crear la documentación por usted.
Para otorgar acceso al equipo de documentación para crear, actualizar y publicar la documentación de
la API, puede asignar al equipo de documentación un rol de IAM con la siguiente política de IAM, donde
account_id es el ID de cuenta de AWS del equipo de documentación.
216
Importar una API
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "StmtDocPartsAddEditViewDelete",
"Effect": "Allow",
"Action": [
"apigateway:GET",
"apigateway:PUT",
"apigateway:POST",
"apigateway:PATCH",
"apigateway:DELETE"
],
"Resource": [
"arn:aws:apigateway::account_id:/restapis/*/documentation/*"
]
}
]
}
Para obtener información sobre la configuración de permisos para obtener acceso a recursos de API
Gateway, consulte Controlar quién puede crear y administrar una API de API Gateway con políticas de
IAM (p. 223).
Importar una API en API Gateway

Puede utilizar la característica Import API de API Gateway para importar una API de un archivo de
definición externo en API Gateway. En la actualidad, la característica Import API admite archivos de
definición de Swagger v2.0.
Con Import API, puede crear una nueva API enviando una solicitud POST que incluya una definición
como la carga, o bien puede actualizar una API existente usando una solicitud PUT que contenga una
definición en la carga. Puede actualizar una API sobrescribiéndola con una nueva definición o combinar
una definición con una API existente. Las opciones de la URL de solicitud se especifican mediante un
parámetro de consulta mode.
Note
Para las definiciones de API de RAML, puede seguir usando API Gateway Importer.
Además de realizar llamadas explícitas a la API REST, tal y como se describe a continuación, también
puede utilizar la característica Import API en la consola de API Gateway. La opción está disponible
como un elemento en el menú desplegable Actions. Para ver un ejemplo de cómo usar la característica
Import API desde la consola de API Gateway, consulte Crear una API de API Gateway a partir de un
ejemplo (p. 9).
Usar Import API para crear una nueva API

Para utilizar la característica Import API para crear una nueva API, publique (POST) el archivo de
definición de la API en https://apigateway.<region>.amazonaws.com/restapis?mode=import. Esta
solicitud da como resultado una nueva RestApi, junto con recursos, modelos y otros elementos definidos
en el archivo de definición.
El siguiente fragmento de código muestra un ejemplo de la solicitud POST con la carga de una definición
de Swagger con formato JSON:
217
Usar Import API para actualizar una API existente
POST /restapis?mode=import
Host:apigateway.<region>.amazonaws.com
Content-Length: ...
Swagger API definition in JSON (p. 409)
Usar Import API para actualizar una API existente

Puede utilizar la característica Import API para actualizar una API existente cuando haya aspectos de la
API que desee conservar, como las etapas y las variables de etapa o las referencias a la API de las claves
de API.
Una actualización de API puede producirse de dos modos: combinándola o sobrescribiéndola. Combinar
una API es útil cuando ha descompuesto sus definiciones de API externas en varias partes más pequeñas
y solo desea aplicar los cambios de una de esas partes a la vez. Esto podría ocurrir, por ejemplo, si
varios equipos son responsables de diferentes partes de una API y han realizado cambios disponibles en
diferentes partes. En este modo, los elementos de la API existente que no están específicamente definidos
en la definición importada se dejan tal como están.
Sobrescribir una API es útil cuando una definición de API externa contiene la definición completa de una
API. En este modo, los elementos de una API existente que no están específicamente definidos en la
definición importada se eliminan.
Para combinar una API, envíe una solicitud PUT a https://apigateway.<region>.amazonaws.com/

restapis/<restapi_id>?mode=merge. El valor del parámetro de ruta restapi_id especifica la API con la
que debe combinarse la definición de API proporcionada.
El siguiente fragmento de código muestra un ejemplo de la solicitud PUT para combinar una definición de
API de Swagger en JSON, como la carga, con la API ya especificada en API Gateway.
PUT /restapis/<restapi_id>?mode=merge
Content-Length: ...
A Swagger API definition in JSON (p. 409)
La operación de actualización por combinación toma dos definiciones de API completas y las combina.
Para un cambio pequeño e incremental, puede usar la operación resource update.
Para sobrescribir una API, envíe una solicitud PUT a https://apigateway.<region>.amazonaws.com/

restapis/<restapi_id>?mode=overwrite. El parámetro de ruta restapi_id especifica la API que se
sobrescribirá con las definiciones de API proporcionadas.
El siguiente fragmento de código muestra un ejemplo de una solicitud de sobrescritura con la carga de una
definición de Swagger con formato JSON:
PUT /restapis/<restapi_id>?mode=overwrite
218
basePath de Swagger
Content-Length: ...
A Swagger API definition in JSON (p. 409)
Cuando no se especifica el parámetro de consulta mode, se asume que se trata de una combinación.
Note
Las operaciones PUT son idempotentes, pero no atómicas. Eso significa que si se produce un
error del sistema durante el procesamiento, la API puede acabar en mal estado. Sin embargo, si
se repite la operación, la API acabará en el mismo estado final que tendría si la primera operación
se hubiera realizado con éxito.
basePath de Swagger
En Swagger, puede utilizar la propiedad basePath para proporcionar una o varias partes de la ruta
que preceden a cada una de las rutas definidas en la propiedad de rutas. Como API Gateway tiene
varias maneras de expresar la ruta de un recurso, la característica Import API ofrece tres opciones para
interpretar la propiedad basePath durante una importación:
ignorar
Si el archivo de Swagger tiene un valor basePath de "/a/b/c" y la propiedad paths contiene "/e" y "/f",
la siguiente solicitud POST o PUT:
POST /restapis?mode=import&basepath=ignore
PUT /restapis/api_id?basepath=ignore
producirá los siguientes recursos en la API:
• /
• /e
• /f
El efecto consiste en tratar basePath como si no estuviera presente, y todos los recursos de la API
declarados se sirven en relación con el host. Esto puede utilizarse, por ejemplo, cuando disponga de un
nombre de dominio personalizado con una asignación de API que no incluya un valor BasePath ni Stage
que haga referencia a la etapa de producción.
Note
API Gateway creará automáticamente un recurso raíz, aunque no se haya declarado

explícitamente en el archivo de definición.
Cuando no se especifica, basePath toma ignore como valor predeterminado.
anexar
219
Errores durante la importación
POST /restapis?mode=import&basepath=prepend
PUT /restapis/api_id?basepath=prepend
• /
• /a
• /a/b
• /a/b/c
• /a/b/c/e
• /a/b/c/f
El efecto consiste en tratar basePath como si especificara recursos adicionales (sin métodos) y añadiera
estos recursos al conjunto de recursos declarados. Esto puede utilizarse, por ejemplo, cuando diferentes
equipos sean responsables de diferentes partes de una API y basePath pueda hacer referencia a la
ubicación de ruta de la parte de la API de cada equipo.
Note
API Gateway creará automáticamente los recursos intermedios, aunque no se hayan declarado
explícitamente en la definición.
dividir
POST /restapis?mode=import&basepath=split
PUT /restapis/api_id?basepath=split
• /
• /b
• /b/c
• /b/c/e
• /b/c/f
El efecto consiste en tratar la parte de la ruta superior, "/a", como el principio de la ruta de cada recurso y
crear recursos adicionales (sin método) dentro de la propia API. Esto podría usarse, por ejemplo, cuando
"a" es un nombre de etapa que desee exponer como parte de la API.
Errores durante la importación

Durante la importación, se pueden generar errores por problemas graves, como un documento de
Swagger no válido. Los errores se devuelven como excepciones (por ejemplo, BadRequestException) en
una respuesta incorrecta. Cuando se produce un error, la nueva definición de la API se descarta y no se
realiza ningún cambio en la API existente.
220
Advertencias durante la importación
Advertencias durante la importación

Durante la importación, se pueden generar advertencias por problemas menores, como la falta de una
referencia del modelo. Si se produce una advertencia, la operación continuará si la expresión de consulta
failonwarnings=false se añade a la URL de la solicitud. De lo contrario, las actualizaciones se revertirán.
De forma predeterminada, failonwarnings está establecido en false. En estos casos, las advertencias
se devuelven como un campo en el recurso de RestApi resultante. De lo contrario, las advertencias se
devuelven como un mensaje en la excepción.
Controlar el acceso en API Gateway

API Gateway admite varios mecanismos de control de acceso, incluida la medición o el seguimiento del
uso de las API por los clientes mediante claves de API. Los roles y políticas de AWS IAM estándar ofrecen
controles de acceso flexibles y robustos que se pueden aplicar a un conjunto completo de API o a métodos
individuales. Los autorizadores personalizados y grupos de usuarios de Amazon Cognito proporcionan
soluciones de autenticación y autorización personalizables.
Temas
• Controlar el acceso a API Gateway con permisos de IAM (p. 221)
• Habilitar CORS para un recurso de API Gateway (p. 235)
• Usar autorizadores personalizados de API Gateway (p. 239)
• Usar conjuntos de usuarios de Amazon Cognito (p. 252)
• Uso de certificados SSL del lado cliente para la autenticación por el backend (p. 256)
• Entidades de certificación compatibles con API Gateway para las integraciones HTTP y Proxy
HTTP (p. 260)
• Crear usar planes de uso de API Gateway (p. 280)
Controlar el acceso a API Gateway con permisos de

IAM
El acceso a Amazon API Gateway se controla con permisos de IAM para los dos procesos de
componentes de API Gateway siguientes:
• Para crear, implementar y administrar una API en API Gateway, debe conceder al desarrollador de la
API permisos para realizar las acciones necesarias admitidas por el componente de administración de la
API de API Gateway.
• Para llamar a una API implementada o para actualizar el almacenamiento en caché de la API, debe
conceder al intermediario de la API permisos para realizar las acciones de IAM necesarias admitidas por
el componente de ejecución de la API de API Gateway.
El control de acceso para los dos procesos implica diferentes modelos de permisos, que se explican a
continuación.
Modelo de permisos de API Gateway para crear y administrar

una API
Para permitir a un desarrollador de API crear y administrar una API en API Gateway debe crear políticas
de permisos de IAM que permitan a un desarrollador de la API especificado crear, actualizar, implementar,
ver o eliminar las entidades de API necesarias. Asocia la política de permisos a un usuario de IAM que
221
Usar permisos de IAM
representa al desarrollador, a un grupo de IAM, que contiene al usuario o a un rol de IAM asumido por el
usuario.
En este documento de política de IAM, el elemento Resource de IAM, contiene una lista de entidades
de API de API Gateway, incluidos recursos de API Gateway y relaciones de enlace de API Gateway. El
elemento Action de IAM contiene las acciones de administración de API de API Gateway necesarias.
Estas acciones se declaran con el formato apigateway:HTTP_VERB, donde apigateway designa el
componente de administración de la API subyacente de API Gateway y HTTP_VERB representa los verbos
HTTP admitidos por API Gateway.
Para obtener más información sobre cómo usar este modelo de permisos, consulte Controlar el acceso
para administrar una API (p. 223).
Modelo de permisos de API Gateway para invocar una API

Para permitir a un intermediario de la API invocar la API o actualizar su caché, debe crear políticas de
IAM que permitan a un intermediario de la API especificado invocar el método de API para el que se
ha habilitado la autenticación de usuarios de IAM. El desarrollador de la API establece la propiedad
authorizationType del método en AWS_IAM para exigir que el intermediario envíe las clave de acceso del
usuario de IAM que se va a autenticar. A continuación, asocia la política de permisos a un usuario de IAM
que representa al intermediario de la API, a un grupo de IAM, que contiene al usuario o a un rol de IAM
asumido por el usuario.
En esta instrucción de política de permisos de IAM, el elemento Resource de IAM contiene una lista de
métodos de la API implementada identificados por verbos HTTP y rutas de recursos de API Gateway. El
elemento Action de IAM contiene las acciones de ejecución de API de API Gateway necesarias. Estas
acciones incluyen execute-api:Invoke o execute-api:InvalidateCache, donde execute-api designa el
componente de ejecución de la API subyacente de API Gateway.
Para obtener más información sobre cómo usar este modelo de permisos, consulte Controlar el acceso
para invocar una API (p. 226).
Cuando una API está integrada con un servicio de AWS (por ejemplo, AWS Lambda) en el backend,
API Gateway también debe tener permisos para obtener acceso a los recursos de AWS integrados
(por ejemplo, invocar una función Lambda) en nombre del intermediario de la API. Para conceder estos
permisos, cree un rol de IAM del tipo Amazon API Gateway. Este rol contiene la siguiente política de
confianza de IAM que declara API Gateway como una entidad de confianza capaz de asumir el rol:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
También debe asociar a este rol las políticas de permisos de IAM para llamar a los servicios de AWS
integrados. Por ejemplo, si el backend es Lambda, la política de permisos de IAM debe incluir la siguiente
instrucción de política de permisos:
{
"Version": "2012-10-17",
"Statement": [
{
222
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "*"
}
]
}
Tenga en cuenta que Lambda admite la política de acceso basada en recursos, que combina políticas de
confianza y de permisos. Cuando integre una API con una función Lambda mediante la consola de API
Gateway, no se le pedirá que establezca este rol de IAM explícitamente, porque la consola establece los
permisos basados en recursos en la función Lambda por usted, con su consentimiento.
Note
Para establecer el control del acceso a un servicio de AWS, puede utilizar el modelo de permisos
basado en el intermediario, donde una política de permisos se asocia directamente al usuario o
grupo de IAM del intermediario, o el modelo de permisos basado en rol, donde una política de
permisos se asocia a un rol de IAM que API Gateway puede asumir. Los permisos de políticas
pueden ser diferentes en los dos modelos. Por ejemplo, la política basada en el intermediario
bloquea el acceso, mientras que la política basada en roles lo permite. Puede aprovechar esto
para exigir que un usuario de IAM tenga acceso a un servicio de AWS únicamente a través de la
API de API Gateway.
Controlar el acceso para administrar una API

En esta sección, aprenderá a crear instrucciones de política de IAM para controlar quién puede o no
puede crear, implementar y actualizar una API en API Gateway. También encontrará la referencia de
instrucciones de política, incluidos los formatos de los campos Action y Resource relacionados con el
servicio de administración de la API.
Controlar quién puede crear y administrar una API de API Gateway con políticas
de IAM
Para controlar quién puede o no puede crear, implementar y actualizar la API con el servicio de
administración de la API de API Gateway, cree un documento de política de IAM con los permisos
necesarios, tal y como se muestra en la siguiente plantilla de política:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Permission",
"Action": [
"apigateway:HTTP_VERB"
],
"Resource": [
"arn:aws:apigateway:region::resource1-path",
"arn:aws:apigateway:region::resource2-path",
...
]
}
]
}
Aquí Permission puede ser Allow o Deny para conceder o revocar, respectivamente, los derechos de
acceso estipulados por la instrucción de política. Para obtener más información, consulte AWS IAM
permissions.
HTTP_VERB pueden ser cualquiera de los verbos HTTP admitidos por API Gateway (p. 225). * se puede
utilizar para denotar cualquiera de los verbos HTTP.
223
Resource contiene una lista de los ARN de las entidades de API afectadas, incluidas RestApi, Resource,
Method, Integration, DocumentationPart, Model, Authorizer, UsagePlan, etc. Para obtener más
información, consulte Formato de Resource de permisos para administrar API en API Gateway (p. 225).
Combinando diferentes instrucciones de políticas, puede personalizar los permisos de acceso para
usuarios individuales, grupos o roles para tener acceso a las entidades de API seleccionadas y para
realizar acciones específicas en esas entidades. Por ejemplo, puede crear la siguiente política para
conceder al equipo de documentación los permisos para crear, publicar, actualizar y eliminar las piezas de
documentación de una API especificada, así como para ver las entidades de API.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:region::/restapis/api-id/*"
]
},
{
"Effect": "Allow",
"Action": [
"apigateway:POST",
"apigateway:PATCH",
"apigateway:DELETE"
],
"Resource": [
"arn:aws:apigateway:region::/restapis/api-id/documentation/*"
]
}
]
}
Para el equipo de desarrollo de la API responsable de todas las operaciones, puede crear la siguiente
política de IAM para conceder al equipo permisos de acceso más amplios.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:*::/*"
]
}
]
}
Referencia de instrucciones de políticas de IAM para administrar la API en API

Gateway
La siguiente información describe el formato de los elementos Action y Resource usados en una
instrucción de política de IAM para conceder o revocar los permisos para administrar entidades de API de
API Gateway.
224
Formato de Action de permisos para administrar API en API Gateway
La expresión Action de administración de API tiene el siguiente formato general:
apigateway:action
donde action es una de las siguientes acciones de API Gateway:
• *, que representa todas las acciones siguientes.

• GET, que se utiliza para obtener información acerca de los recursos.
• POST, que se utiliza principalmente para crear recursos secundarios.
• PUT, que se utiliza principalmente para actualizar los recursos (y, aunque no es recomendable, puede
utilizarse para crear recursos secundarios).
• DELETE, que se utiliza para eliminar recursos.
• PATCH, que se puede utilizar para actualizar los recursos.
• HEAD, que es igual que GET, pero no devuelve la representación de los recursos. HEAD se utiliza
principalmente en escenarios de pruebas.
• OPTIONS, que pueden usar los intermediarios para obtener la información sobre las opciones de
comunicación disponibles para el servicio de destino.
Algunos ejemplos de la expresión Action incluyen:
• apigateway:* para todas las acciones de API Gateway.

• apigateway:GET para solo la acción GET en API Gateway.
Formato de Resource de permisos para administrar API en API Gateway
La expresión Resource de administración de API tiene el siguiente formato general:
arn:aws:apigateway:region::resource-path-specifier
donde region es una región de AWS de destino (como us-east-1 o * para todas las regiones de AWS
admitidas) y resource-path-specifier es la ruta de acceso a los recursos de destino.
Algunos ejemplos de expresiones de recursos incluyen:
• arn:aws: apigateway:region::/restapis /* para todos los recursos, métodos, modelos y etapas de

la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/* para todos los recursos, métodos, modelos y
etapas de la API con el identificador api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/resources/resource-id/* para todos los recursos
y métodos del recurso con el identificador resource-id, que se encuentran en la API con el identificador
api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/resources/resource-id/methods/* para todos los
métodos del recurso con el identificador resource-id, que se encuentran en la API con el identificador
api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/resources/resource-id/methods/GET para
solamente el método GET del recurso con el identificador resource-id, que se encuentra en la API con
el identificador api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/models/* para todos los modelos de la API con el
identificador api-id en la región de AWS region.
225
• arn:aws: apigateway:region::/restapis/api-id/models/model-name para el modelo con el nombre

model-name, que se encuentra en la API con el identificador api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/stages/* para todas las etapas de la API con el
identificador api-id en la región de AWS region.
• arn:aws: apigateway:region::/restapis/api-id/stages/stage-name para solo la etapa con el
nombre stage-name en la API con el identificador api-id en la región de AWS region.
Controlar el acceso para invocar una API

En esta sección aprenderá a crear instrucciones de política de IAM para controlar quién puede o no puede
llamar a una API implementada en API Gateway. Aquí, encontrará también la referencia de instrucciones
de política, incluidos los formatos de los campos Action y Resource relacionados con el servicio de
ejecución de la API.
Controlar quién puede llamar a una API de API Gateway con políticas de IAM
Para controlar quién puede o no puede llamar a una API implementada con permisos de IAM, cree un
documento de política de IAM con los permisos necesarios. A continuación, se muestra una plantilla para
un documento de política como este.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Permission",
"Action": [
"execute-api:Execution-operation"
],
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
]
}
]
}
Aquí, Permission se sustituirá por Allow o Deny dependiendo de si desea conceder o revocar los permisos
incluidos. Execution-operation se sustituye por las operaciones compatibles con el servicio de ejecución
de la API. METHOD_HTTP_VERB es un verbo HTTP compatible con los recursos especificados. Resource-
path es el marcador de posición para la ruta URL de una instancia de Resource de la API implementada
que admite METHOD_HTTP-VERB. Para obtener más información, consulte Referencia de instrucciones de
políticas de IAM para ejecutar la API en API Gateway (p. 227).
Note
Para que las políticas de IAM sean eficaces, debe haber habilitado la autenticación de IAM en los
métodos de API configurando AWS_IAM para la propiedad authorizationType de los métodos. En
caso contrario, estos métodos de API serán accesibles públicamente.
Cuando la administración de identidad y acceso de AWS está habilitada en un recurso específico,
los usuarios de IAM de diferentes cuentas de AWS no pueden tener acceso a dicho recurso,
porque API Gateway no admite actualmente la autenticación entre cuentas.
Por ejemplo, para conceder a un usuario el permiso para ver una lista de mascotas expuesta por una
API especificada, pero denegar al usuario el permiso para añadir una mascota a la lista, podría crear la
siguiente instrucción de política:
{
"Version": "2012-10-17",
226
"Statement": [
{
"Effect": "Allow",
"Action": [
],
"Resource": [
"arn:aws:execute-api:us-east-1:account-id:api-id/*/GET/pets"
]
},
{
"Effect": "Deny",
"Action": [
],
"Resource": [
"arn:aws:execute-api:us-east-1:account-id:api-id/*/POST/pets"
]
}
]
}
Para el equipo de desarrolladores que prueba las API, puede crear la siguiente instrucción de política
para permitir a cualquier desarrollador del equipo llamar a cualquier método de cualquier API en cualquier
recurso en la etapa test.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke",
"execute-api:InvalidateCache"
],
"Resource": [
"arn:aws:execute-api:*:*:*/test/*"
]
}
]
}
Referencia de instrucciones de políticas de IAM para ejecutar la API en API

Gateway
La siguiente información describe el formato de Action y Resource de las instrucciones de política de IAM
de permisos de acceso para ejecutar una API.
Formato de Action de permisos para ejecutar la API en API Gateway
La expresión Action de ejecución de API tiene el siguiente formato general:
execute-api:action
donde action es una acción de ejecución de API disponible:
• *, que representa todas las acciones siguientes.

• Invoke, que se utiliza para invocar una API previa solicitud del cliente.
• InvalidateCache, que se utiliza para invalidar la caché de API previa solicitud del cliente.
227
Formato de Resource de permisos para ejecutar una API en API Gateway
La expresión Resource de ejecución de API tiene el siguiente formato general:
arn:aws:execute-api:region:account-id:api-id/stage-name/HTTP-VERB/resource-path-specifier
donde:
• region es la región de AWS (como us-east-1 o * para todas las regiones de AWS) que se corresponde
con la API implementada para el método.
• account-id es el ID de cuenta de 12 dígitos de AWS del propietario de la API REST.
• api-id es el identificador que API Gateway ha asignado a la API para el método. (* puede utilizarse
para todas las API, independientemente del identificador de la API).
• stage-name es el nombre de la etapa asociada con el método (* se puede utilizar para todas las etapas,
independientemente del nombre de la etapa).
• HTTP-VERB es el verbo HTTP del método. Puede ser uno de las siguientes: GET, POST, PUT, PATCH,
DELETE, HEAD, OPTIONS.
• resource-path-specifier es la ruta al método deseado. (* puede utilizarse para todas las rutas).
Algunos ejemplos de expresiones de recursos incluyen:
• arn:aws:execute-api:*:*:* para cualquier ruta de recurso en cualquier etapa, para cualquier API de
cualquier región de AWS. (Equivale a *).
• arn:aws:execute-api:us-east-1:*:* para cualquier ruta de recurso en cualquier etapa, para cualquier
API en la región de AWS us-east-1.
• arn:aws:execute-api:us-east-1:*:api-id/* para cualquier ruta de recurso, en cualquier etapa, para
la API con el identificador api-id en la región de AWS us-east-1.
• arn:aws:execute-api: us-east-1:*:api-id/test /* para la ruta de recurso en la etapa test, para la
API con el identificador api-id en la región de AWS us-east-1.
• arn:aws:execute-api: us-east-1:*:api-id/test /*/mydemoresource /* para cualquier recurso en la
ruta de mydemoresource, para cualquier método HTTP en la etapa test, para la API con el identificador
api-id en la región de AWS us-east-1.
• arn:aws:execute-api:us-east-1:*:api-id/test/GET/mydemoresource/*, para los métodos GET en
cualquier ruta de recurso de mydemoresource, en la etapa test, para la API con el identificador api-id
en la región de AWS us-east-1.
Ejemplos de política de IAM para administrar las API de API

Gateway
Los siguientes documentos de política de ejemplo muestran varios casos de uso para establecer permisos
de acceso para administrar recursos de API en API Gateway. Para ver el modelo de permisos y otra
información de referencia, consulte Controlar quién puede crear y administrar una API de API Gateway
con políticas de IAM (p. 223).
Temas
• Permisos sencillos de lectura (p. 229)
• Permisos de solo lectura en cualquier API (p. 229)
• Permisos de acceso completo a cualquier recurso de API Gateway (p. 230)
• Permisos de acceso completo para administrar las etapas de API (p. 231)
• Impedir a usuarios especificados eliminar recursos de la API (p. 231)
228
Permisos sencillos de lectura

La siguiente instrucción de política concede al usuario permiso para obtener información acerca de todos
los recursos, métodos, modelos y etapas de la API con el identificador a123456789 en la región de AWS
us-east-1:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/a123456789/*"
]
}
]
}
La siguiente instrucción de política de ejemplo concede al usuario de IAM permiso para mostrar
información para todos los recursos, métodos, modelos y etapas en cualquier región. El usuario también
tiene permiso para realizar todas las acciones de API Gateway disponibles para la API con el identificador
a123456789 en la región de AWS us-east-1:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:*::/restapis/*"
]
},
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/a123456789/*"
]
}
]
}
Permisos de solo lectura en cualquier API

El siguiente documento de política permitirá a las entidades asociadas (usuarios, grupos o roles) recuperar
cualquiera de las API de la cuenta de AWS del intermediario. Esto incluye todos los recursos secundarios
de una API, como el método, la integración, etc.
{
"Version": "2012-10-17",
"Statement": [
{
229
"Sid": "Stmt1467321237000",
"Effect": "Deny",
"Action": [
"apigateway:POST",
"apigateway:PUT",
"apigateway:PATCH",
"apigateway:DELETE"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/*"
]
},
{
"Sid": "Stmt1467321341000",
"Effect": "Deny",
"Action": [
"apigateway:GET",
"apigateway:HEAD",
"apigateway:OPTIONS"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/",
"arn:aws:apigateway:us-east-1::/account",
"arn:aws:apigateway:us-east-1::/clientcertificates",
"arn:aws:apigateway:us-east-1::/domainnames",
"arn:aws:apigateway:us-east-1::/apikeys"
]
},
{
"Sid": "Stmt1467321344000",
"Effect": "Allow",
"Action": [
"apigateway:GET",
"apigateway:HEAD",
"apigateway:OPTIONS"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/*"
]
}
]
}
La primera instrucción Deny prohíbe explícitamente las llamadas de POST, PUT, PATCH, DELETE en cualquier
recurso en API Gateway. De este modo, se garantiza que otros documentos de política, asociados también
al intermediario, no invaliden dichos permisos. La segunda instrucción Deny impide al intermediario
consultar el recurso raíz (/), la información de la cuenta (/account), los certificados del cliente (/
clientcertificates), los nombres de dominios personalizados (/domainnames) y las claves de API (/
apikeys). Juntas, las tres instrucciones garantizan que el intermediario solo pueda consultar los recursos
relacionados con la API. Esto puede resultar útil en las pruebas de la API cuando no desee que el
evaluador modifique el código.
Para restringir el acceso de solo lectura anterior a las API especificadas, sustituya la propiedad Resource
de la instrucción Allow por lo siguiente:
"Resource": ["arn:aws:apigateway:us-east-1::/restapis/restapi_id1/*",
"arn:aws:apigateway:us-east-1::/restapis/restapi_id2/*"]
Permisos de acceso completo a cualquier recurso de API Gateway

El siguiente documento de política de ejemplo concede acceso completo a cualquiera de los recursos de
API Gateway de la cuenta de AWS.
230
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1467321765000",
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"*"
]
}
]
}
En general, debe abstenerse de utilizar una política de acceso tan amplia y abierta. Puede ser necesaria
para que su equipo de desarrollo de la API pueda crear, implementar, actualizar y eliminar cualquier
recurso de API Gateway.
Permisos de acceso completo para administrar las etapas de API

El siguiente documento de política de ejemplo concede permisos de acceso completo a los recursos
relacionados con la etapa de cualquier API en la cuenta de AWS del intermediario.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/*/stages",
"arn:aws:apigateway:us-east-1::/restapis/*/stages/*"
]
}
]
}
El documento de política anterior concede permisos de acceso completo solo a la colección stages y a
cualquiera de los recursos stage incluidos, siempre que no se asocie ninguna otra política que conceda
más acceso al intermediario. De lo contrario, debe denegar explícitamente todos los accesos.
Con esta política, el intermediario debe conocer el identificador de la API REST de antemano, ya que el
usuario no puede llamar a GET /respais para consultar las API disponibles. Además, si no se especifica
arn:aws:apigateway:us-east-1::/restapis/*/stages en la lista Resource, el recurso Stages no estará
accesible. En este caso, el intermediario no podrá crear una etapa ni obtener las etapas existentes, aunque
puede consultar, actualizar o eliminar una etapa, siempre que conozca el nombre de la etapa.
Para conceder permisos para etapas de la API específicas, solo tiene que sustituir la propiedad restapis/
* de las especificaciones Resource por restapis/restapi_id, donde restapi_id es el identificador de la
API específica.
Impedir a usuarios especificados eliminar recursos de la API

El siguiente documento de política de ejemplo de IAM impide a un usuario especificado eliminar cualquier
recurso en API Gateway.
231
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1467331998000",
"Effect": "Allow",
"Action": [
"apigateway:GET",
"apigateway:HEAD",
"apigateway:OPTIONS",
"apigateway:PATCH",
"apigateway:POST",
"apigateway:PUT"
],
"Resource": [
]
},
{
"Sid": "Stmt1467332141000",
"Effect": "Allow",
"Action": [
"apigateway:DELETE"
],
"Condition": {
"StringNotLike": {
"aws:username": "johndoe"
}
},
"Resource": [
]
}
]
}
Esta política de IAM concede permiso de acceso completo para crear, implementar, actualizar y eliminar
API a los usuarios, grupos o roles asociados, excepto al usuario especificado (johndoe), que no puede
eliminar ningún recurso de la API. Se asume que ningún otro documento de política que conceda permisos
Allow en la raíz, las claves de API, los certificados del cliente o los nombres de dominio personalizados se
ha asociado al intermediario.
Para impedir que el usuario especificado elimine recursos de API Gateway específicos, por ejemplo, una
API concreta o los recursos de una API, sustituya la especificación Resource anterior por esta:
"Resource": ["arn:aws:apigateway:us-east-1::/restapis/restapi_id_1",
"arn:aws:apigateway:us-east-1::/restapis/restapi_id_2/resources"]
Ejemplos de política de IAM para permisos de ejecución de la

API
Para ver el modelo de permisos y otra información de referencia, consulte Controlar el acceso para
invocar una API (p. 226).
La siguiente instrucción de política concede al usuario permiso para llamar a cualquier método POST en
la ruta mydemoresource, en la etapa test, para la API con el identificador de API a123456789, suponiendo
que la API correspondiente se ha implementado en la región de AWS us-east-1:
232
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
"Resource": [
"arn:aws:execute-api:us-east-1:*:a123456789/test/POST/mydemoresource/*"
]
}
]
}
La siguiente instrucción de política de ejemplo concede al usuario permiso para llamar a cualquier método
en la ruta del recurso petstorewalkthrough/pets, en cualquier etapa, para la API con el identificador
a123456789, en cualquier región de AWS en la que se haya implementado la API correspondiente:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
"Resource": [
"arn:aws:execute-api:*:*:a123456789/*/*/petstorewalkthrough/pets"
]
}
]
}
Crear y asociar una política a un usuario de IAM

Para que un usuario pueda llamar al servicio de administración de la API o al servicio de ejecución de la
API, debe crear una política de IAM para un usuario de IAM, que controle el acceso a las entidades de API
Gateway y después asociar la política al usuario de IAM. Los siguientes pasos describen cómo crear la
política de IAM.
Para crear su propia política de IAM
1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en https://

console.aws.amazon.com/iam/.
2. Elija Policies y después, Create Policy. Si aparece el botón Get Started, elíjalo y, a continuación, elija
Create Policy.
3. Junto a Create Your Own Policy, seleccione Select.
4. En Policy Name, escriba cualquier valor que sea fácil de consultar más tarde. Si lo desea, escriba un
texto descriptivo en Description.
5. En Policy Document, escriba una instrucción de política con el formato siguiente y, a continuación, elija
Create Policy:
{
"Version": "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"action-statement"
233
],
"Resource" : [
]
},
{
"Effect" : "Allow",
"Action" : [
"action-statement"
],
"Resource" : [
]
}
]
}
En esta instrucción, sustituya action-statement y resource-statement según sea necesario, y añada

otras instrucciones para especificar las entidades de API Gateway que desea que el usuario de IAM
pueda administrar, los métodos de API a los que puede llamar el usuario de IAM o ambas cosas. De
forma predeterminada, el usuario de IAM no tiene permisos a menos que exista la instrucción Allow
explícita correspondiente.
6. Para habilitar la política para un usuario, elija Users.
7. Elija el usuario de IAM a quien desea asociar la política.
Acaba de crear una política de IAM. No tendrá ningún efecto hasta que la asocie a un usuario de IAM, a un
grupo de IAM que contenga al usuario o a un rol de IAM asumido por el usuario.
Para asociar una política de IAM a un usuario de IAM
1. Para el usuario elegido, elija la pestaña Permissions y, a continuación, elija Attach Policy.
2. En Grant permissions, elija Attach existing policies directly.
3. Elija el documento de política que acaba de crear en la lista mostrada y, a continuación, elija Next:
Review.
4. En Permissions summary, elija Add permissions.
Del mismo modo, si lo desea, puede añadir el usuario a un grupo de IAM, si el usuario aún no es miembro,
y asociar el documento de política al grupo para que las políticas asociadas se apliquen a todos los
miembros del grupo. Esto es útil para administrar y actualizar configuraciones de políticas en un grupo de
usuarios de IAM. A continuación, explicaremos cómo asociar la política a un grupo de IAM, suponiendo
que ya haya creado el grupo y haya añadido al usuario al grupo.
Para asociar un documento de política de IAM a un grupo de IAM
1. Elija Groups en el panel de navegación principal.

2. Seleccione la pestaña Permissions en el grupo seleccionado.
3. Elija Attach policy.
4. Elija el documento de política que ha creado anteriormente y, a continuación, elija Attach policy.
Para que API Gateway llame a otros servicios de AWS en su nombre, cree un rol de IAM del tipo Amazon
API Gateway.
Para crear un tipo de rol Amazon API Gateway
1. Elija Roles en el panel de navegación principal.
234
Habilitar CORS para un recurso
2. Elija Create New Role.

3. Escriba un nombre para Role name y, a continuación, elija Next Step.
4. En Select Role Type, en AWS Service Roles, elija Select junto a Amazon API Gateway.
5. Elija una política de permisos de IAM administrada disponible (por ejemplo,
AmazonAPIGatewayPushToCloudWatchLog) si desea que API Gateway registre las métricas en
CloudWatch en Attach Policy y, a continuación, elija Next Step.
6. En Trusted Entities, compruebe que apigateway.amazonaws.com aparece como una entrada y, a
continuación, elija Create Role.
7. En el rol recién creado, elija la pestaña Permissions y, a continuación, elija Attach Policy.
8. Elija el documento de política de IAM personalizado creado anteriormente y, a continuación, elija
Attach Policy.
Habilitar CORS para un recurso de API Gateway

Cuando los recursos de la API reciben solicitudes de un dominio distinto del dominio propiedad de la API,
debe habilitar el uso compartido de recursos entre orígenes (CORS) para los métodos seleccionados en el
recurso. Esto implica permitir que la API responda a la solicitud de comprobación preliminar OPTIONS con al
menos los siguientes encabezados de respuesta necesarios para CORS:
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin
En API Gateway CORS se habilita configurando un método OPTIONS con el tipo de integración simulado
para devolver los encabezados de respuesta anteriores (con los valores estáticos descritos a continuación)
como encabezados de respuesta del método. Además, los métodos reales habilitados para CORS
también deben devolver el encabezado Access-Control-Allow-Origin:'request-originating server
addresses' en al menos su respuesta 200. Puede sustituir el valor estático de request-originating
server addresses por * para indicar cualquier servidor. Sin embargo, debe tener cuidado cuando habilite
una compatibilidad tan amplia y solo debe hacerlo si comprende muy bien cuáles son las consecuencias.
Con las integraciones Lambda, AWS o HTTP, puede usar API Gateway para configurar los encabezados
necesarios mediante la respuesta del método o la respuesta de integración. Para las integraciones de
proxy (p. 115) Lambda o HTTP, puede configurar los encabezados de respuesta OPTIONS necesarios
en API Gateway. Sin embargo, debe usar el backend para devolver los encabezados Access-Control-
Allow-Origin, ya que la respuesta de integración está deshabilitada para la integración de proxy.
Tip
Debe configurar un método OPTIONS para administrar las solicitudes de comprobación preliminar
que admite CORS. Sin embargo, los métodos OPTIONS son opcionales si 1) un recurso de API
solo expone los métodos GET, HEAD o POST y 2) el tipo de contenido de la carga del método es
application/x-www-form-urlencoded, multipart/form-data o text/plain y 3) la solicitud no
contiene encabezados personalizados. Cuando sea posible, es recomendable que use el método
OPTIONS para habilitar CORS en la API.
En esta sección se describe cómo habilitar CORS para un método en API Gateway mediante la consola de
API Gateway o la característica Importar una API (p. 217) de API Gateway.
Temas
• Habilitar CORS en un recurso mediante la consola de API Gateway (p. 236)
235
• Habilitar CORS para un recurso mediante la característica Import API de API Gateway (p. 238)
Requisitos previos
• El método debe estar disponible en API Gateway. Para obtener instrucciones sobre cómo crear y
configurar un método, consulte Cree una API de API Gateway para exponer un punto de enlace
HTTP (p. 8).
Habilitar CORS en un recurso mediante la consola de API

Gateway
2. En la consola de API Gateway, elija una API en APIs.
3. Elija un recurso en Resources. De esta forma, se habilitará CORS para todos los métodos existentes
en el recurso.
También puede elegir un método en el recurso para habilitar CORS solo para este método.
4. Elija Enable CORS en el menú desplegable Actions.
5. En el formulario Enable CORS, haga lo siguiente:
a. En el campo de entrada Access-Control-Allow-Headers, escriba una cadena estática de una

lista separada por comas de encabezados que el cliente debe enviar en la solicitud real del
recurso. Utilice la lista de encabezados proporcionada por la consola 'Content-Type,X-
Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token' o especifique sus propios
encabezados.
b. Utilice el valor proporcionado por la consola '*' como el valor de encabezado Access-Control-
Allow-Origin para permitir acceso desde todos los dominios o especifique un dominio con nombre
para todas las solicitudes de acceso desde el dominio especificado.
c. Elija Enable CORS and replace existing CORS headers.
236
Note
Al aplicar las instrucciones anteriores al método ANY en una integración de proxy, no se

establecerán los encabezados de CORS correspondientes. En lugar de ello, debe usar el
backend de integración para devolver los encabezados CORS correspondientes, por ejemplo,
Access-Control-Allow-Origin.
6. En Confirm method changes, elija Yes, overwrite existing values para confirmar la nueva configuración
de CORS.
Una vez habilitado CORS en el método GET, se añade un método OPTIONS al recurso si no aún no se
ha añadido. La respuesta 200 del método OPTIONS se configura automáticamente para devolver los tres
encabezados Access-Control-Allow-* para el protocolo preliminar. Asimismo, el método (GET) real
también está configurado de forma predeterminada para devolver el encabezado Access-Control-Allow-
Origin en su respuesta 200. Para otros tipos de respuestas, tendrá que configurarlas manualmente para
que devuelvan el encabezado Access-Control-Allow-Origin' con '*' o nombres de dominio de origen
específicos, si no desea recibir el error de acceso entre orígenes.
237
Al igual que con las actualizaciones de la API, debe implementar o volver a implementar la API para que la
nueva configuración surta efecto.
Habilitar CORS para un recurso mediante la característica Import

API de API Gateway
Si utiliza Import API de API Gateway (p. 217), puede configurar la compatibilidad de CORS con un
archivo de Swagger. En primer lugar, debe definir un método OPTIONS en el recurso que devuelva los
encabezados necesarios.
Note
Los navegadores web esperan que los encabezados Access-Control-Allow-Headers y Access-

Control-Allow-Origin estén configurados en cada método de API que acepta solicitudes de CORS.
Además, algunos navegadores primero realizan una solicitud HTTP a un método OPTIONS en el
mismo recurso y, a continuación, esperan recibir los mismos encabezados.
El siguiente ejemplo crea un método OPTIONS y especifica una integración simulada. Para obtener más
información, consulte Configurar una integración simulada para un método (p. 112).
/users
options:
summary: CORS support
description: |
Enable CORS by returning correct headers
consumes:
- application/json
produces:
- application/json
tags:
- CORS
x-amazon-apigateway-integration:
type: mock
requestTemplates:
application/json: |
{
"statusCode" : 200
}
responses:
"default":
statusCode: "200"
responseParameters:
method.response.header.Access-Control-Allow-Headers : "'Content-Type,X-Amz-
Date,Authorization,X-Api-Key'"
method.response.header.Access-Control-Allow-Methods : "'*'"
method.response.header.Access-Control-Allow-Origin : "'*'"
responseTemplates:
application/json: |
{}
responses:
200:
description: Default response for CORS method
headers:
Access-Control-Allow-Headers:
type: "string"
Access-Control-Allow-Methods:
type: "string"
Access-Control-Allow-Origin:
type: "string"
Una vez que haya configurado el método OPTIONS para su recurso, puede añadir los encabezados
necesarios a los otros métodos del mismo recurso necesarios para aceptar solicitudes de CORS.
238
Usar autorizadores personalizados
1. Declare Access-Control-Allow-Origin y Headers en los tipos de respuesta.
responses:
200:
description: Default response for CORS method
headers:
Access-Control-Allow-Headers:
type: "string"
Access-Control-Allow-Methods:
type: "string"
Access-Control-Allow-Origin:
type: "string"
2. En la etiqueta x-amazon-apigateway-integration, configure la asignación de esos encabezados a

los valores estáticos:
responses:
"default":
statusCode: "200"
responseParameters:
method.response.header.Access-Control-Allow-Headers : "'Content-Type,X-
Amz-Date,Authorization,X-Api-Key'"
method.response.header.Access-Control-Allow-Methods : "'*'"
method.response.header.Access-Control-Allow-Origin : "'*'"
Usar autorizadores personalizados de API Gateway

Un autorizador personalizado de Amazon API Gateway es una función Lambda que se proporciona
para controlar el acceso a los métodos de la API. Un autorizador personalizado utiliza estrategias de
autenticación de token al portador como OAuth o SAML. También puede utilizar la información descrita por
parámetros de solicitud como encabezados, rutas, cadenas de consulta, variables de etapa o variables de
contexto.
Note
Los parámetros de ruta pueden utilizarse para conceder o denegar permisos para invocar un
método, pero no se puedan utilizar para definir las fuentes de identidad, que se pueden utilizar
como parte de una clave de almacenamiento en caché de una política de autorización. Solo los
encabezados, las cadenas de consulta, las variables de etapa y las variables de contexto pueden
configurarse como fuentes de identidad.
Cuando un cliente llama a su API, API Gateway verifica si se ha configurado algún autorizador
personalizado para el método de la API. En caso afirmativo, API Gateway llama la función Lambda.
En esta llamada, API Gateway suministra el token de autorización que se extrae de un encabezado de
solicitud especificado para el autorizador basado en un token, o introduce los parámetros de solicitud
recibidos (por ejemplo, el parámetro event) como entrada para la función del autorizador basada en
parámetros de solicitud.
239
Puede implementar diversas estrategias de autorización, como la verificación mediante JSON Web Token
(JWT) y la llamada al proveedor de OAuth. También puede implementar un esquema personalizado
en función de los valores de los parámetros de solicitud recibidos, para devolver políticas de IAM que
autoricen la solicitud. Si la política devuelta no es válida o se deniegan los permisos, la llamada a la API no
prospera. Para una política válida, API Gateway almacena en caché la política devuelta, asociada con el
token de entrada o los parámetros de solicitud de la fuente de identidad. A continuación, utiliza la política
almacenada en caché para las solicitudes actuales y posteriores durante un periodo de tiempo de vida
(TTL) preconfigurado de hasta 3 600 segundos. Puede establecer el periodo de TTL en cero segundos
para deshabilitar el almacenamiento en caché de las políticas. El valor de TTL predeterminado es de 300
segundos. En la actualidad, el valor TTL máximo de 3 600 segundos no se puede aumentar.
Temas
• Tipos de autorizadores personalizados de API Gateway (p. 240)
• Crear la función Lambda de autorizador personalizado en API Gateway (p. 241)
• Entrada de una autorizado personalizado de Amazon API Gateway (p. 244)
• Salida de un autorizador personalizado de Amazon API Gateway (p. 246)
• Configurar un autorizador personalizado mediante la consola de API Gateway (p. 247)
• Llamar a una API con autorizadores personalizados de API Gateway (p. 249)
Tipos de autorizadores personalizados de API Gateway

API Gateway admite autorizadores personalizados de tipo TOKEN y REQUEST:
• Los autorizadores personalizados del tipo TOKEN conceden permisos a un intermediario para invocar una
determinada solicitud utilizando un token de autorización pasado en un encabezado. El token podría ser,
por ejemplo, un token de OAuth.
• Los autorizadores personalizados del tipo REQUEST conceden permisos a un intermediario para invocar
una solicitud determinada mediante parámetros de solicitud, incluidos los encabezados, las cadenas de
consulta, las variables de etapa o los parámetros de contexto.
240
Crear la función Lambda de autorizador personalizado en API

Gateway
Antes de crear un autorizador personalizado de API Gateway debe crear la función AWS Lambda que
implementa la lógica para autorizar y, si es necesario, autenticar al intermediario. Puede hacer esto en
la consola de Lambda, usando la plantilla de código disponible en el proyecto Autorizador personalizado
de API Gateway. También puede crear una desde el principio, siguiendo este ejemplo de awslabs. Para
fines ilustrativos, se explica cómo crear una función Lambda sencilla desde cero sin usar ningún plan.
En el código de producción, debe seguir el proyecto Autorizador personalizado de API Gateway para
implementar su función Lambda de autorizador.
Al crear la función Lambda para su autorizador personalizado de API Gateway, asignará un rol de
ejecución para la función Lambda si esta llama a otros servicios de AWS. En el siguiente ejemplo, el
rol básico AWSLambdaRole es suficiente. Para casos de uso más complejos, siga las instrucciones para
conceder permisos a un rol de ejecución para Lambda. función.
Crear la función Lambda de un autorizador personalizado del tipo TOKEN

En el editor de código de la consola de Lambda, escriba el siguiente código de node.js como ejemplo del
autorizador personalizado de API Gateway del tipo TOKEN.
// A simple TOKEN authorizer example to demonstrate how to use an authorization token

// to allow or deny a request. In this example, the caller named 'user' is allowed to
invoke
// a request if the client-supplied token value is 'allow'. The caller is not allowed to
invoke
// the request if the token value is 'deny'. If the token value is 'Unauthorized', the
function
// returns the 'Unauthorized' error with an HTTP status code of 401. For any other token
value,
// the authorizer returns an 'Invalid token' error.
exports.handler = (event, context, callback) => {

var token = event.authorizationToken;
switch (token.toLowerCase()) {
case 'allow':
callback(null, generatePolicy('user', 'Allow', event.methodArn));
break;
case 'deny':
callback(null, generatePolicy('user', 'Deny', event.methodArn));
break;
case 'unauthorized':
callback("Unauthorized"); // Return a 401 Unauthorized response
break;
default:
callback("Error: Invalid token");
}
};
// Help function to generate an IAM policy

var generatePolicy = function(principalId, effect, resource) {
var authResponse = {};
authResponse.principalId = principalId;
if (effect && resource) {
var policyDocument = {};
policyDocument.Version = '2012-10-17';
policyDocument.Statement = [];
var statementOne = {};
statementOne.Action = 'execute-api:Invoke';
statementOne.Effect = effect;
241
statementOne.Resource = resource;
policyDocument.Statement[0] = statementOne;
authResponse.policyDocument = policyDocument;
}
// Optional output with custom properties of the String, Number or Boolean type.
authResponse.context = {
"stringKey": "stringval",
"numberKey": 123,
"booleanKey": true
};
return authResponse;
}
Para autorizadores personalizados del tipo TOKEN, API Gateway pasa el token de origen a la función
Lambda como event.authorizationToken. Basado en el valor de este token, la función del autorizador
anterior devuelve una política Allow de IAM en un método especificado si el valor del token es 'allow'.
Esto permite que un intermediario invoque el método especificado. El intermediario recibe una respuesta
200 OK. La función del autorizador devuelve una política Deny con el método especificado si el token de
autorización tiene un valor 'deny'. Esto impide que el intermediario llame al método. El cliente recibe
una respuesta 403 Forbidden. Si el token es 'unauthorized', el cliente recibe una respuesta 401
Unauthorized. Si el token es 'fail' o cualquier otro, el cliente recibe una respuesta 500 Internal
Server Error. En los dos últimos casos, no se genera ninguna política de IAM y las llamadas fallan.
Note
En el código de producción, es posible que necesite autenticar al usuario antes de conceder

autorizaciones. En tal caso, puede añadir también la lógica de autenticación a la función Lambda.
Consulte la documentación específica del proveedor para obtener instrucciones sobre cómo
llamar a un proveedor de autenticación.
Además de devolver una política de IAM, la función del autorizador personalizado también debe devolver
el identificador principal del intermediario. También puede devolver un mapa de clave-valor denominado
context, que contiene información adicional que puede pasarse al backend de integración. Para
obtener más información acerca del formato de salida del autorizador, consulte Salida de un autorizador
personalizado de Amazon API Gateway (p. 246).
Puede utilizar el mapa context para devolver las credenciales almacenadas en caché del autorizador al
backend utilizando una plantilla de mapeo de una solicitud de integración. Esto permite que el backend
proporcione una mejor experiencia de usuario mediante la utilización de las credenciales almacenadas en
caché para reducir la necesidad de obtener acceso a las claves secretas y abrir los tokens de autorización
para cada solicitud.
En el caso de la integración del proxy Lambda API Gateway transmite el objeto context de un
autorizador personalizado directamente a la función Lambda del backend como parte de la entrada
event. Puede recuperar los pares de clave-valor de context en la función Lambda llamando a
$event.requestContext.authorizer.key. En el ejemplo de autorizador personalizado anterior, key es
stringKey, numberKey o booleanKey. Sus valores están representados en forma de cadena. Por ejemplo,
"stringval", "123" o "true", respectivamente.
Antes de continuar, es posible que desee probar la función Lambda desde la consola de Lambda. Para
ello, configure el evento de ejemplo para proporcionar una entrada como se describe en Entrada de una
autorizado personalizado de Amazon API Gateway (p. 244) y verifique el resultado comprobando que la
salida sea compatible con Salida de un autorizador personalizado de Amazon API Gateway (p. 246). En
la próxima subsección se explica cómo crear una función Lambda del autorizador Request.
Crear la función Lambda de un autorizador personalizado del tipo REQUEST

En el editor de código de la consola de Lambda, escriba el siguiente código de node.js para la función
Lambda simplificada como ejemplo del autorizador personalizado de API Gateway del tipo REQUEST.
242

console.log('Received event:', JSON.stringify(event, null, 2));
// A simple REQUEST authorizer example to demonstrate how to use request

// parameters to allow or deny a request. In this example, a request is
// authorized if the client-supplied HeaderAuth1 header, QueryString1 query parameter,
// stage variable of StageVar1 and the accountId in the request context all match
// specified values of 'headerValue1', 'queryValue1', 'stageValue1', and
// '123456789012', respectively.
// Retrieve request parameters from the Lambda function input:

var headers = event.headers;
var queryStringParameters = event.queryStringParameters;
var pathParameters = event.pathParameters;
var stageVariables = event.stageVariables;
var requestContext = event.requestContext;
// Parse the input for the parameter values

var tmp = event.methodArn.split(':');
var apiGatewayArnTmp = tmp[5].split('/');
var awsAccountId = tmp[4];
var region = tmp[3];
var restApiId = apiGatewayArnTmp[0];
var stage = apiGatewayArnTmp[1];
var method = apiGatewayArnTmp[2];
var resource = '/'; // root resource
if (apiGatewayArnTmp[3]) {
resource += apiGatewayArnTmp[3];
}
// Perform authorization to return the Allow policy for correct parameters and
// the 'Unauthorized' error, otherwise.
var condition = {};
condition.IpAddress = {};
if (headers.HeaderAuth1 === "headerValue1"

&& queryStringParameters.QueryString1 === "queryValue1"
&& stageVariables.StageVar1 === "stageValue1"
&& requestContext.accountId === "123456789012") {
callback(null, generateAllow('me', event.methodArn));
} else {
callback("Unauthorized");
}
}
// Help function to generate an IAM policy

var generatePolicy = function(principalId, effect, resource) {
// Required output:
authResponse.principalId = principalId;
if (effect && resource) {
var policyDocument = {};
policyDocument.Version = '2012-10-17'; // default version
policyDocument.Statement = [];
var statementOne = {};
statementOne.Action = 'execute-api:Invoke'; // default action
statementOne.Effect = effect;
statementOne.Resource = resource;
policyDocument.Statement[0] = statementOne;
authResponse.policyDocument = policyDocument;
}
// Optional output with custom properties of the String, Number or Boolean type.
authResponse.context = {
"stringKey": "stringval",
243
"numberKey": 123,
"booleanKey": true
};
return authResponse;
}
var generateAllow = function(principalId, resource) {

return generatePolicy(principalId, 'Allow', resource);
}
var generateDeny = function(principalId, resource) {

return generatePolicy(principalId, 'Deny', resource);
}
Esta función Lambda del autorizador REQUEST verifica los parámetros de solicitud de entrada para devolver
una política Allow de IAM en un método especificado si todos los valores necesarios de los parámetros
(HeaderAuth1, QueryString1, StageVar1 y accountId) coinciden con los preconfigurados. Esto permite
que un intermediario invoque el método especificado. El intermediario recibe una respuesta 200 OK. De lo
contrario, la función del autorizador devuelve un error Unauthorized sin generar ninguna política de IAM.
Antes de continuar, es posible que desee probar la función Lambda desde la consola de Lambda. Para
ello, configure el evento de ejemplo para proporcionar la entrada y verifique el resultado examinando la
salida. En las dos secciones siguientes se explica Entrada de una autorizado personalizado de Amazon
API Gateway (p. 244) y Salida de un autorizador personalizado de Amazon API Gateway (p. 246).
Entrada de una autorizado personalizado de Amazon API

Gateway
Para un autorizador personalizado del tipo TOKEN, debe especificar un encabezado personalizado
como Token Source al configurar el autorizador para su API. La API cliente debe transmitir el token de
autorización necesario en la solicitud de entrada. Tras recibir la solicitud del método de entrada, API
Gateway extrae el token del encabezado personalizado. A continuación, transmite el token como propiedad
authorizationToken del objeto event de la función Lambda, además del ARN del método como propiedad
methodArn:
{
"type":"TOKEN",
"authorizationToken":"<caller-supplied-token>",
"methodArn":"arn:aws:execute-
api:<regionId>:<accountId>:<apiId>/<stage>/<method>/<resourcePath>"
}
En este ejemplo, la propiedad type especifica el tipo de autorizador, que es un autorizador TOKEN.
<caller-supplied-token> se origina del encabezado de autorización personalizado de una solicitud del
cliente. methodArn es el ARN de la solicitud de método de entrada y lo rellena API Gateway de acuerdo
con la configuración del autorizador personalizado.
Para la función Lambda del autorizador TOKEN de ejemplo mostrada en la sección anterior, la cadena
<caller-supplied-token es allow, deny, unauthorized o cualquier otro valor de cadena. Una cadena
vacía es lo mismo que unauthorized. A continuación, se muestra un ejemplo de este tipo de entrada
para obtener una política Allow en el método GET de una API (ymy8tbxw7b) de la cuenta de AWS
(123456789012) en cualquier etapa (*).
{
"type":"TOKEN",
"authorizationToken":"allow",
"methodArn":"arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/GET/"
}
244
Para un autorizador personalizado del tipo REQUEST, API Gateway transmite los parámetros de solicitud
necesarios a la función Lambda del autorizador como parte del objeto event. Los parámetros de solicitud
afectados incluyen encabezados, parámetros de ruta, parámetros de cadenas de consulta, variables de
etapa y algunas variables de contexto de solicitud. El intermediario de la API puede definir parámetros
de ruta, encabezados y parámetros de cadenas de consulta. El desarrollador de la API debe establecer
las variables de etapa durante la implementación de la API y API Gateway proporciona el contexto de la
solicitud en tiempo de ejecución.
El siguiente ejemplo muestra una entrada de un autorizador REQUEST para un método de la API (GET /
request) con una integración de proxy:
{
"type": "REQUEST",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:s4x3opwd6i/test/GET/request",
"resource": "/request",
"path": "/request",
"headers": {
"X-AMZ-Date": "20170718T062915Z",
"Accept": "*/*",
"HeaderAuth1": "headerValue1",
"User-Agent": "...",
"X-Forwarded-Proto": "https",
"Host": "....execute-api.us-east-1.amazonaws.com",
"Accept-Encoding": "gzip, deflate",
"X-Amzn-Trace-Id": "...",
"Via": "...cloudfront.net (CloudFront)",
"X-Amz-Cf-Id": "...",
"X-Forwarded-For": "..., ...",
"Postman-Token": "...",
"cache-control": "no-cache",
"Content-Type": "application/x-www-form-urlencoded"
},
"queryStringParameters": {
"QueryString1": "queryValue1"
},
"pathParameters": {},
"stageVariables": {
"StageVar1": "stageValue1"
},
"requestContext": {
"path": "/request",
"accountId": "123456789012",
"resourceId": "05c7jb",
"stage": "test",
"requestId": "...",
"identity": {
"apiKey": "...",
"sourceIp": "..."
},
"resourcePath": "/request",
"apiId": "s4x3opwd6i"
}
}
245
requestContext es un mapa de pares de clave-valor y se corresponde con la variable $context (p. 158).
Su resultado depende de la API. API Gateway puede añadir nuevas claves al mapa. Para obtener más
información sobre la entrada de la función Lambda en una integración de proxy, consulte Formato de
entrada de una función Lambda para la integración de proxy (p. 121).
Salida de un autorizador personalizado de Amazon API Gateway

La función Lambda del autorizador personalizado devuelve una salida que debe incluir el identificador
principal (principalId) y un documento de política (policyDocument) que contenga una lista de
instrucciones de política. La salida también puede incluir un mapa context que contenga pares de clave-
valor. A continuación se muestra un ejemplo de esta salida.
{
"principalId": "yyyyyyyy", // The principal user identification associated with the token
sent by the client.
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow|Deny",
"Resource": "arn:aws:execute-api:<regionId>:<accountId>:<appId>/<stage>/<httpVerb>/
[<resource>/<httpVerb>/[...]]"
}
]
},
"context": {
"stringKey": "value",
"numberKey": "1",
"booleanKey": "true"
}
}
Aquí, una instrucción de política estipula si se permite o deniega (Effect) al servicio de ejecución de API
Gateway invocar (Action) el método de API especificado (Resource). Puede utilizar un carácter comodín
(*) para especificar un tipo de recurso (método). Para obtener información sobre la configuración de
políticas válidas para llamar a una API, consulte Referencia de instrucciones de políticas de IAM para
ejecutar la API en API Gateway (p. 227).
Puede tener acceso al valor principalId de una plantilla de asignación utilizando la variable
$context.authorizer.principalId. Esto resulta útil si desea transmitir el valor al backend. Para obtener
más información, consulte Acceso a la variable $context (p. 158).
Puede obtener acceso al valor de stringKey, numberKey o booleanKey (por ejemplo, "value", "1" o
"true") del mapa context en una plantilla de mapeo llamando a $context.authorizer.stringKey,
$context.authorizer.numberKey o $context.authorizer.booleanKey, respectivamente. Los valores
devueltos se representan en forma de cadena. Observe que no puede establecer un objeto o matriz JSON
como un valor válido de ninguna clave en el mapa context.
El siguiente ejemplo muestra la salida del ejemplo de autorizador personalizado. La salida del ejemplo
contiene una instrucción de política para bloquear (Deny) las llamadas al método GET de una API
(ymy8tbxw7b) de una cuenta de AWS (123456789012) en cualquier etapa (*).
{
"principalId": "user",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
246
"Effect": "Deny",
"Resource": "arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/*/GET/"
}
]
}
}
Configurar un autorizador personalizado mediante la consola de

API Gateway
Después de crear la función Lambda y verificar que funciona, siga los pasos siguientes para configurar el
autorizador personalizado de API Gateway en la consola de API Gateway.
Habilitar un autorizador personalizado en métodos de API

2. Cree una nueva API o seleccione una ya existente y elija Authorizers en esa API.
3. Elija Create New Authorizer.
4. Para Create Authorizer, escriba un nombre de autorizador en el campo de entrada Name.
5. Para Type, seleccione la opción Lambda.
6. Para Lambda Function, elija una región y, a continuación, elija una función Lambda del autorizador
personalizado disponible.
7. Deje en blanco el campo Lambda Execution Role para permitir que la consola de API Gateway
defina una política basada en recursos. La política concede permisos de API Gateway para invocar
la función Lambda del autorizador. También puede escribir el nombre de un rol de IAM para permitir
que API Gateway invoque la función Lambda del autorizador. Para ver un ejemplo de este rol, consulte
Configurar un rol y una política de IAM para que una API invoque funciones Lambda (p. 396).
Si elige permitir que la consola de API Gateway defina la política basada en recursos, se mostrará
el cuadro de diálogo Add Permission to Lambda Function. Seleccione OK. Una vez creada la
autorización personalizada, puede probarla con los valores del token de autorización adecuados para
comprobar que funciona según lo previsto.
8. Para Lambda Event Payload, elija Token para un autorizador TOKEN o bien Request para un
autorizador REQUEST. (Es lo mismo que establecer la propiedad type de TOKEN o de REQUEST.)
9. Dependiendo de la elección del paso anterior, lleve a cabo alguna de las siguientes operaciones:
a. Para las opciones Token, haga lo siguiente:
• Escriba el nombre de un encabezado en Token Source. El cliente de la API debe incluir un

encabezado con este nombre para enviar el token de autorización al autorizador personalizado.
• Opcionalmente, proporcione una instrucción RegEx en el campo de entrada Token Validation.
API Gateway realiza la validación inicial del token de entrada contra esta expresión e invoca el
autorizador tras una validación correcta. Esto ayuda a reducir la posibilidad de que se cobre por
tokens no válidos.
• Para Authorization Caching, seleccione o anule la selección de la opción Enabled, en función
de si desea almacenar en caché o no la política de autorización generada por el autorizador.
Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor TTL del
valor predeterminado (300). Si establece TTL=0, se desactivará el almacenamiento en caché
de políticas. Cuando el almacenamiento en caché de las políticas esté habilitado, el nombre del
encabezado especificado en Token Source pasará a ser la clave de caché.
b. Para la opción Request, haga lo siguiente:
• Para Identity Sources, escriba un nombre de parámetro de solicitud de un tipo de parámetro

elegido. Los tipos de parámetro admitidos son Header, Query String, Stage Variable y
Context. Para añadir más fuentes de identidad, elija Add Identity Source.
247
API Gateway utiliza las fuentes de identidad especificadas como la clave de caché del
autorizador de la solicitud. Cuando está habilitado el almacenamiento en caché, API Gateway
llama a la función Lambda del autorizador solo después de verificar correctamente que todas
las fuentes de identidad especificadas estén presentes en tiempo de ejecución. Si falta alguna
fuente de identidad especificada, o bien es nula o está vacía, API Gateway devolverá una
respuesta 401 Unauthorized sin llamar a la función Lambda del autorizador.
Cuando se definen varias fuentes de identidad, todas se utilizan para obtener la clave de caché
del autorizador. Cambiar cualquiera de las partes de la clave de caché hace que el autorizador
descarte el documento de políticas almacenado en caché y genere otro nuevo.
• Para Authorization Caching, seleccione o anule la selección de la opción Enabled, en función
de si desea almacenar en caché o no la política de autorización generada por el autorizador.
Cuando se activa el almacenamiento en caché de políticas, puede modificar el valor TTL del
valor predeterminado (300). Si establece TTL=0, se desactiva el almacenamiento en caché de
políticas.
Cuando está desactivado el almacenamiento en caché, no es necesario especificar ninguna

fuente de identidad. API Gateway no realiza ninguna validación antes de invocar la función
Lambda del autorizador.
Note
Para habilitar el almacenamiento en caché, su autorizador debe devolver una política que se
aplique a todos los métodos a través de una API. Para forzar la política especificada por el
método, puede establecer el valor de TTL en cero para deshabilitar el almacenamiento en
caché de políticas para la API.
10. Elija Create para crear el nuevo autorizador personalizado para la API elegida.
11. Una vez que se crea el autorizador para la API, tiene la opción de probar la llamada a un autorizador
antes de configurarlo en un método.
Para el autorizador TOKEN, escriba un token válido en el campo de texto de entrada Identity token y
seleccione Test. El token se transferirá a la función Lambda como el encabezado que especificó en la
configuración de Identity token source del autorizador.
Para el autorizador REQUEST, escriba los parámetros de solicitud válidos correspondientes a las fuentes
de identidad especificadas y, a continuación, seleccione Test.
Además de utilizar la consola de API Gateway, puede utilizar AWS CLI o un SDK de AWS para API
Gateway para probar la llamada a un autorizador. Para hacerlo a través de AWS CLI, consulte test-
invoke-authorizer.
Note
Los procesos "test-invoke" para ejecuciones de métodos y "test-invoke" para autorizadores

son procesos independientes.
Para probar la llamada a un método usando la consola de API Gateway, consulte Usar la
consola para probar un método (p. 348). Para probar la llamada a un método usando AWS
CLI, consulte test-invoke-method.
Para probar la llamada a un método y a un autorizador configurado, implemente la API y, a
continuación, utilice cURL o Postman para llamar al método, proporcionando el token o los
parámetros de solicitud necesarios.
El procedimiento siguiente muestra cómo configurar un método de API para que use el autorizador
personalizado.
248
Configurar un método de API para que use un autorizador personalizado
1. Vuelva a la API. Cree un nuevo método o elija un método existente. Si es necesario, cree un nuevo
recurso.
2. En Method Execution, elija el enlace Method Request.
3. En Settings, expanda la lista desplegable Authorization para seleccionar el autorizador personalizado
que acaba de crear (por ejemplo, myTestApiAuthorizer) y, a continuación, elija el icono de marca de
verificación para guardar la selección.
4. Si lo desea, mientras está en la página Method Request, elija Add header si también quiere transmitir
el token de autorización personalizado al backend. En Name, escriba un nombre de encabezado
personalizado que coincida con el nombre de Token Source que especificó al crear el autorizador
personalizado para la API. A continuación, elija el icono de marca de verificación para guardar la
configuración. Este paso no se aplica a los autorizadores REQUEST.
5. Elija Deploy API para implementar la API en una etapa. Tenga en cuenta el valor Invoke URL. Lo
necesitará cuando llame a la API. Para un autorizador REQUEST que utiliza variables de etapa, también
debe definir las variables de etapa necesarias y especificar sus valores en Stage Editor.
Llamar a una API con autorizadores personalizados de API

Gateway
Después de configurar el autorizador personalizado e implementar la API, debe probar la API con el
autorizador personalizado habilitado. Para ello, necesita un cliente REST, como cURL. Postman. En los
siguientes ejemplos, usamos Postman.
Note
Al llamar a un método habilitado para un autorizador, API Gateway no registra la llamada en

CloudWatch si el token necesario para el autorizador TOKEN no se establece, es nulo o no es
válido para la expresión Token validation expression especificada. Del mismo modo, API Gateway
no registra la llamada a CloudWatch si cualquiera de las fuentes de identidad necesarias para el
autorizador REQUEST no está establecida, es nula o está vacía.
A continuación, mostramos cómo utilizar Postman para llamar a la API o probarla con el autorizador
personalizado TOKEN habilitado, descrito anteriormente. El método puede usarse para llamar a una API
con un autorizador personalizado REQUEST si especifica la ruta, el encabezamiento o los parámetros de
cadenas de consulta necesarios de forma explícita.
Llamar a una API con el autorizador personalizado TOKEN
1. Abra Postman, elija el método GET y pegue el elemento Invoke URL de la API en el campo URL
contiguo.
Añada el encabezado de token de autorización personalizado y establezca el valor en allow.

Seleccione Send.
249
La respuesta muestra que el autorizador personalizado de API Gateway devuelve una respuesta 200
OK y autoriza correctamente la llamada para tener acceso al punto de enlace HTTP (http://httpbin.org/
get) integrado con el método.
2. Aún en Postman, cambie el valor del encabezado de token de autorización personalizado a deny.
Seleccione Send.
La respuesta muestra que el autorizador personalizado de API Gateway devuelve una respuesta 403
Forbidden sin autorizar la llamada para tener acceso al punto de enlace HTTP.
250
3. En Postman, cambie el valor del encabezado de token de autorización personalizado a unauthorized

y elija Send.
La respuesta muestra que API Gateway devuelve una respuesta 401 Unauthorized sin autorizar la
llamada para tener acceso al punto de enlace HTTP.
4. Ahora, cambie el valor del encabezado de token de autorización personalizado a fail. Seleccione
Send.
La respuesta muestra que API Gateway devuelve una respuesta 500 Internal Server Error sin autorizar
la llamada para tener acceso al punto de enlace HTTP.
251
Usar conjuntos de usuarios de Amazon Cognito

Además de utilizar roles y políticas de IAM (p. 221) o autorizadores personalizados (p. 239), también
puede utilizar un conjunto de usuarios en Amazon Cognito para controlar quién puede tener acceso a
su API en API Gateway. Un conjunto de usuarios actúa como su propio proveedor de identidad para
mantener un directorio de usuarios. Admite el registro y el inicio de sesión de los usuarios, así como el
aprovisionamiento de tokens de identidad para los usuarios que han iniciado sesión.
Note
Para obtener los permisos de un rol de IAM mediante credenciales de Amazon Cognito, utilice
Identidades federadas de Amazon Cognito para obtener credenciales temporales y defina el tipo
de autorización en AWS_IAM en la API.
Un grupo de usuarios se integra con una API como un autorizador de método que se aplica a cualquier
método. Cuando se llama a los métodos con un autorizador habilitado, un cliente API incluye en los
encabezados de la solicitud el token de identidad del usuario aprovisionado desde el conjunto de
usuarios. A continuación, API Gateway valida el token para garantizar que pertenece al grupo de usuarios
configurado y autentica al intermediario antes de transmitir la solicitud al backend.
Para integrar una API con el proveedor de identidad de Amazon Cognito, usted, como desarrollador
de la API, crea un conjunto de usuarios, crea un autorizador de API Gateway conectado al conjunto de
usuarios y habilita el autorizador en los métodos de la API seleccionados. Asimismo, debe distribuir a
los desarrolladores de clientes API el ID del conjunto de usuarios, un ID de cliente y, posiblemente, el
secreto de cliente aprovisionado desde el conjunto de usuarios. El cliente necesitará esta información para
registrar a los usuarios con el conjunto de usuarios, para proporcionar la funcionalidad de inicio de sesión y
para disponer del token de identidad del usuario aprovisionado desde el conjunto de usuarios.
En esta sección, aprenderá a crear un conjunto de usuarios, a integrar una API de API Gateway con el
conjunto de usuarios y a invocar una API integrada con el conjunto de usuarios.
Temas
• Crear un conjunto de usuarios (p. 252)
• Integrar una API con un conjunto de usuarios (p. 252)
• Llamar a una API integrada con un conjunto de usuarios (p. 255)
Crear un conjunto de usuarios

Antes de integrar la API con un conjunto de usuarios, debe crear el conjunto de usuarios en Amazon
Cognito. Para obtener instrucciones sobre cómo crear un conjunto de usuarios, consulte Setting up User
Pools en la Amazon Cognito Developer Guide.
Note
Anote el ID del conjunto de usuarios, el ID del cliente y el secreto del cliente, si se han
seleccionado estos elementos. El cliente deberá proporcionarlos a Amazon Cognito para que
el usuario se registre con el conjunto de usuarios, para iniciar sesión en el conjunto de usuarios
y para obtener un token de identidad que se debe incluir en las solicitudes para llamar a los
métodos de la API configurados con el conjunto de usuarios. Además, tendrá que especificar el
nombre del conjunto de usuarios cuando configure el conjunto de usuarios como un autorizador
de API Gateway, tal y como se describe a continuación.
Integrar una API con un conjunto de usuarios

Para integrar la API con un conjunto de usuarios, debe crear en API Gateway un autorizador de conjunto
de usuarios conectado al conjunto de usuarios. El siguiente procedimiento le guía por los pasos para
realizar esta operación con la consola de API Gateway.
252
Para crear un autorizador del conjunto de usuarios con la consola de API Gateway
1. Cree una nueva API o seleccione una existente en API Gateway.

2. En el panel de navegación principal, elija Authorizers en la API especificada.
3. En Authorizers, elija Create y, a continuación, elija Cognito User Pool Authorizer.
4. Para configurar este autorizador:
a. Elija una región en Cognito region.

b. En Cognito User Pool, elija un grupo de usuarios disponible.
c. El campo Authorizer name se rellenará automáticamente con el nombre del grupo de usuarios
elegido. Sin embargo, puede personalizarlo si lo desea.
d. El campo Identity token source se establecerá en method.request.header.Authorization
de forma predeterminada. Sin embargo, puede personalizarlo si lo desea. Si se usa el valor
predeterminado, Authorization será el nombre del encabezado de la solicitud entrante que
contiene el token de identidad del intermediario de la API.
e. Si lo desea, escriba una expresión regular en el campo App client ID regex para validar los ID de
cliente asociados con el grupo de usuarios.
f. Elija Create para terminar de integrar el grupo de usuarios con la API.
5. Una vez creado el autorizador, puede, si lo desea, probarlo proporcionando un token de identidad
aprovisionado desde el conjunto de usuarios.
Para habilitar un autorizador de conjunto de usuarios en los métodos
1. Elija (o cree) un método de la API.

3. En Authorization Settings, elija el icono de edición en el campo Authorization.
4. Elija uno de los Amazon Cognito User Pool authorizers disponibles en la lista desplegable.
5. Elija el icono de marca de verificación para guardar la configuración.
6. Repita estos pasos para otros métodos que elija.
7. Si fuera necesario, elija Integration Request para añadir las expresiones
$context.authorizer.claims['property-name'] o $context.authorizer.claims.property-
name a una plantilla de mapeo de cuerpo para transmitir la propiedad de notificaciones de identidad
especificada del grupo de usuarios al backend. Para los nombres de propiedad sencillos, como sub
o custom-sub, las dos notaciones son idénticas. Para los nombres de propiedad complejos, como
custom:role, no se puede usar la notación de punto. Por ejemplo, las siguientes expresiones de
mapeo transmiten los campos estándar sub y email de la notificación al backend:
{
"context" : {
"sub" : "$context.authorizer.claims.sub",
"email" : "$context.authorizer.claims.email"
}
}
Si ha declarado un campo de notificación personalizado al configurar un conjunto de usuarios, puede

seguir el mismo patrón para tener acceso a los campos personalizados. El siguiente ejemplo obtiene
un campo role personalizado de una notificación:
{
"context" : {
"role" : "$context.authorizer.claims.role"
}
}
253
Si el campo de notificación personalizada se declara como custom:role, utilice el siguiente ejemplo

para obtener la propiedad de la notificación:
{
"context" : {
"role" : "$context.authorizer.claims['custom:role']"
}
}
En lugar de utilizar la consola de API Gateway, también puede habilitar un conjunto de usuarios de
Amazon Cognito en un método configurando un archivo de definición de Swagger e importando la
definición de API en API Gateway.
Para importar un autorizador de conjunto de usuarios con un archivo de definición de Swagger
1. Cree (o exporte) un archivo de definición de Swagger para la API.

2. Añada la configuración del conjunto de usuarios a securityDefinitions:
"securityDefinitions": {
"MyUserPool": {
"type": "apiKey",
"name": "Authorization",
"in": "header",
"x-amazon-apigateway-authtype": "cognito_user_pools",
"x-amazon-apigateway-authorizer": {
"type": "cognito_user_pools",
"providerARNs": [
"arn:aws:cognito-idp:{region}:{account_id}:userpool/{user_pool_id}"
]
}
}
3. Active el conjunto de usuarios de Cognito (MyUserPool) como un autorizador para un método, tal y
como se muestra en el siguiente método GET en el recurso raíz.
"paths": {
"/": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"text/html"
],
"responses": {
"200": {
"headers": {
"Content-Type": {
"type": "string"
}
}
}
},
"security": [
{
"MyUserPool": []
}
],
254
"type": "mock",
"responses": {
"default": {
"method.response.header.Content-Type": "'text/html'"
},
}
},
"application/json": "{\"statusCode\": 200}"
},
"passthroughBehavior": "when_no_match"
}
},
...
}
4. Si es necesario, puede establecer otra configuración de la API mediante las definiciones o extensiones
de Swagger correspondientes. Para obtener más información, consulte Extensiones de API Gateway
para Swagger (p. 373).
Llamar a una API integrada con un conjunto de usuarios

Para llamar a un método con un autorizador de conjunto de usuarios configurado, el cliente debe hacer lo
siguiente:
• Permitir al usuario inscribirse en el conjunto de usuarios.

• Permitir al usuario iniciar sesión en el conjunto de usuarios.
• Obtener un token de identidad del usuario conectado del conjunto de usuarios.
• Incluir el token de identidad en el encabezado Authorization (u otro encabezado especificado al crear
el autorizador).
Puede utilizar uno de los SDK de AWS para realizar estas tareas. Por ejemplo:
• Para utilizar el SDK de Android, consulte Setting up the AWS Mobile SDK for Android to Work with User
Pools.
• Para utilizar el SDK de iOS, consulte Setting Up the AWS Mobile SDK for iOS to Work with User Pools.
• Para utilizar JavaScript, consulte Setting up the AWS SDK for JavaScript in the Browser to Work with
User Pools.
El siguiente procedimiento describe los pasos para realizar estas tareas. Para obtener más información,
consulte las entradas de blog en Using Android SDK with Amazon Cognito User Pools y Using Amazon
Cognito User Pool for iOS.
Para llamar a una API integrada con un conjunto de usuarios
1. Inscriba a un usuario nuevo en un conjunto de usuarios especificado.

2. Inicie sesión al usuario en el conjunto de usuarios.
3. Obtenga el token de identidad del usuario.
4. Llame a los métodos de API configurados con un autorizador de conjunto de usuarios, proporcionando
un token no caducado en el encabezado Authorization u otro encabezado que elija.
5. Cuando el token caduque, repita los pasos del 2 al 4. Los tokens de identidad proporcionados por
Amazon Cognito caducan en el plazo de una hora.
255
Usar certificados SSL del lado cliente
Para ver ejemplos de código, consulte un ejemplo de Java para Android y un ejemplo de Objective-C para
iOS.
Uso de certificados SSL del lado cliente para la

autenticación por el backend
Puede utilizar API Gateway para generar un certificado SSL y usar su clave pública en el backend para
verificar que las solicitudes HTTP a su sistema backend proceden de API Gateway. Esto permite que el
backend HTTP controle y acepte únicamente las solicitudes procedentes de Amazon API Gateway, incluso
si el backend está disponible públicamente.
Note
Puesto que algunos servidores backend no son compatibles con la autenticación SSL de los
clientes de la manera en que lo es API Gateway, podrían devolver un error de certificado SSL.
Para obtener una lista de backends incompatibles, consulte Problemas conocidos (p. 474).
Los certificados SSL generados por API Gateway son autofirmados y solo la clave pública de un certificado
está visible en la consola de API Gateway o a través de las API.
Temas
• Generar un certificado cliente mediante la consola de API Gateway (p. 256)
• Configurar una API para que use certificados SSL (p. 257)
• Test Invoke (p. 258)
• Configuración del backend para autenticar la API (p. 260)
Generar un certificado cliente mediante la consola de API

Gateway
1. En el panel de navegación principal, seleccione Client Certificates.
2. En el panel Client Certificates, elija Generate Client Certificate.
3. Si lo desea, en Edit, elija añadir un título descriptivo al certificado generado y seleccione Save para
guardar la descripción. API Gateway genera un certificado nuevo y devuelve el GUID del nuevo
certificado junto con la clave pública codificada en PEM.
256
Ahora está listo para configurar una API para que utilice el certificado.
Configurar una API para que use certificados SSL

En estas instrucciones, se presupone que usted ya ha completado Generar un certificado cliente mediante
la consola de API Gateway (p. 256).
1. En la consola de API Gateway, cree o abra una API para la que desee utilizar el certificado cliente.
Asegúrese de que la API se ha implementado en una etapa.
2. Elija Stages en la API seleccionada y, a continuación, elija una etapa.
3. En el panel Stage Editor, seleccione un certificado en la sección Client Certificate.
4. Para guardar la configuración, elija Save Changes.
Una vez seleccionado y guardado un certificado para la API, API Gateway utilizará el certificado para todas
las llamadas a las integraciones HTTP de la API.
257
Test Invoke
1. Elija un método de API. En Client, elija Test.
2. En Client Certificate, elija Test para invocar la solicitud de método.
258
259
Entidades de certificación compatibles
para las integraciones HTTP y Proxy HTTP
API Gateway presentará el certificado SSL elegido al backend HTTP para autenticar la API.
Configuración del backend para autenticar la API

En estas instrucciones, se presupone que usted ya ha completado Generar un certificado cliente mediante
la consola de API Gateway (p. 256) y Configurar una API para que use certificados SSL (p. 257).
Cuando reciba solicitudes HTTPS de API Gateway su backend puede autenticar la API mediante el
certificado codificado en PEM generado por API Gateway, siempre que el backend esté configurado
correctamente. La mayoría de los servidores web se pueden configurar fácilmente para ello.
Por ejemplo, en Node.js, puede utilizar el módulo HTTPS para crear un backend HTTPS y utilizar los
módulos client-certificate-auth para autenticar las solicitudes cliente con certificados codificados
en PEM. Para obtener más información, consulte HTTPS en el sitio web de Nodejs.org y consulte client-
certificate-auth en el sitio web https://www.npmjs.com/.
Entidades de certificación compatibles con API

Gateway para las integraciones HTTP y Proxy HTTP
En la siguiente lista se incluyen las entidades de certificación compatibles con API Gateway para las
integraciones HTTP y Proxy HTTP.
Alias name: mozillacert81.pem

MD5: D5:E9:81:40:C5:18:69:FC:46:2C:89:75:62:0F:AA:78
SHA1: 07:E0:32:E0:20:B7:2C:3F:19:2F:06:28:A2:59:3A:19:A7:0F:06:9E
SHA256:
5C:58:46:8D:55:F5:8E:49:7E:74:39:82:D2:B5:00:10:B6:D1:65:37:4A:CF:83:A7:D4:A3:2D:B7:68:C4:40:8E
MD5: 2B:70:20:56:86:82:A0:18:C8:07:53:12:28:70:21:72
SHA1: F1:7F:6F:B6:31:DC:99:E3:A3:C8:7F:FE:1C:F1:81:10:88:D9:60:33
SHA256:
97:8C:D9:66:F2:FA:A0:7B:A7:AA:95:00:D9:C0:2E:9D:77:F2:CD:AD:A6:AD:6B:A7:4A:F4:B9:1C:66:59:3C:50
Alias name: swisssignplatinumg2ca
MD5: C9:98:27:77:28:1E:3D:0E:15:3C:84:00:B8:85:03:E6
SHA1: 56:E0:FA:C0:3B:8F:18:23:55:18:E5:D3:11:CA:E8:C2:43:31:AB:66
SHA256:
3B:22:2E:56:67:11:E9:92:30:0D:C0:B1:5A:B9:47:3D:AF:DE:F8:C8:4D:0C:EF:7D:33:17:B4:C1:82:1D:14:36
MD5: 60:84:7C:5A:CE:DB:0C:D4:CB:A7:E9:FE:02:C6:A9:C0
SHA1: 10:1D:FA:3F:D5:0B:CB:BB:9B:B5:60:0C:19:55:A4:1A:F4:73:3A:04
SHA256:
D4:1D:82:9E:8C:16:59:82:2A:F9:3F:CE:62:BF:FC:DE:26:4F:C8:4E:8B:95:0C:5F:F2:75:D0:52:35:46:95:A3
MD5: AB:57:A6:5B:7D:42:82:19:B5:D8:58:26:28:5E:FD:FF
SHA1: B1:2E:13:63:45:86:A4:6F:1A:B2:60:68:37:58:2D:C4:AC:FD:94:97
SHA256:
E3:B6:A2:DB:2E:D7:CE:48:84:2F:7A:C5:32:41:C7:B7:1D:54:14:4B:FB:40:C1:1F:3F:1D:0B:42:F5:EE:A1:2D
MD5: 4F:EB:F1:F0:70:C2:80:63:5D:58:9F:DA:12:3C:A9:C4
SHA1: E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B
SHA256:
0B:5E:ED:4E:84:64:03:CF:55:E0:65:84:84:40:ED:2A:82:75:8B:F5:B9:AA:1F:25:3D:46:13:CF:A0:80:FF:3F
MD5: 5E:80:9E:84:5A:0E:65:0B:17:02:F3:55:18:2A:3E:D7
SHA1: 78:6A:74:AC:76:AB:14:7F:9C:6A:30:50:BA:9E:A8:7E:FE:9A:CE:3C
SHA256:
06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0
MD5: 73:9F:4C:4B:73:5B:79:E9:FA:BA:1C:EF:6E:CB:D5:C9
260
SHA1: FE:45:65:9B:79:03:5B:98:A1:61:B5:51:2E:AC:DA:58:09:48:22:4D
SHA256:
BC:10:4F:15:A4:8B:E7:09:DC:A5:42:A7:E1:D4:B9:DF:6F:05:45:27:E8:02:EA:A9:2D:59:54:44:25:8A:FE:71
MD5: FC:11:B8:D8:08:93:30:00:6D:23:F9:7E:EB:52:1E:02
SHA1: 70:17:9B:86:8C:00:A4:FA:60:91:52:22:3F:9F:3E:32:BD:E0:05:62
SHA256:
69:FA:C9:BD:55:FB:0A:C7:8D:53:BB:EE:5C:F1:D5:97:98:9F:D0:AA:AB:20:A2:51:51:BD:F1:73:3E:E7:D1:22
MD5: DC:32:C3:A7:6D:25:57:C7:68:09:9D:EA:2D:A9:A2:D1
SHA1: 87:82:C6:C3:04:35:3B:CF:D2:96:92:D2:59:3E:7D:44:D9:34:FF:11
SHA256:
F1:C1:B5:0A:E5:A2:0D:D8:03:0E:C9:F6:BC:24:82:3D:D3:67:B5:25:57:59:B4:E7:1B:61:FC:E9:F7:37:5D:73
Alias name: buypassclass2ca
MD5: 46:A7:D2:FE:45:FB:64:5A:A8:59:90:9B:78:44:9B:29
SHA1: 49:0A:75:74:DE:87:0A:47:FE:58:EE:F6:C7:6B:EB:C6:0B:12:40:99
SHA256:
9A:11:40:25:19:7C:5B:B9:5D:94:E6:3D:55:CD:43:79:08:47:B6:46:B2:3C:DF:11:AD:A4:A0:0E:FF:15:FB:48
Alias name: chunghwaepkirootca
MD5: 1B:2E:00:CA:26:06:90:3D:AD:FE:6F:15:68:D3:6B:B3
SHA1: 67:65:0D:F1:7E:8E:7E:5B:82:40:A4:F4:56:4B:CF:E2:3D:69:C6:F0
SHA256:
C0:A6:F4:DC:63:A2:4B:FD:CF:54:EF:2A:6A:08:2A:0A:72:DE:35:80:3E:2F:F5:FF:52:7A:E5:D8:72:06:DF:D5
Alias name: verisignclass2g2ca
MD5: 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1
SHA1: B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D
SHA256:
3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1
MD5: CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
SHA1: 13:2D:0D:45:53:4B:69:97:CD:B2:D5:C3:39:E2:55:76:60:9B:5C:C6
SHA256:
EB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1:B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44
MD5: C1:62:3E:23:C5:82:73:9C:03:59:4B:2B:E9:77:49:7F
SHA1: 2A:B6:28:48:5E:78:FB:F3:AD:9E:79:10:DD:6B:DF:99:72:2C:96:E5
SHA256:
07:91:CA:07:49:B2:07:82:AA:D3:C7:D7:BD:0C:DF:C9:48:58:35:84:3E:B2:D7:99:60:09:CE:43:AB:6C:69:27
Alias name: utndatacorpsgcca
MD5: B3:A5:3E:77:21:6D:AC:4A:C0:C9:FB:D5:41:3D:CA:06
SHA1: 58:11:9F:0E:12:82:87:EA:50:FD:D9:87:45:6F:4F:78:DC:FA:D6:D4
SHA256:
85:FB:2F:91:DD:12:27:5A:01:45:B6:36:53:4F:84:02:4A:D6:8B:69:B8:EE:88:68:4F:F7:11:37:58:05:B3:48
MD5: 88:2C:8C:52:B8:A2:3C:F3:F7:BB:03:EA:AE:AC:42:0B
SHA1: 74:20:74:41:72:9C:DD:92:EC:79:31:D8:23:10:8D:C2:81:92:E2:BB
SHA256:
0F:99:3C:8A:EF:97:BA:AF:56:87:14:0E:D5:9A:D1:82:1B:B4:AF:AC:F0:AA:9A:58:B5:D5:7A:33:8A:3A:FB:CB
Alias name: digicertglobalrootca
MD5: 79:E4:A9:84:0D:7D:3A:96:D7:C0:4F:E2:43:4C:89:2E
SHA1: A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
SHA256:
43:48:A0:E9:44:4C:78:CB:26:5E:05:8D:5E:89:44:B4:D8:4F:96:62:BD:26:DB:25:7F:89:34:A4:43:C7:01:61
MD5: 3D:41:29:CB:1E:AA:11:74:CD:5D:B0:62:AF:B0:43:5B
SHA1: DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34
SHA256:
E6:09:07:84:65:A4:19:78:0C:B6:AC:4C:1C:0B:FB:46:53:D9:D9:CC:6E:B3:94:6E:B7:F3:D6:99:97:BA:D5:98
MD5: 37:41:49:1B:18:56:9A:26:F5:AD:C2:66:FB:40:A5:4C
SHA1: 43:13:BB:96:F1:D5:86:9B:C1:4E:6A:92:F6:CF:F6:34:69:87:82:37
SHA256:
DD:69:36:FE:21:F8:F0:77:C1:23:A1:A5:21:C1:22:24:F7:22:55:B7:3E:03:A7:26:06:93:E8:A2:4B:0F:A3:89
Alias name: utnuserfirstclientauthemailca
MD5: D7:34:3D:EF:1D:27:09:28:E1:31:02:5B:13:2B:DD:F7
SHA1: B1:72:B1:A5:6D:95:F9:1F:E5:02:87:E1:4D:37:EA:6A:44:63:76:8A
261
SHA256:
43:F2:57:41:2D:44:0D:62:74:76:97:4F:87:7D:A8:F1:FC:24:44:56:5A:36:7A:E6:0E:DD:C2:7A:41:25:31:AE
Alias name: verisignc2g1.pem
MD5: B3:9C:25:B1:C3:2E:32:53:80:15:30:9D:4D:02:77:3E
SHA1: 67:82:AA:E0:ED:EE:E2:1A:58:39:D3:C0:CD:14:68:0A:4F:60:14:2A
SHA256:
BD:46:9F:F4:5F:AA:E7:C5:4C:CB:D6:9D:3F:3B:00:22:55:D9:B0:6B:10:B1:D0:FA:38:8B:F9:6B:91:8B:2C:E9
MD5: 74:9D:EA:60:24:C4:FD:22:53:3E:CC:3A:72:D9:29:4F
SHA1: AA:DB:BC:22:23:8F:C4:01:A1:27:BB:38:DD:F4:1D:DB:08:9E:F0:12
SHA256:
A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57
MD5: DF:F2:80:73:CC:F1:E6:61:73:FC:F5:42:E9:C5:7C:EE
SHA1: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39
SHA256:
62:F2:40:27:8C:56:4C:4D:D8:BF:7D:9D:4F:6F:36:6E:A8:94:D2:2F:5F:34:D9:89:A9:83:AC:EC:2F:FF:ED:50
MD5: 94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
SHA1: 75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
MD5: EF:5A:F1:33:EF:F1:CD:BB:51:02:EE:12:14:4B:96:C4
SHA1: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
SHA256:
A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
MD5: 72:E4:4A:87:E3:69:40:80:77:EA:BC:E3:F4:FF:F0:E1
SHA1: 5F:43:E5:B1:BF:F8:78:8C:AC:1C:C7:CA:4A:9A:C6:22:2B:CC:34:C6
SHA256:
96:0A:DF:00:63:E9:63:56:75:0C:29:65:DD:0A:08:67:DA:0B:9C:BD:6E:77:71:4A:EA:FB:23:49:AB:39:3D:A3
MD5: 3E:45:52:15:09:51:92:E1:B7:5D:37:9F:B1:87:29:8A
SHA1: B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
SHA256:
EB:D4:10:40:E4:BB:3E:C7:42:C9:E3:81:D3:1E:F2:A4:1A:48:B6:68:5C:96:E7:CE:F3:C1:DF:6C:D4:33:1C:99
MD5: 3D:3B:18:9E:2C:64:5A:E8:D5:88:CE:0E:F9:37:C2:EC
SHA1: DA:FA:F7:FA:66:84:EC:06:8F:14:50:BD:C7:C2:81:A5:BC:A9:64:57
SHA256:
ED:F7:EB:BC:A2:7A:2A:38:4D:38:7B:7D:40:10:C6:66:E2:ED:B4:84:3E:4C:29:B4:AE:1D:5B:93:32:E6:B2:4D
Alias name: keynectisrootca
MD5: CC:4D:AE:FB:30:6B:D8:38:FE:50:EB:86:61:4B:D2:26
SHA1: 9C:61:5C:4D:4D:85:10:3A:53:26:C2:4D:BA:EA:E4:A2:D2:D5:CC:97
SHA256:
42:10:F1:99:49:9A:9A:C3:3C:8D:E0:2B:A6:DB:AA:14:40:8B:DD:8A:6E:32:46:89:C1:92:2D:06:97:15:A3:32
MD5: A9:23:75:9B:BA:49:36:6E:31:C2:DB:F2:E7:66:BA:87
SHA1: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6
SHA256:
58:D0:17:27:9C:D4:DC:63:AB:DD:B1:96:A6:C9:90:6C:30:C4:E0:87:83:EA:E8:C1:60:99:54:D6:93:55:59:6B
Alias name: equifaxsecureglobalebusinessca1
MD5: 51:F0:2A:33:F1:F5:55:39:07:F2:16:7A:47:C7:5D:63
SHA1: 3A:74:CB:7A:47:DB:70:DE:89:1F:24:35:98:64:B8:2D:82:BD:1A:36
SHA256:
86:AB:5A:65:71:D3:32:9A:BC:D2:E4:E6:37:66:8B:A8:9C:73:1E:C2:93:B6:CB:A6:0F:71:63:40:A0:91:CE:AE
Alias name: affirmtrustpremiumca
MD5: C4:5D:0E:48:B6:AC:28:30:4E:0A:BC:F9:38:16:87:57
SHA1: D8:A6:33:2C:E0:03:6F:B1:85:F6:63:4F:7D:6A:06:65:26:32:28:27
SHA256:
70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A
Alias name: baltimorecodesigningca
MD5: 90:F5:28:49:56:D1:5D:2C:B0:53:D4:4B:EF:6F:90:22
SHA1: 30:46:D8:C8:88:FF:69:30:C3:4A:FC:CD:49:27:08:7C:60:56:7B:0D
262
SHA256:
A9:15:45:DB:D2:E1:9C:4C:CD:F9:09:AA:71:90:0D:18:C7:35:1C:89:B3:15:F0:F1:3D:05:C1:3A:8F:FB:46:87
MD5: 22:2D:A6:01:EA:7C:0A:F7:F0:6C:56:43:3F:77:76:D3
SHA1: FE:B8:C4:32:DC:F9:76:9A:CE:AE:3D:D8:90:8F:FD:28:86:65:64:7D
SHA256:
A2:2D:BA:68:1E:97:37:6E:2D:39:7D:72:8A:AE:3A:9B:62:96:B9:FD:BA:60:BC:2E:11:F6:47:F2:C6:75:FB:37
MD5: CA:3D:D3:68:F1:03:5C:D0:32:FA:B8:2B:59:E8:5A:DB
SHA1: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74
SHA256:
A5:31:25:18:8D:21:10:AA:96:4B:02:C7:B7:C6:DA:32:03:17:08:94:E5:FB:71:FF:FB:66:67:D5:E6:81:0A:36
MD5: 49:63:AE:27:F4:D5:95:3D:D8:DB:24:86:B8:9C:07:53
SHA1: D3:C0:63:F2:19:ED:07:3E:34:AD:5D:75:0B:32:76:29:FF:D5:9A:F2
SHA256:
79:3C:BF:45:59:B9:FD:E3:8A:B2:2D:F1:68:69:F6:98:81:AE:14:C4:B0:13:9A:C7:88:A7:8A:1A:FC:CA:02:FB
MD5: 65:58:AB:15:AD:57:6C:1E:A8:A7:B5:69:AC:BF:FF:EB
SHA1: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E
SHA256:
F4:C1:49:55:1A:30:13:A3:5B:C7:BF:FE:17:A7:F3:44:9B:C1:AB:5B:5A:0A:E7:4B:06:C2:3B:90:00:4C:01:04
MD5: 4C:56:41:E5:0D:BB:2B:E8:CA:A3:ED:18:08:AD:43:39
SHA1: 04:83:ED:33:99:AC:36:08:05:87:22:ED:BC:5E:46:00:E3:BE:F9:D7
SHA256:
6E:A5:47:41:D0:04:66:7E:ED:1B:48:16:63:4A:A3:A7:9E:6E:4B:96:95:0F:82:79:DA:FC:8D:9B:D8:81:21:37
MD5: 02:26:C3:01:5E:08:30:37:43:A9:D0:7D:CF:37:E6:BF
SHA1: 32:3C:11:8E:1B:F7:B8:B6:52:54:E2:E2:10:0D:D6:02:90:37:F0:96
SHA256:
37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C
MD5: 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62
SHA1: 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77:AF:55:6F
SHA256:
D1:7C:D8:EC:D5:86:B7:12:23:8A:48:2C:E4:6F:A5:29:39:70:74:2F:27:6D:8A:B6:A9:E4:6E:E0:28:8F:33:55
MD5: 32:4A:4B:BB:C8:63:69:9B:BE:74:9A:C6:DD:1D:46:24
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256:
14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
MD5: D6:39:81:C6:52:7E:96:69:FC:FC:CA:66:ED:05:F2:96
SHA1: B5:1C:06:7C:EE:2B:0C:3D:F8:55:AB:2D:92:F4:FE:39:D4:E7:0F:0E
SHA256:
2C:E1:CB:0B:F9:D2:F9:E1:02:99:3F:BE:21:51:52:C3:B2:DD:0C:AB:DE:1C:68:E5:31:9B:83:91:54:DB:B7:F5
MD5: D3:D9:BD:AE:9F:AC:67:24:B3:C8:1B:52:E1:B9:A9:BD
SHA1: 4A:65:D5:F4:1D:EF:39:B8:B8:90:4A:4A:D3:64:81:33:CF:C7:A1:D1
SHA256:
BD:81:CE:3B:4F:65:91:D1:1A:67:B5:FC:7A:47:FD:EF:25:52:1B:F9:AA:4E:18:B9:E3:DF:2E:34:A7:80:3B:E8
Alias name: swisssignsilverg2ca
MD5: E0:06:A1:C9:7D:CF:C9:FC:0D:C0:56:75:96:D8:62:13
SHA1: 9B:AA:E5:9F:56:EE:21:CB:43:5A:BE:25:93:DF:A7:F0:40:D1:1D:CB
SHA256:
BE:6C:4D:A2:BB:B9:BA:59:B6:F3:93:97:68:37:42:46:C3:C0:05:99:3F:A9:8F:02:0D:1D:ED:BE:D4:8A:81:D5
MD5: 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
SHA1: 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
SHA256:
3E:90:99:B5:01:5E:8F:48:6C:00:BC:EA:9D:11:1E:E7:21:FA:BA:35:5A:89:BC:F1:DF:69:56:1E:3D:C6:32:5C
MD5: D3:F3:A6:16:C0:FA:6B:1D:59:B1:2D:96:4D:0E:11:2E
SHA1: 74:F8:A3:C3:EF:E7:B3:90:06:4B:83:90:3C:21:64:60:20:E5:DF:CE
263
SHA256:
15:F0:BA:00:A3:AC:7A:F3:AC:88:4C:07:2B:10:11:A0:77:BD:77:C0:97:F4:01:64:B2:F8:59:8A:BD:83:86:0C
SHA1: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
SHA256:
MD5: 77:0D:19:B1:21:FD:00:42:9C:3E:0C:A5:DD:0B:02:8E
SHA1: 25:01:90:19:CF:FB:D9:99:1C:B7:68:25:74:8D:94:5F:30:93:95:42
SHA256:
AF:8B:67:62:A1:E5:28:22:81:61:A9:5D:5C:55:9E:E2:66:27:8F:75:D7:9E:83:01:89:A5:03:50:6A:BD:6B:4C
Alias name: securetrustca
MD5: DC:32:C3:A7:6D:25:57:C7:68:09:9D:EA:2D:A9:A2:D1
SHA1: 87:82:C6:C3:04:35:3B:CF:D2:96:92:D2:59:3E:7D:44:D9:34:FF:11
SHA256:
F1:C1:B5:0A:E5:A2:0D:D8:03:0E:C9:F6:BC:24:82:3D:D3:67:B5:25:57:59:B4:E7:1B:61:FC:E9:F7:37:5D:73
Alias name: soneraclass1ca
MD5: 33:B7:84:F5:5F:27:D7:68:27:DE:14:DE:12:2A:ED:6F
SHA1: 07:47:22:01:99:CE:74:B9:7C:B0:3D:79:B2:64:A2:C8:55:E9:33:FF
SHA256:
CD:80:82:84:CF:74:6F:F2:FD:6E:B5:8A:A1:D5:9C:4A:D4:B3:CA:56:FD:C6:27:4A:89:26:A7:83:5F:32:31:3D
MD5: F1:6A:22:18:C9:CD:DF:CE:82:1D:1D:B7:78:5C:A9:A5
SHA1: 79:98:A3:08:E1:4D:65:85:E6:C2:1E:15:3A:71:9F:BA:5A:D3:4A:D9
SHA256:
44:04:E3:3B:5E:14:0D:CF:99:80:51:FD:FC:80:28:C7:C8:16:15:C5:EE:73:7B:11:1B:58:82:33:A9:B5:35:A0
MD5: 18:98:C0:D6:E9:3A:FC:F9:B0:F5:0C:F7:4B:01:44:17
SHA1: FA:B7:EE:36:97:26:62:FB:2D:B0:2A:F6:BF:03:FD:E8:7C:4B:2F:9B
SHA256:
EA:A9:62:C4:FA:4A:6B:AF:EB:E4:15:19:6D:35:1C:CD:88:8D:4F:53:F3:FA:8A:E6:D7:C4:66:A9:4E:60:42:BB
MD5: A6:B0:CD:85:80:DA:5C:50:34:A3:39:90:2F:55:67:73
SHA1: 2F:78:3D:25:52:18:A7:4A:65:39:71:B5:2C:A2:9C:45:15:6F:E9:19
SHA256:
25:30:CC:8E:98:32:15:02:BA:D9:6F:9B:1F:BA:1B:09:9E:2D:29:9E:0F:45:48:BB:91:4F:36:3B:C0:D4:53:1F
MD5: 2B:9B:9E:E4:7B:6C:1F:00:72:1A:CC:C1:77:79:DF:6A
SHA1: 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:17:D8:94:E9
SHA256:
91:E2:F5:78:8D:58:10:EB:A7:BA:58:73:7D:E1:54:8A:8E:CA:CD:01:45:98:BC:0B:14:3E:04:1B:17:05:25:52
MD5: CB:17:E4:31:67:3E:E2:09:FE:45:57:93:F3:0A:FA:1C
SHA1: 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
SHA256:
9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99:89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF
Alias name: utnuserfirsthardwareca
MD5: 4C:56:41:E5:0D:BB:2B:E8:CA:A3:ED:18:08:AD:43:39
SHA1: 04:83:ED:33:99:AC:36:08:05:87:22:ED:BC:5E:46:00:E3:BE:F9:D7
SHA256:
6E:A5:47:41:D0:04:66:7E:ED:1B:48:16:63:4A:A3:A7:9E:6E:4B:96:95:0F:82:79:DA:FC:8D:9B:D8:81:21:37
Alias name: addtrustqualifiedca
MD5: 27:EC:39:47:CD:DA:5A:AF:E2:9A:01:65:21:A9:4C:BB
SHA1: 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:C5:4D:8B:CF
SHA256:
80:95:21:08:05:DB:4B:BC:35:5E:44:28:D8:FD:6E:C2:CD:E3:AB:5F:B9:7A:99:42:98:8E:B8:F4:DC:D0:60:16
MD5: 56:5F:AA:80:61:12:17:F6:67:21:E6:2B:6D:61:56:8E
SHA1: 80:25:EF:F4:6E:70:C8:D4:72:24:65:84:FE:40:3B:8A:8D:6A:DB:F5
SHA256:
8D:A0:84:FC:F9:9C:E0:77:22:F8:9B:32:05:93:98:06:FA:5C:B8:11:E1:C8:13:F6:A1:08:C7:D3:36:B3:40:8E
MD5: 01:5E:D8:6B:BD:6F:3D:8E:A1:31:F8:12:E0:98:73:6A
SHA1: 8D:17:84:D5:37:F3:03:7D:EC:70:FE:57:8B:51:9A:99:E6:10:D7:B0
264
SHA256:
5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66
MD5: CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
SHA256:
MD5: 55:5D:63:00:97:BD:6A:97:F5:67:AB:4B:FB:6E:63:15
SHA1: 4F:99:AA:93:FB:2B:D1:37:26:A1:99:4A:CE:7F:F0:05:F2:93:5D:1E
SHA256:
1C:01:C6:F4:DB:B2:FE:FC:22:55:8B:2B:CA:32:56:3F:49:84:4A:CF:C3:2B:7B:E4:B0:FF:59:9F:9E:8C:7A:F7
MD5: 30:C9:E7:1E:6B:E6:14:EB:65:B2:16:69:20:31:67:4D
SHA1: 3B:C0:38:0B:33:C3:F6:A6:0C:86:15:22:93:D9:DF:F5:4B:81:C0:04
SHA256:
C1:B4:82:99:AB:A5:20:8F:E9:63:0A:CE:55:CA:68:A0:3E:DA:5A:51:9C:88:02:A0:D3:A6:73:BE:8F:8E:55:7D
Alias name: thawtepersonalfreemailca
MD5: 53:4B:1D:17:58:58:1A:30:A1:90:F8:6E:5C:F2:CF:65
SHA1: E6:18:83:AE:84:CA:C1:C1:CD:52:AD:E8:E9:25:2B:45:A6:4F:B7:E2
SHA256:
5B:38:BD:12:9E:83:D5:A0:CA:D2:39:21:08:94:90:D5:0D:4A:AE:37:04:28:F8:DD:FF:FF:FA:4C:15:64:E1:84
Alias name: certplusclass3pprimaryca
MD5: E1:4B:52:73:D7:1B:DB:93:30:E5:BD:E4:09:6E:BE:FB
SHA1: 21:6B:2A:29:E6:2A:00:CE:82:01:46:D8:24:41:41:B9:25:11:B2:79
SHA256:
CC:C8:94:89:37:1B:AD:11:1C:90:61:9B:EA:24:0A:2E:6D:AD:D9:9F:9F:6E:1D:4D:41:E5:8E:D6:DE:3D:02:85
MD5: 3A:52:E1:E7:FD:6F:3A:E3:6F:F3:6F:99:1B:F9:22:41
SHA1: 22:D5:D8:DF:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A
SHA256:
69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60:32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79
Alias name: swisssigngoldg2ca
MD5: 24:77:D9:A8:91:D1:3B:FA:88:2D:C2:FF:F8:CD:33:93
SHA1: D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61
SHA256:
62:DD:0B:E9:B9:F5:0A:16:3E:A0:F8:E7:5C:05:3B:1E:CA:57:EA:55:C8:68:8F:64:7C:68:81:F2:C8:35:7B:95
MD5: ED:41:F5:8C:50:C5:2B:9C:73:E6:EE:6C:EB:C2:A8:26
SHA1: 1B:4B:39:61:26:27:6B:64:91:A2:68:6D:D7:02:43:21:2D:1F:1D:96
SHA256:
E4:C7:34:30:D7:A5:B5:09:25:DF:43:37:0A:0D:21:6E:9A:79:B9:D6:DB:83:73:A0:C6:9E:B1:CC:31:C7:C5:2A
MD5: 64:B0:09:55:CF:B1:D5:99:E2:BE:13:AB:A6:5D:EA:4D
SHA1: B8:23:6B:00:2F:1D:16:86:53:01:55:6C:11:A4:37:CA:EB:FF:C3:BB
SHA256:
BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23
MD5: 43:5E:88:D4:7D:1A:4A:7E:FD:84:2E:52:EB:01:D4:6F
SHA1: C9:A8:B9:E7:55:80:5E:58:E3:53:77:A7:25:EB:AF:C3:7B:27:CC:D7
SHA256:
3E:84:BA:43:42:90:85:16:E7:75:73:C0:99:2F:09:79:CA:08:4E:46:85:68:1F:F1:95:CC:BA:8A:22:9B:8A:76
MD5: A3:EC:75:0F:2E:88:DF:FA:48:01:4E:0B:5C:48:6F:FB
SHA1: 37:F7:6D:E6:07:7C:90:C5:B1:3E:93:1A:B7:41:10:B4:F2:E4:9A:27
SHA256:
79:08:B4:03:14:C1:38:10:0B:51:8D:07:35:80:7F:FB:FC:F8:51:8A:00:95:33:71:05:BA:38:6B:15:3D:D9:27
Alias name: starfieldclass2ca
MD5: 32:4A:4B:BB:C8:63:69:9B:BE:74:9A:C6:DD:1D:46:24
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256:
14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
MD5: F0:96:B6:2F:C5:10:D5:67:8E:83:25:32:E8:5E:2E:E5
SHA1: 23:88:C9:D3:71:CC:9E:96:3D:FF:7D:3C:A7:CE:FC:D6:25:EC:19:0D
265
SHA256:
32:7A:3D:76:1A:BA:DE:A0:34:EB:99:84:06:27:5C:B1:A4:77:6E:FD:AE:2F:DF:6D:01:68:EA:1C:4F:55:67:D0
MD5: 39:16:AA:B9:6A:41:E1:14:69:DF:9E:6C:3B:72:DC:B6
SHA1: 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF
SHA256:
39:DF:7B:68:2B:7B:93:8F:84:71:54:81:CC:DE:8D:60:D8:F2:2E:C5:98:87:7D:0A:AA:C1:2B:59:18:2B:03:12
Alias name: globalsignr2ca
MD5: 94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
SHA1: 75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
MD5: 6C:39:7D:A4:0E:55:59:B2:3F:D6:41:B1:12:50:DE:43
SHA1: 5F:3B:8C:F2:F8:10:B3:7D:78:B4:CE:EC:19:19:C3:73:34:B9:C7:74
SHA256:
51:3B:2C:EC:B8:10:D4:CD:E5:DD:85:39:1A:DF:C6:C2:DD:60:D8:7B:B7:36:D2:B5:21:48:4A:A4:7A:0E:BE:F6
MD5: D6:ED:3C:CA:E2:66:0F:AF:10:43:0D:77:9B:04:09:BF
SHA1: 85:B5:FF:67:9B:0C:79:96:1F:C8:6E:44:22:00:46:13:DB:17:92:84
SHA256:
7D:3B:46:5A:60:14:E5:26:C0:AF:FC:EE:21:27:D2:31:17:27:AD:81:1C:26:84:2D:00:6A:F3:73:06:CC:80:BD
MD5: CB:17:E4:31:67:3E:E2:09:FE:45:57:93:F3:0A:FA:1C
SHA256:
MD5: DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83
SHA1: 27:3E:E1:24:57:FD:C4:F9:0C:55:E8:2B:56:16:7F:62:F5:32:E5:47
SHA256:
34:1D:E9:8B:13:92:AB:F7:F4:AB:90:A9:60:CF:25:D4:BD:6E:C6:5B:9A:51:CE:6E:D0:67:D0:0E:C7:CE:9B:7F
MD5: 82:92:BA:5B:EF:CD:8A:6F:A6:3D:55:F9:84:F6:D6:B7
SHA1: F9:B5:B6:32:45:5F:9C:BE:EC:57:5F:80:DC:E9:6E:2C:C7:B2:78:B7
SHA256:
03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7
MD5: 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F
SHA1: 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
SHA256:
68:7F:A4:51:38:22:78:FF:F0:C8:B1:1F:8D:43:D5:76:67:1C:6E:B2:BC:EA:B4:13:FB:83:D9:65:D0:6D:2F:F2
MD5: D4:74:DE:57:5C:39:B2:D3:9C:85:83:C5:C0:65:49:8A
SHA1: 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25
SHA256:
74:31:E5:F4:C3:C1:CE:46:90:77:4F:0B:61:E0:54:40:88:3B:A9:A0:1E:D0:0B:A6:AB:D7:80:6E:D3:B1:18:CF
Alias name: equifaxsecureca
MD5: 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
SHA1: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A
SHA256:
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78
MD5: A2:6F:53:B7:EE:40:DB:4A:68:E7:FA:18:D9:10:4B:72
SHA1: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB
SHA256:
BC:23:F9:8A:31:3C:B9:2D:E3:BB:FC:3A:5A:9F:44:61:AC:39:49:4C:4A:E1:5A:9E:9D:F1:31:E9:9B:73:01:9A
MD5: F9:03:7E:CF:E6:9E:3C:73:7A:2A:90:07:69:FF:2B:96
SHA1: 9C:BB:48:53:F6:A4:F6:D3:52:A4:E8:32:52:55:60:13:F5:AD:AF:65
SHA256:
59:76:90:07:F7:68:5D:0F:CD:50:87:2F:9F:95:D5:75:5A:5B:2B:45:7D:81:F3:69:2B:61:0A:98:67:2F:0E:1B
Alias name: certumtrustednetworkca
MD5: D5:E9:81:40:C5:18:69:FC:46:2C:89:75:62:0F:AA:78
SHA1: 07:E0:32:E0:20:B7:2C:3F:19:2F:06:28:A2:59:3A:19:A7:0F:06:9E
266
SHA256:
5C:58:46:8D:55:F5:8E:49:7E:74:39:82:D2:B5:00:10:B6:D1:65:37:4A:CF:83:A7:D4:A3:2D:B7:68:C4:40:8E
MD5: 92:65:58:8B:A2:1A:31:72:73:68:5C:B4:A5:7A:07:48
SHA1: E6:21:F3:35:43:79:05:9A:4B:68:30:9D:8A:2F:74:22:15:87:EC:79
SHA256:
A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12
MD5: B5:E8:34:36:C9:10:44:58:48:70:6D:2E:83:D4:B8:05
SHA1: 03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
SHA256:
B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4
MD5: CD:E0:25:69:8D:47:AC:9C:89:35:90:F7:FD:51:3D:2F
SHA1: 58:E8:AB:B0:36:15:33:FB:80:F7:9B:1B:6D:29:D3:FF:8D:5F:00:F0
SHA256:
49:E7:A4:42:AC:F0:EA:62:87:05:00:54:B5:25:64:B6:50:E4:F4:9E:42:E3:48:D6:AA:38:E0:39:E9:57:B1:C1
MD5: 8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC
SHA1: 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45
SHA256:
5F:0B:62:EA:B5:E3:53:EA:65:21:65:16:58:FB:B6:53:59:F4:43:28:0A:4A:FB:D1:04:D7:7D:10:F9:F0:4C:07
Alias name: gd-class2-root.pem
MD5: 91:DE:06:25:AB:DA:FD:32:17:0C:BB:25:17:2A:84:67
SHA1: 27:96:BA:E6:3F:18:01:E2:77:26:1B:A0:D7:77:70:02:8F:20:EE:E4
SHA256:
C3:84:6B:F2:4B:9E:93:CA:64:27:4C:0E:C6:7C:1E:CC:5E:02:4F:FC:AC:D2:D7:40:19:35:0E:81:FE:54:6A:E4
MD5: 86:38:6D:5E:49:63:6C:85:5C:DB:6D:DC:94:B7:D0:F7
SHA1: AC:ED:5F:65:53:FD:25:CE:01:5F:1F:7A:48:3B:6A:74:9F:61:78:C6
SHA256:
7F:12:CD:5F:7E:5E:29:0E:C7:D8:51:79:D5:B7:2C:20:A5:BE:75:08:FF:DB:5B:F8:1A:B9:68:4A:7F:C9:F6:67
Alias name: thawteprimaryrootcag3
MD5: FB:1B:5D:43:8A:94:CD:44:C6:76:F2:43:4B:47:E7:31
SHA1: F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2
SHA256:
4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C
Alias name: quovadisrootca
MD5: 27:DE:36:FE:72:B7:00:03:00:9D:F4:F0:1E:6C:04:24
SHA1: DE:3F:40:BD:50:93:D3:9B:6C:60:F6:DA:BC:07:62:01:00:89:76:C9
SHA256:
A4:5E:DE:3B:BB:F0:9C:8A:E1:5C:72:EF:C0:72:68:D6:93:A2:1C:99:6F:D5:1E:67:CA:07:94:60:FD:6D:88:73
Alias name: thawteprimaryrootcag2
MD5: 74:9D:EA:60:24:C4:FD:22:53:3E:CC:3A:72:D9:29:4F
SHA1: AA:DB:BC:22:23:8F:C4:01:A1:27:BB:38:DD:F4:1D:DB:08:9E:F0:12
SHA256:
A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57
Alias name: deprecateditsecca
MD5: A5:96:0C:F6:B5:AB:27:E5:01:C6:00:88:9E:60:33:E5
SHA1: 12:12:0B:03:0E:15:14:54:F4:DD:B3:F5:DE:13:6E:83:5A:29:72:9D
SHA256:
9A:59:DA:86:24:1A:FD:BA:A3:39:FA:9C:FD:21:6A:0B:06:69:4D:E3:7E:37:52:6B:BE:63:C8:BC:83:74:2E:CB
Alias name: entrustrootcag2
MD5: 4B:E2:C9:91:96:65:0C:F4:0E:5A:93:92:A0:0A:FE:B2
SHA1: 8C:F4:27:FD:79:0C:3A:D1:66:06:8D:E8:1E:57:EF:BB:93:22:72:D4
SHA256:
43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39
MD5: 40:01:25:06:8D:21:43:6A:0E:43:00:9C:E7:43:F3:D5
SHA1: F9:CD:0E:2C:DA:76:24:C1:8F:BD:F0:F0:AB:B6:45:B8:F7:FE:D5:7A
SHA256:
50:79:41:C7:44:60:A0:B4:70:86:22:0D:4E:99:32:57:2A:B5:D1:B5:BB:CB:89:80:AB:1C:B1:76:51:A8:44:D2
MD5: BE:EC:11:93:9A:F5:69:21:BC:D7:C1:C0:67:89:CC:2A
SHA1: 8E:1C:74:F8:A6:20:B9:E5:8A:F4:61:FA:EC:2B:47:56:51:1A:52:C6
267
SHA256:
F9:6F:23:F4:C3:E7:9C:07:7A:46:98:8D:5A:F5:90:06:76:A0:F0:39:CB:64:5D:D1:75:49:B2:16:C8:24:40:CE
Alias name: trustcenterclass4caii
MD5: 9D:FB:F9:AC:ED:89:33:22:F4:28:48:83:25:23:5B:E0
SHA1: A6:9A:91:FD:05:7F:13:6A:42:63:0B:B1:76:0D:2D:51:12:0C:16:50
SHA256:
32:66:96:7E:59:CD:68:00:8D:9D:D3:20:81:11:85:C7:04:20:5E:8D:95:FD:D8:4F:1C:7B:31:1E:67:04:FC:32
MD5: 46:A7:D2:FE:45:FB:64:5A:A8:59:90:9B:78:44:9B:29
SHA1: 49:0A:75:74:DE:87:0A:47:FE:58:EE:F6:C7:6B:EB:C6:0B:12:40:99
SHA256:
9A:11:40:25:19:7C:5B:B9:5D:94:E6:3D:55:CD:43:79:08:47:B6:46:B2:3C:DF:11:AD:A4:A0:0E:FF:15:FB:48
MD5: 5E:39:7B:DD:F8:BA:EC:82:E9:AC:62:BA:0C:54:00:2B
SHA1: CA:3A:FB:CF:12:40:36:4B:44:B2:16:20:88:80:48:39:19:93:7C:F7
SHA256:
85:A0:DD:7D:D7:20:AD:B7:FF:05:F8:3D:54:2B:20:9D:C7:FF:45:28:F7:D6:77:B1:83:89:FE:A5:E5:C4:9E:86
Alias name: ttelesecglobalrootclass3ca
MD5: CA:FB:40:A8:4E:39:92:8A:1D:FE:8E:2F:C4:27:EA:EF
SHA1: 55:A6:72:3E:CB:F2:EC:CD:C3:23:74:70:19:9D:2A:BE:11:E3:81:D1
SHA256:
FD:73:DA:D3:1C:64:4F:F1:B4:3B:EF:0C:CD:DA:96:71:0B:9C:D9:87:5E:CA:7E:31:70:7A:F3:E9:6D:52:2B:BD
Alias name: amzninternalcorpca
MD5: 7B:0E:9D:67:A9:3A:88:DD:BA:81:8D:A9:3C:74:AA:BB
SHA1: 43:E3:E6:37:C5:88:05:67:91:37:E3:72:4D:01:7F:F4:1B:CE:3A:97
SHA256:
01:29:04:6C:60:EF:5C:51:60:D3:9F:A2:3A:1D:0C:52:0A:AF:DA:4F:17:87:95:AA:66:82:01:9F:76:C9:11:DC
Alias name: starfieldservicesrootg2ca
MD5: 17:35:74:AF:7B:61:1C:EB:F4:F9:3C:E2:EE:40:F9:A2
SHA1: 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:E8:25:6F:3F
SHA256:
56:8D:69:05:A2:C8:87:08:A4:B3:02:51:90:ED:CF:ED:B1:97:4A:60:6A:13:C6:E5:29:0F:CB:2A:E6:3E:DA:B5
MD5: 0C:7F:DD:6A:F4:2A:B9:C8:9B:BD:20:7E:A9:DB:5C:37
SHA1: 60:D6:89:74:B5:C2:65:9E:8A:0F:C1:88:7C:88:D2:46:69:1B:18:2C
SHA256:
B9:BE:A7:86:0A:96:2E:A3:61:1D:AB:97:AB:6D:A3:E2:1C:10:68:B9:7D:55:57:5E:D0:E1:12:79:C1:1C:89:32
MD5: 2C:8C:17:5E:B1:54:AB:93:17:B5:36:5A:DB:D1:C6:F2
SHA1: A0:73:E5:C5:BD:43:61:0D:86:4C:21:13:0A:85:58:57:CC:9C:EA:46
SHA256:
8C:4E:DF:D0:43:48:F3:22:96:9E:7E:29:A4:CD:4D:CA:00:46:55:06:1C:16:E1:B0:76:42:2E:F3:42:AD:63:0E
Alias name: verisignroot.pem
MD5: 8E:AD:B5:01:AA:4D:81:E4:8C:1D:D1:E1:14:00:95:19
SHA1: 36:79:CA:35:66:87:72:30:4D:30:A5:FB:87:3B:0F:A7:7B:B7:0D:54
SHA256:
23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C
MD5: B3:A5:3E:77:21:6D:AC:4A:C0:C9:FB:D5:41:3D:CA:06
SHA1: 58:11:9F:0E:12:82:87:EA:50:FD:D9:87:45:6F:4F:78:DC:FA:D6:D4
SHA256:
85:FB:2F:91:DD:12:27:5A:01:45:B6:36:53:4F:84:02:4A:D6:8B:69:B8:EE:88:68:4F:F7:11:37:58:05:B3:48
Alias name: camerfirmachambersca
MD5: 5E:80:9E:84:5A:0E:65:0B:17:02:F3:55:18:2A:3E:D7
SHA1: 78:6A:74:AC:76:AB:14:7F:9C:6A:30:50:BA:9E:A8:7E:FE:9A:CE:3C
SHA256:
06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0
MD5: E0:06:A1:C9:7D:CF:C9:FC:0D:C0:56:75:96:D8:62:13
SHA1: 9B:AA:E5:9F:56:EE:21:CB:43:5A:BE:25:93:DF:A7:F0:40:D1:1D:CB
SHA256:
BE:6C:4D:A2:BB:B9:BA:59:B6:F3:93:97:68:37:42:46:C3:C0:05:99:3F:A9:8F:02:0D:1D:ED:BE:D4:8A:81:D5
MD5: CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
SHA1: AE:50:83:ED:7C:F4:5C:BC:8F:61:C6:21:FE:68:5D:79:42:21:15:6E
268
SHA256:
E6:B8:F8:76:64:85:F8:07:AE:7F:8D:AC:16:70:46:1F:07:C0:A1:3E:EF:3A:1F:F7:17:53:8D:7A:BA:D3:91:B4
MD5: 91:DE:06:25:AB:DA:FD:32:17:0C:BB:25:17:2A:84:67
SHA256:
Alias name: verisignuniversalrootca
MD5: 8E:AD:B5:01:AA:4D:81:E4:8C:1D:D1:E1:14:00:95:19
SHA256:
MD5: 80:3A:BC:22:C1:E6:FB:8D:9B:3B:27:4A:32:1B:9A:01
SHA1: 47:BE:AB:C9:22:EA:E8:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8B
SHA256:
45:14:0B:32:47:EB:9C:C8:C5:B4:F0:D7:B5:30:91:F7:32:92:08:9E:6E:5A:63:E2:74:9D:D3:AC:A9:19:8E:DA
Alias name: geotrustuniversalca
MD5: 92:65:58:8B:A2:1A:31:72:73:68:5C:B4:A5:7A:07:48
SHA1: E6:21:F3:35:43:79:05:9A:4B:68:30:9D:8A:2F:74:22:15:87:EC:79
SHA256:
A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12
MD5: 49:79:04:B0:EB:87:19:AC:47:B0:BC:11:51:9B:74:D0
SHA1: D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
SHA256:
D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4
MD5: F8:38:7C:77:88:DF:2C:16:68:2E:C2:E2:52:4B:B8:F9
SHA1: 5F:3A:FC:0A:8B:64:F6:86:67:34:74:DF:7E:A9:A2:FE:F9:FA:7A:51
SHA256:
21:DB:20:12:36:60:BB:2E:D4:18:20:5D:A1:1E:E7:A8:5A:65:E2:BC:6E:55:B5:AF:7E:78:99:C8:A2:66:D9:2E
MD5: 5C:48:DC:F7:42:72:EC:56:94:6D:1C:CC:71:35:80:75
SHA1: 66:31:BF:9E:F7:4F:9E:B6:C9:D5:A6:0C:BA:6A:BE:D1:F7:BD:EF:7B
SHA256:
0C:2C:D6:3D:F7:80:6F:A3:99:ED:E8:09:11:6B:57:5B:F8:79:89:F0:65:18:F9:80:8C:86:05:03:17:8B:AF:66
Alias name: affirmtrustnetworkingca
MD5: 42:65:CA:BE:01:9A:9A:4C:A9:8C:41:49:CD:C0:D5:7F
SHA1: 29:36:21:02:8B:20:ED:02:F5:66:C5:32:D1:D6:ED:90:9F:45:00:2F
SHA256:
0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0:B4:1B
MD5: 42:81:A0:E2:1C:E3:55:10:DE:55:89:42:65:96:22:E6
SHA1: E0:B4:32:2E:B2:F6:A5:68:B6:54:53:84:48:18:4A:50:36:87:43:84
SHA256:
03:95:0F:B4:9A:53:1F:3E:19:91:94:23:98:DF:A9:E0:EA:32:D7:BA:1C:DD:9B:C8:5D:B5:7E:D9:40:0B:43:4A
MD5: C4:5D:0E:48:B6:AC:28:30:4E:0A:BC:F9:38:16:87:57
SHA1: D8:A6:33:2C:E0:03:6F:B1:85:F6:63:4F:7D:6A:06:65:26:32:28:27
SHA256:
70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A
Alias name: affirmtrustcommercialca
MD5: 82:92:BA:5B:EF:CD:8A:6F:A6:3D:55:F9:84:F6:D6:B7
SHA1: F9:B5:B6:32:45:5F:9C:BE:EC:57:5F:80:DC:E9:6E:2C:C7:B2:78:B7
SHA256:
03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7
MD5: D6:A5:C3:ED:5D:DD:3E:00:C1:3D:87:92:1F:1D:3F:E4
SHA1: B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9
SHA256:
73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C
MD5: 21:D8:4C:82:2B:99:09:33:A2:EB:14:24:8D:8E:5F:E8
SHA1: 40:54:DA:6F:1C:3F:40:74:AC:ED:0F:EC:CD:DB:79:D1:53:FB:90:1D
269
SHA256:
76:7C:95:5A:76:41:2C:89:AF:68:8E:90:A1:C7:0F:55:6C:FD:6B:60:25:DB:EA:10:41:6D:7E:B6:83:1F:8C:40
MD5: 2C:20:26:9D:CB:1A:4A:00:85:B5:B7:5A:AE:C2:01:37
SHA1: 8C:96:BA:EB:DD:2B:07:07:48:EE:30:32:66:A0:F3:98:6E:7C:AE:58
SHA256:
35:AE:5B:DD:D8:F7:AE:63:5C:FF:BA:56:82:A8:F0:0B:95:F4:84:62:C7:10:8E:E9:A0:E5:29:2B:07:4A:AF:B2
MD5: 73:3A:74:7A:EC:BB:A3:96:A6:C2:E4:E2:C8:9B:C0:C3
SHA1: AE:C5:FB:3F:C8:E1:BF:C4:E5:4F:03:07:5A:9A:E8:00:B7:F7:B6:FA
SHA256:
04:04:80:28:BF:1F:28:64:D4:8F:9A:D4:D8:32:94:36:6A:82:88:56:55:3F:3B:14:30:3F:90:14:7F:5D:40:EF
Alias name: starfieldrootg2ca
MD5: D6:39:81:C6:52:7E:96:69:FC:FC:CA:66:ED:05:F2:96
SHA1: B5:1C:06:7C:EE:2B:0C:3D:F8:55:AB:2D:92:F4:FE:39:D4:E7:0F:0E
SHA256:
2C:E1:CB:0B:F9:D2:F9:E1:02:99:3F:BE:21:51:52:C3:B2:DD:0C:AB:DE:1C:68:E5:31:9B:83:91:54:DB:B7:F5
MD5: B8:A1:03:63:B0:BD:21:71:70:8A:6F:13:3A:BB:79:49
SHA1: 51:C6:E7:08:49:06:6E:F3:92:D4:5C:A0:0D:6D:A3:62:8F:C3:52:39
SHA256:
B0:BF:D5:2B:B0:D7:D9:BD:92:BF:5D:4D:C1:3D:A2:55:C0:2C:54:2F:37:83:65:EA:89:39:11:F5:5E:55:F2:3C
Alias name: buypassclass3ca
MD5: 3D:3B:18:9E:2C:64:5A:E8:D5:88:CE:0E:F9:37:C2:EC
SHA1: DA:FA:F7:FA:66:84:EC:06:8F:14:50:BD:C7:C2:81:A5:BC:A9:64:57
SHA256:
ED:F7:EB:BC:A2:7A:2A:38:4D:38:7B:7D:40:10:C6:66:E2:ED:B4:84:3E:4C:29:B4:AE:1D:5B:93:32:E6:B2:4D
MD5: A8:0D:6F:39:78:B9:43:6D:77:42:6D:98:5A:CC:23:CA
SHA1: D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
SHA256:
F9:E6:7D:33:6C:51:00:2A:C0:54:C6:32:02:2D:66:DD:A2:E7:E3:FF:F1:0A:D0:61:ED:31:D8:BB:B4:10:CF:B2
MD5: F8:BE:C4:63:22:C9:A8:46:74:8B:B8:1D:1E:4A:2B:F6
SHA1: 61:EF:43:D7:7F:CA:D4:61:51:BC:98:E0:C3:59:12:AF:9F:EB:63:11
SHA256:
92:A9:D9:83:3F:E1:94:4D:B3:66:E8:BF:AE:7A:95:B6:48:0C:2D:6C:6C:2A:1B:E6:5D:42:36:B6:08:FC:A1:BB
MD5: F8:BE:C4:63:22:C9:A8:46:74:8B:B8:1D:1E:4A:2B:F6
SHA1: 61:EF:43:D7:7F:CA:D4:61:51:BC:98:E0:C3:59:12:AF:9F:EB:63:11
SHA256:
92:A9:D9:83:3F:E1:94:4D:B3:66:E8:BF:AE:7A:95:B6:48:0C:2D:6C:6C:2A:1B:E6:5D:42:36:B6:08:FC:A1:BB
MD5: E6:24:E9:12:01:AE:0C:DE:8E:85:C4:CE:A3:12:DD:EC
SHA1: 70:C1:8D:74:B4:28:81:0A:E4:FD:A5:75:D7:01:9F:99:B0:3D:50:74
SHA256:
3C:FC:3C:14:D1:F6:84:FF:17:E3:8C:43:CA:44:0C:00:B9:67:EC:93:3E:8B:FE:06:4C:A1:D7:2C:90:F2:AD:B0
MD5: 69:C1:0D:4F:07:A3:1B:C3:FE:56:3D:04:BC:11:F6:A6
SHA1: F3:73:B3:87:06:5A:28:84:8A:F2:F3:4A:CE:19:2B:DD:C7:8E:9C:AC
SHA256:
55:92:60:84:EC:96:3A:64:B9:6E:2A:BE:01:CE:0B:A8:6A:64:FB:FE:BC:C7:AA:B5:AF:C1:55:B3:7F:D7:60:66
MD5: CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
SHA256:
MD5: AA:8E:5D:D9:F8:DB:0A:58:B7:8D:26:87:6C:82:35:55
SHA1: 40:9D:4B:D9:17:B5:5C:27:B6:9B:64:CB:98:22:44:0D:CD:09:B8:89
SHA256:
EC:C3:E9:C3:40:75:03:BE:E0:91:AA:95:2F:41:34:8F:F8:8B:AA:86:3B:22:64:BE:FA:C8:07:90:15:74:E9:39
Alias name: godaddyclass2ca
MD5: 91:DE:06:25:AB:DA:FD:32:17:0C:BB:25:17:2A:84:67
270
SHA256:
MD5: DB:C8:F2:27:2E:B1:EA:6A:29:23:5D:FE:56:3E:33:DF
SHA1: C8:EC:8C:87:92:69:CB:4B:AB:39:E9:8D:7E:57:67:F3:14:95:73:9D
SHA256:
E3:89:36:0D:0F:DB:AE:B3:D2:50:58:4B:47:30:31:4E:22:2F:39:C1:56:A0:20:14:4E:8D:96:05:61:79:15:06
MD5: A2:33:9B:4C:74:78:73:D4:6C:E7:C1:F3:8D:CB:5C:E9
SHA1: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F
SHA256:
83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B
MD5: F1:BC:63:6A:54:E0:B5:27:F5:CD:E7:1A:E3:4D:6E:4A
SHA1: 36:B1:2B:49:F9:81:9E:D7:4C:9E:BC:38:0F:C6:56:8F:5D:AC:B2:F7
SHA256:
E7:5E:72:ED:9F:56:0E:EC:6E:B4:80:00:73:A4:3F:C3:AD:19:19:5A:39:22:82:01:78:95:97:4A:99:02:6B:6C
MD5: 3F:45:96:39:E2:50:87:F7:BB:FE:98:0C:3C:20:98:E6
SHA1: 2A:C8:D5:8B:57:CE:BF:2F:49:AF:F2:FC:76:8F:51:14:62:90:7A:41
SHA256:
92:BF:51:19:AB:EC:CA:D0:B1:33:2D:C4:E1:D0:5F:BA:75:B5:67:90:44:EE:0C:A2:6E:93:1F:74:4F:2F:33:CF
SHA256:
Alias name: utnuserfirstobjectca
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:2D:46
SHA256:
6F:FF:78:E4:00:A7:0C:11:01:1C:D8:59:77:C4:59:FB:5A:F9:6A:3D:F0:54:08:20:D0:F4:B8:60:78:75:E5:8F
MD5: 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67
SHA1: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
SHA256:
E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
MD5: 14:F1:08:AD:9D:FA:64:E2:89:E7:1C:CF:A8:AD:7D:5E
SHA1: 39:21:C1:15:C1:5D:0E:CA:5C:CB:5B:C4:F0:7D:21:D8:05:0B:56:6A
SHA256:
77:40:73:12:C6:3A:15:3D:5B:C0:0B:4E:51:75:9C:DF:DA:C2:37:DC:2A:33:B6:79:46:E9:8E:9B:FA:68:0A:E3
Alias name: addtrustclass1ca
MD5: 1E:42:95:02:33:92:6B:B9:5F:C0:7F:DA:D6:B2:4B:FC
SHA1: CC:AB:0E:A0:4C:23:01:D6:69:7B:DD:37:9F:CD:12:EB:24:E3:94:9D
SHA256:
8C:72:09:27:9A:C0:4E:27:5E:16:D0:7F:D3:B7:75:E8:01:54:B5:96:80:46:E3:1F:52:DD:25:76:63:24:E9:A7
MD5: 7C:A5:0F:F8:5B:9A:7D:6D:30:AE:54:5A:E3:42:A2:8A
SHA1: 59:AF:82:79:91:86:C7:B4:75:07:CB:CF:03:57:46:EB:04:DD:B7:16
SHA256:
66:8C:83:94:7D:A6:3B:72:4B:EC:E1:74:3C:31:A0:E6:AE:D0:DB:8E:C5:B3:1B:E3:77:BB:78:4F:91:B6:71:6F
MD5: B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73
SHA1: 20:42:85:DC:F7:EB:76:41:95:57:8E:13:6B:D4:B7:D1:E9:8E:46:A5
SHA256:
CB:B5:AF:18:5E:94:2A:24:02:F9:EA:CB:C0:ED:5B:B8:76:EE:A3:C1:22:36:23:D0:04:47:E4:F3:BA:55:4B:65
MD5: 37:85:44:53:32:45:1F:20:F0:F3:95:E1:25:C4:43:4E
SHA1: F4:8B:11:BF:DE:AB:BE:94:54:20:71:E6:41:DE:6B:BE:88:2B:40:B9
SHA256:
76:00:29:5E:EF:E8:5B:9E:1F:D6:24:DB:76:06:2A:AA:AE:59:81:8A:54:D2:77:4C:D4:C0:B2:C0:11:31:E1:B3
Alias name: amzninternalrootca
MD5: 08:09:73:AC:E0:78:41:7C:0A:26:33:51:E8:CF:E6:60
SHA1: A7:B7:F6:15:8A:FF:1E:C8:85:13:38:BC:93:EB:A2:AB:A4:09:EF:06
271
SHA256:
0E:DE:63:C1:DC:7A:8E:11:F1:AB:BC:05:4F:59:EE:49:9D:62:9A:2F:DE:9C:A7:16:32:A2:64:29:3E:8B:66:AA
MD5: 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
SHA1: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A
SHA256:
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78
Alias name: entrustevca
MD5: D6:A5:C3:ED:5D:DD:3E:00:C1:3D:87:92:1F:1D:3F:E4
SHA1: B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9
SHA256:
73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C
Alias name: secomscrootca2
MD5: 6C:39:7D:A4:0E:55:59:B2:3F:D6:41:B1:12:50:DE:43
SHA1: 5F:3B:8C:F2:F8:10:B3:7D:78:B4:CE:EC:19:19:C3:73:34:B9:C7:74
SHA256:
51:3B:2C:EC:B8:10:D4:CD:E5:DD:85:39:1A:DF:C6:C2:DD:60:D8:7B:B7:36:D2:B5:21:48:4A:A4:7A:0E:BE:F6
Alias name: camerfirmachambersignca
MD5: 9E:80:FF:78:01:0C:2E:C1:36:BD:FE:96:90:6E:08:F3
SHA1: 4A:BD:EE:EC:95:0D:35:9C:89:AE:C7:52:A1:2C:5B:29:F6:D6:AA:0C
SHA256:
13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA
Alias name: secomscrootca1
MD5: F1:BC:63:6A:54:E0:B5:27:F5:CD:E7:1A:E3:4D:6E:4A
SHA1: 36:B1:2B:49:F9:81:9E:D7:4C:9E:BC:38:0F:C6:56:8F:5D:AC:B2:F7
SHA256:
E7:5E:72:ED:9F:56:0E:EC:6E:B4:80:00:73:A4:3F:C3:AD:19:19:5A:39:22:82:01:78:95:97:4A:99:02:6B:6C
MD5: 1E:42:95:02:33:92:6B:B9:5F:C0:7F:DA:D6:B2:4B:FC
SHA1: CC:AB:0E:A0:4C:23:01:D6:69:7B:DD:37:9F:CD:12:EB:24:E3:94:9D
SHA256:
8C:72:09:27:9A:C0:4E:27:5E:16:D0:7F:D3:B7:75:E8:01:54:B5:96:80:46:E3:1F:52:DD:25:76:63:24:E9:A7
MD5: 27:DE:36:FE:72:B7:00:03:00:9D:F4:F0:1E:6C:04:24
SHA1: DE:3F:40:BD:50:93:D3:9B:6C:60:F6:DA:BC:07:62:01:00:89:76:C9
SHA256:
A4:5E:DE:3B:BB:F0:9C:8A:E1:5C:72:EF:C0:72:68:D6:93:A2:1C:99:6F:D5:1E:67:CA:07:94:60:FD:6D:88:73
MD5: C5:A1:B7:FF:73:DD:D6:D7:34:32:18:DF:FC:3C:AD:88
SHA1: 06:08:3F:59:3F:15:A1:04:A0:69:A4:6B:A9:03:D0:06:B7:97:09:91
SHA256:
6C:61:DA:C3:A2:DE:F0:31:50:6B:E0:36:D2:A6:FE:40:19:94:FB:D1:3D:F9:C8:D4:66:59:92:74:C4:46:EC:98
MD5: 06:9F:69:79:16:66:90:02:1B:8C:8C:A2:C3:07:6F:3A
SHA1: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A
SHA256:
AB:70:36:36:5C:71:54:AA:29:C2:C2:9F:5D:41:91:16:3B:16:2A:22:25:01:13:57:D5:6D:07:FF:A7:BC:1F:72
MD5: D0:A0:5A:EE:05:B6:09:94:21:A1:7D:F1:B2:29:82:02
SHA1: 93:05:7A:88:15:C6:4F:CE:88:2F:FA:91:16:52:28:78:BC:53:64:17
SHA256:
9A:6E:C0:12:E1:A7:DA:9D:BE:34:19:4D:47:8A:D7:C0:DB:18:22:FB:07:1D:F1:29:81:49:6E:D1:04:38:41:13
MD5: 0E:40:A7:6C:DE:03:5D:8F:D1:0F:E4:D1:8D:F9:6C:A9
SHA1: A9:E9:78:08:14:37:58:88:F2:05:19:B0:6D:2B:0D:2B:60:16:90:7D
SHA256:
CA:2D:82:A0:86:77:07:2F:8A:B6:76:4F:F0:35:67:6C:FE:3E:5E:32:5E:01:21:72:DF:3F:92:09:6D:B7:9B:85
Alias name: entrust2048ca
MD5: EE:29:31:BC:32:7E:9A:E6:E8:B5:F7:51:B4:34:71:90
SHA1: 50:30:06:09:1D:97:D4:F5:AE:39:F7:CB:E7:92:7D:7D:65:2D:34:31
SHA256:
6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77
MD5: 7E:23:4E:5B:A7:A5:B4:25:E9:00:07:74:11:62:AE:D6
SHA1: 7F:8A:B0:CF:D0:51:87:6A:66:F3:36:0F:47:C8:8D:8C:D3:35:FC:74
272
SHA256:
2D:47:43:7D:E1:79:51:21:5A:12:F3:C5:8E:51:C7:29:A5:80:26:EF:1F:CC:0A:5F:B3:D9:DC:01:2F:60:0D:19
MD5: AC:B6:94:A5:9C:17:E0:D7:91:52:9B:B1:97:06:A6:E4
SHA1: D4:DE:20:D0:5E:66:FC:53:FE:1A:50:88:2C:78:DB:28:52:CA:E4:74
SHA256:
16:AF:57:A9:F6:76:B0:AB:12:60:95:AA:5E:BA:DE:F2:2A:B3:11:19:D6:44:AC:95:CD:4B:93:DB:F3:F2:6A:EB
MD5: C5:E6:7B:BF:06:D0:4F:43:ED:C4:7A:65:8A:FB:6B:19
SHA1: 33:9B:6B:14:50:24:9B:55:7A:01:87:72:84:D9:E0:2F:C3:D2:D8:E9
SHA256:
EF:3C:B4:17:FC:8E:BF:6F:97:87:6C:9E:4E:CE:39:DE:1E:A5:FE:64:91:41:D1:02:8B:7D:11:C0:B2:29:8C:ED
Alias name: thawteserverca
MD5: EE:FE:61:69:65:6E:F8:9C:C6:2A:F4:D7:2B:63:EF:A2
SHA1: 9F:AD:91:A6:CE:6A:C6:C5:00:47:C4:4E:C9:D4:A5:0D:92:D8:49:79
SHA256:
87:C6:78:BF:B8:B2:5F:38:F7:E9:7B:33:69:56:BB:CF:14:4B:BA:CA:A5:36:47:E6:1A:23:25:BC:10:55:31:6B
Alias name: secomvalicertclass1ca
MD5: 65:58:AB:15:AD:57:6C:1E:A8:A7:B5:69:AC:BF:FF:EB
SHA1: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E
SHA256:
F4:C1:49:55:1A:30:13:A3:5B:C7:BF:FE:17:A7:F3:44:9B:C1:AB:5B:5A:0A:E7:4B:06:C2:3B:90:00:4C:01:04
MD5: 74:01:4A:91:B1:08:C4:58:CE:47:CD:F0:DD:11:53:08
SHA1: 85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
SHA256:
B6:19:1A:50:D0:C3:97:7F:7D:A9:9B:CD:AA:C8:6A:22:7D:AE:B9:67:9E:C7:0B:A3:B0:C9:D9:22:71:C1:70:D3
MD5: 7D:0B:83:E5:FB:7C:AD:07:4F:20:A9:B5:DF:63:ED:79
SHA1: 40:B3:31:A0:E9:BF:E8:55:BC:39:93:CA:70:4F:4E:C2:51:D4:1D:8F
SHA256:
CB:62:7D:18:B5:8A:D5:6D:DE:33:1A:30:45:6B:C6:5C:60:1A:4E:9B:18:DE:DC:EA:08:E7:DA:AA:07:81:5F:F0
Alias name: godaddyrootg2ca
SHA256:
Alias name: gtecybertrustglobalca
MD5: CA:3D:D3:68:F1:03:5C:D0:32:FA:B8:2B:59:E8:5A:DB
SHA1: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74
SHA256:
A5:31:25:18:8D:21:10:AA:96:4B:02:C7:B7:C6:DA:32:03:17:08:94:E5:FB:71:FF:FB:66:67:D5:E6:81:0A:36
MD5: 7B:30:34:9F:DD:0A:4B:6B:35:CA:31:51:28:5D:AE:EC
SHA1: E7:A1:90:29:D3:D5:52:DC:0D:0F:C6:92:D3:EA:88:0D:15:2E:1A:6B
SHA256:
D9:5F:EA:3C:A4:EE:DC:E7:4C:D7:6E:75:FC:6D:1F:F6:2C:44:1F:0F:A8:BC:77:F0:34:B1:9E:5D:B2:58:01:5D
Alias name: equifaxsecureebusinessca1
MD5: 14:C0:08:E5:A3:85:03:A3:BE:78:E9:67:4F:27:CA:EE
SHA1: AE:E6:3D:70:E3:76:FB:C7:3A:EB:B0:A1:C1:D4:C4:7A:A7:40:B3:F4
SHA256:
2E:3A:2B:B5:11:25:05:83:6C:A8:96:8B:E2:CB:37:27:CE:9B:56:84:5C:6E:E9:8E:91:85:10:4A:FB:9A:F5:96
MD5: 78:4B:FB:9E:64:82:0A:D3:B8:4C:62:F3:64:F2:90:64
SHA1: 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
SHA256:
C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95
Alias name: quovadisrootca3
MD5: 31:85:3C:62:94:97:63:B9:AA:FD:89:4E:AF:6F:E0:CF
SHA1: 1F:49:14:F7:D8:74:95:1D:DD:AE:02:C0:BE:FD:3A:2D:82:75:51:85
SHA256:
18:F1:FC:7F:20:5D:F8:AD:DD:EB:7F:E0:07:DD:57:E3:AF:37:5A:9C:4D:8D:73:54:6B:F4:F1:FE:D1:E1:8D:35
Alias name: quovadisrootca2
MD5: 5E:39:7B:DD:F8:BA:EC:82:E9:AC:62:BA:0C:54:00:2B
SHA1: CA:3A:FB:CF:12:40:36:4B:44:B2:16:20:88:80:48:39:19:93:7C:F7
273
SHA256:
85:A0:DD:7D:D7:20:AD:B7:FF:05:F8:3D:54:2B:20:9D:C7:FF:45:28:F7:D6:77:B1:83:89:FE:A5:E5:C4:9E:86
Alias name: soneraclass2ca
MD5: A3:EC:75:0F:2E:88:DF:FA:48:01:4E:0B:5C:48:6F:FB
SHA1: 37:F7:6D:E6:07:7C:90:C5:B1:3E:93:1A:B7:41:10:B4:F2:E4:9A:27
SHA256:
79:08:B4:03:14:C1:38:10:0B:51:8D:07:35:80:7F:FB:FC:F8:51:8A:00:95:33:71:05:BA:38:6B:15:3D:D9:27
MD5: 7C:62:FF:74:9D:31:53:5E:68:4A:D5:78:AA:1E:BF:23
SHA1: 9F:74:4E:9F:2B:4D:BA:EC:0F:31:2C:50:B6:56:3B:8E:2D:93:C3:11
SHA256:
17:93:92:7A:06:14:54:97:89:AD:CE:2F:8F:34:F7:F0:B6:6D:0F:3A:E3:A3:B8:4D:21:EC:15:DB:BA:4F:AD:C7
MD5: DF:3C:73:59:81:E7:39:50:81:04:4C:34:A2:CB:B3:7B
SHA1: 61:57:3A:11:DF:0E:D8:7E:D5:92:65:22:EA:D0:56:D7:44:B3:23:71
SHA256:
B7:B1:2B:17:1F:82:1D:AA:99:0C:D0:FE:50:87:B1:28:44:8B:A8:E5:18:4F:84:C5:1E:02:B5:C8:FB:96:2B:24
MD5: 7F:30:78:8C:03:E3:CA:C9:0A:E2:C9:EA:1E:AA:55:1A
SHA1: 2E:14:DA:EC:28:F0:FA:1E:8E:38:9A:4E:AB:EB:26:C0:0A:D3:83:C3
SHA256:
FC:BF:E2:88:62:06:F7:2B:27:59:3C:8B:07:02:97:E1:2D:76:9E:D1:0E:D7:93:07:05:A8:09:8E:FF:C1:4D:17
MD5: 91:F4:03:55:20:A1:F8:63:2C:62:DE:AC:FB:61:1C:8E
SHA1: 21:FC:BD:8E:7F:6C:AF:05:1B:D1:B3:43:EC:A8:E7:61:47:F2:0F:8A
SHA256:
48:98:C6:88:8C:0C:FF:B0:D3:E3:1A:CA:8A:37:D4:E3:51:5F:F7:46:D0:26:35:D8:66:46:CF:A0:A3:18:5A:E7
Alias name: baltimorecybertrustca
MD5: AC:B6:94:A5:9C:17:E0:D7:91:52:9B:B1:97:06:A6:E4
SHA1: D4:DE:20:D0:5E:66:FC:53:FE:1A:50:88:2C:78:DB:28:52:CA:E4:74
SHA256:
16:AF:57:A9:F6:76:B0:AB:12:60:95:AA:5E:BA:DE:F2:2A:B3:11:19:D6:44:AC:95:CD:4B:93:DB:F3:F2:6A:EB
MD5: 24:77:D9:A8:91:D1:3B:FA:88:2D:C2:FF:F8:CD:33:93
SHA1: D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61
SHA256:
62:DD:0B:E9:B9:F5:0A:16:3E:A0:F8:E7:5C:05:3B:1E:CA:57:EA:55:C8:68:8F:64:7C:68:81:F2:C8:35:7B:95
MD5: 93:2A:3E:F6:FD:23:69:0D:71:20:D4:2B:47:99:2B:A6
SHA1: CB:A1:C5:F8:B0:E3:5E:B8:B9:45:12:D3:F9:34:A2:E9:06:10:D3:36
SHA256:
A6:C5:1E:0D:A5:CA:0A:93:09:D2:E4:C0:E4:0C:2A:F9:10:7A:AE:82:03:85:7F:E1:98:E3:E7:69:E3:43:08:5C
MD5: A1:0B:44:B3:CA:10:D8:00:6E:9D:0F:D8:0F:92:0A:D1
SHA1: B8:01:86:D1:EB:9C:86:A5:41:04:CF:30:54:F3:4C:52:B7:E5:58:C6
SHA256:
CE:CD:DC:90:50:99:D8:DA:DF:C5:B1:D2:09:B7:37:CB:E2:C1:8C:FB:2C:10:C0:FF:0B:CF:0D:32:86:FC:1A:A2
MD5: 9E:80:FF:78:01:0C:2E:C1:36:BD:FE:96:90:6E:08:F3
SHA1: 4A:BD:EE:EC:95:0D:35:9C:89:AE:C7:52:A1:2C:5B:29:F6:D6:AA:0C
SHA256:
13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA
SHA256:
MD5: DB:C8:F2:27:2E:B1:EA:6A:29:23:5D:FE:56:3E:33:DF
SHA1: C8:EC:8C:87:92:69:CB:4B:AB:39:E9:8D:7E:57:67:F3:14:95:73:9D
SHA256:
E3:89:36:0D:0F:DB:AE:B3:D2:50:58:4B:47:30:31:4E:22:2F:39:C1:56:A0:20:14:4E:8D:96:05:61:79:15:06
MD5: 2C:8F:9F:66:1D:18:90:B1:47:26:9D:8E:86:82:8C:A9
SHA1: 62:52:DC:40:F7:11:43:A2:2F:DE:9E:F7:34:8E:06:42:51:B1:81:18
274
SHA256:
D8:E0:FE:BC:1D:B2:E3:8D:00:94:0F:37:D2:7D:41:34:4D:99:3E:73:4B:99:D5:65:6D:97:78:D4:D8:14:36:24
Alias name: camerfirmachamberscommerceca
MD5: B0:01:EE:14:D9:AF:29:18:94:76:8E:F1:69:33:2A:84
SHA1: 6E:3A:55:A4:19:0C:19:5C:93:84:3C:C0:DB:72:2E:31:30:61:F0:B1
SHA256:
0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
MD5: CF:F4:27:0D:D4:ED:DC:65:16:49:6D:3D:DA:BF:6E:DE
SHA1: 3A:44:73:5A:E5:81:90:1F:24:86:61:46:1E:3B:9C:C4:5F:F5:3A:1B
SHA256:
42:00:F5:04:3A:C8:59:0E:BB:52:7D:20:9E:D1:50:30:29:FB:CB:D4:1C:A1:B5:06:EC:27:F1:5A:DE:7D:AC:69
MD5: 2F:A8:B4:DA:F6:64:4B:1E:82:F9:46:3D:54:1A:7C:B0
SHA1: 51:7F:61:1E:29:91:6B:53:82:FB:72:E7:44:D9:8D:C3:CC:53:6D:64
SHA256:
9D:19:0B:2E:31:45:66:68:5B:E8:A8:89:E2:7A:A8:C7:D7:AE:1D:8A:AD:DB:A3:C1:EC:F9:D2:48:63:CD:34:B9
SHA256:
MD5: B7:52:74:E2:92:B4:80:93:F2:75:E4:CC:D7:F2:EA:26
SHA1: 3B:C4:9F:48:F8:F3:73:A0:9C:1E:BD:F8:5B:B1:C3:65:C7:D8:11:B3
SHA256:
BF:0F:EE:FB:9E:3A:58:1A:D5:F9:E9:DB:75:89:98:57:43:D2:61:08:5C:4D:31:4F:6F:5D:72:59:AA:42:16:12
MD5: 42:65:CA:BE:01:9A:9A:4C:A9:8C:41:49:CD:C0:D5:7F
SHA1: 29:36:21:02:8B:20:ED:02:F5:66:C5:32:D1:D6:ED:90:9F:45:00:2F
SHA256:
0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0:B4:1B
Alias name: gd_bundle-g2.pem
MD5: 96:C2:50:31:BC:0D:C3:5C:FB:A7:23:73:1E:1B:41:40
SHA1: 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
SHA256:
97:3A:41:27:6F:FD:01:E0:27:A2:AA:D4:9E:34:C3:78:46:D3:E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6
Alias name: certumca
MD5: 2C:8F:9F:66:1D:18:90:B1:47:26:9D:8E:86:82:8C:A9
SHA1: 62:52:DC:40:F7:11:43:A2:2F:DE:9E:F7:34:8E:06:42:51:B1:81:18
SHA256:
D8:E0:FE:BC:1D:B2:E3:8D:00:94:0F:37:D2:7D:41:34:4D:99:3E:73:4B:99:D5:65:6D:97:78:D4:D8:14:36:24
Alias name: deutschetelekomrootca2
MD5: 74:01:4A:91:B1:08:C4:58:CE:47:CD:F0:DD:11:53:08
SHA1: 85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
SHA256:
B6:19:1A:50:D0:C3:97:7F:7D:A9:9B:CD:AA:C8:6A:22:7D:AE:B9:67:9E:C7:0B:A3:B0:C9:D9:22:71:C1:70:D3
MD5: 27:EC:39:47:CD:DA:5A:AF:E2:9A:01:65:21:A9:4C:BB
SHA1: 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:C5:4D:8B:CF
SHA256:
80:95:21:08:05:DB:4B:BC:35:5E:44:28:D8:FD:6E:C2:CD:E3:AB:5F:B9:7A:99:42:98:8E:B8:F4:DC:D0:60:16
MD5: 41:03:52:DC:0F:F7:50:1B:16:F0:02:8E:BA:6F:45:C5
SHA1: DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
SHA256:
06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
Alias name: secomevrootca1
MD5: 22:2D:A6:01:EA:7C:0A:F7:F0:6C:56:43:3F:77:76:D3
SHA1: FE:B8:C4:32:DC:F9:76:9A:CE:AE:3D:D8:90:8F:FD:28:86:65:64:7D
SHA256:
A2:2D:BA:68:1E:97:37:6E:2D:39:7D:72:8A:AE:3A:9B:62:96:B9:FD:BA:60:BC:2E:11:F6:47:F2:C6:75:FB:37
MD5: C5:DF:B8:49:CA:05:13:55:EE:2D:BA:1A:C3:3E:B0:28
SHA1: D6:9B:56:11:48:F0:1C:77:C5:45:78:C1:09:26:DF:5B:85:69:76:AD
275
SHA256:
CB:B5:22:D7:B7:F1:27:AD:6A:01:13:86:5B:DF:1C:D4:10:2E:7D:07:59:AF:63:5A:7C:F4:72:0D:C9:63:C5:3B
Alias name: globalsignr3ca
MD5: C5:DF:B8:49:CA:05:13:55:EE:2D:BA:1A:C3:3E:B0:28
SHA1: D6:9B:56:11:48:F0:1C:77:C5:45:78:C1:09:26:DF:5B:85:69:76:AD
SHA256:
CB:B5:22:D7:B7:F1:27:AD:6A:01:13:86:5B:DF:1C:D4:10:2E:7D:07:59:AF:63:5A:7C:F4:72:0D:C9:63:C5:3B
MD5: EE:29:31:BC:32:7E:9A:E6:E8:B5:F7:51:B4:34:71:90
SHA1: 50:30:06:09:1D:97:D4:F5:AE:39:F7:CB:E7:92:7D:7D:65:2D:34:31
SHA256:
6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77
Alias name: gdroot-g2.pem
SHA256:
Alias name: aolrootca2
MD5: D6:ED:3C:CA:E2:66:0F:AF:10:43:0D:77:9B:04:09:BF
SHA1: 85:B5:FF:67:9B:0C:79:96:1F:C8:6E:44:22:00:46:13:DB:17:92:84
SHA256:
7D:3B:46:5A:60:14:E5:26:C0:AF:FC:EE:21:27:D2:31:17:27:AD:81:1C:26:84:2D:00:6A:F3:73:06:CC:80:BD
Alias name: trustcenteruniversalcai
MD5: 45:E1:A5:72:C5:A9:36:64:40:9E:F5:E4:58:84:67:8C
SHA1: 6B:2F:34:AD:89:58:BE:62:FD:B0:6B:5C:CE:BB:9D:D9:4F:4E:39:F3
SHA256:
EB:F3:C0:2A:87:89:B1:FB:7D:51:19:95:D6:63:B7:29:06:D9:13:CE:0D:5E:10:56:8A:8A:77:E2:58:61:67:E7
Alias name: aolrootca1
MD5: 14:F1:08:AD:9D:FA:64:E2:89:E7:1C:CF:A8:AD:7D:5E
SHA1: 39:21:C1:15:C1:5D:0E:CA:5C:CB:5B:C4:F0:7D:21:D8:05:0B:56:6A
SHA256:
77:40:73:12:C6:3A:15:3D:5B:C0:0B:4E:51:75:9C:DF:DA:C2:37:DC:2A:33:B6:79:46:E9:8E:9B:FA:68:0A:E3
MD5: 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1
SHA1: B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D
SHA256:
3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1
MD5: FB:1B:5D:43:8A:94:CD:44:C6:76:F2:43:4B:47:E7:31
SHA1: F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2
SHA256:
4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C
MD5: B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73
SHA1: 20:42:85:DC:F7:EB:76:41:95:57:8E:13:6B:D4:B7:D1:E9:8E:46:A5
SHA256:
CB:B5:AF:18:5E:94:2A:24:02:F9:EA:CB:C0:ED:5B:B8:76:EE:A3:C1:22:36:23:D0:04:47:E4:F3:BA:55:4B:65
MD5: AA:C6:43:2C:5E:2D:CD:C4:34:C0:50:4F:11:02:4F:B6
SHA1: 96:C9:1B:0B:95:B4:10:98:42:FA:D0:D8:22:79:FE:60:FA:B9:16:83
SHA256:
EE:C5:49:6B:98:8C:E9:86:25:B9:34:09:2E:EC:29:08:BE:D0:B0:F3:16:C2:D4:73:0C:84:EA:F1:F3:D3:48:81
Alias name: addtrustexternalca
MD5: 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F
SHA1: 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
SHA256:
68:7F:A4:51:38:22:78:FF:F0:C8:B1:1F:8D:43:D5:76:67:1C:6E:B2:BC:EA:B4:13:FB:83:D9:65:D0:6D:2F:F2
SHA256:
Alias name: verisignclass3ca
SHA1: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
276
SHA256:
MD5: 1B:2E:00:CA:26:06:90:3D:AD:FE:6F:15:68:D3:6B:B3
SHA1: 67:65:0D:F1:7E:8E:7E:5B:82:40:A4:F4:56:4B:CF:E2:3D:69:C6:F0
SHA256:
C0:A6:F4:DC:63:A2:4B:FD:CF:54:EF:2A:6A:08:2A:0A:72:DE:35:80:3E:2F:F5:FF:52:7A:E5:D8:72:06:DF:D5
MD5: 26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60
SHA1: 0B:77:BE:BB:CB:7A:A2:47:05:DE:CC:0F:BD:6A:02:FC:7A:BD:9B:52
SHA256:
44:64:0A:0A:0E:4D:00:0F:BD:57:4D:2B:8A:07:BD:B4:D1:DF:ED:3B:45:BA:AB:A7:6F:78:57:78:C7:01:19:61
Alias name: digicertassuredidrootca
MD5: 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
SHA1: 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
SHA256:
3E:90:99:B5:01:5E:8F:48:6C:00:BC:EA:9D:11:1E:E7:21:FA:BA:35:5A:89:BC:F1:DF:69:56:1E:3D:C6:32:5C
Alias name: verisignclass1ca
MD5: 86:AC:DE:2B:C5:6D:C3:D9:8C:28:88:D3:8D:16:13:1E
SHA1: CE:6A:64:A3:09:E4:2F:BB:D9:85:1C:45:3E:64:09:EA:E8:7D:60:F1
SHA256:
51:84:7C:8C:BD:2E:9A:72:C9:1E:29:2D:2A:E2:47:D7:DE:1E:3F:D2:70:54:7A:20:EF:7D:61:0F:38:B8:84:2C
MD5: 26:01:FB:D8:27:A7:17:9A:45:54:38:1A:43:01:3B:03
SHA1: B5:61:EB:EA:A4:DE:E4:25:4B:69:1A:98:A5:57:47:C2:34:C7:D9:71
SHA256:
E2:3D:4A:03:6D:7B:70:E9:F5:95:B1:42:20:79:D2:B9:1E:DF:BB:1F:B6:51:A0:63:3E:AA:8A:9D:C5:F8:07:03
Alias name: thawtepremiumserverca
MD5: A6:6B:60:90:23:9B:3F:2D:BB:98:6F:D6:A7:19:0D:46
SHA1: E0:AB:05:94:20:72:54:93:05:60:62:02:36:70:F7:CD:2E:FC:66:66
SHA256:
3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9
Alias name: verisigntsaca
MD5: F2:89:95:6E:4D:05:F0:F1:A7:21:55:7D:46:11:BA:47
SHA1: 20:CE:B1:F0:F5:1C:0E:19:A9:F3:8D:B1:AA:8E:03:8C:AA:7A:C7:01
SHA256:
CB:6B:05:D9:E8:E5:7C:D8:82:B1:0B:4D:B7:0D:E4:BB:1D:E4:2B:A4:8A:7B:D0:31:8B:63:5B:F6:E7:78:1A:9D
MD5: CA:FB:40:A8:4E:39:92:8A:1D:FE:8E:2F:C4:27:EA:EF
SHA1: 55:A6:72:3E:CB:F2:EC:CD:C3:23:74:70:19:9D:2A:BE:11:E3:81:D1
SHA256:
FD:73:DA:D3:1C:64:4F:F1:B4:3B:EF:0C:CD:DA:96:71:0B:9C:D9:87:5E:CA:7E:31:70:7A:F3:E9:6D:52:2B:BD
MD5: 31:85:3C:62:94:97:63:B9:AA:FD:89:4E:AF:6F:E0:CF
SHA1: 1F:49:14:F7:D8:74:95:1D:DD:AE:02:C0:BE:FD:3A:2D:82:75:51:85
SHA256:
18:F1:FC:7F:20:5D:F8:AD:DD:EB:7F:E0:07:DD:57:E3:AF:37:5A:9C:4D:8D:73:54:6B:F4:F1:FE:D1:E1:8D:35
Alias name: thawteprimaryrootca
MD5: 8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
SHA1: 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
SHA256:
8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F
MD5: BC:6C:51:33:A7:E9:D3:66:63:54:15:72:1B:21:92:93
SHA1: 59:22:A1:E1:5A:EA:16:35:21:F8:98:39:6A:46:46:B0:44:1B:0F:A9
SHA256:
41:C9:23:86:6A:B4:CA:D6:B7:AD:57:80:81:58:2E:02:07:97:A6:CB:DF:4F:FF:78:CE:83:96:B3:89:37:D7:F5
MD5: C5:70:C4:A2:ED:53:78:0C:C8:10:53:81:64:CB:D0:1D
SHA1: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C
SHA256:
B4:41:0B:73:E2:E6:EA:CA:47:FB:C4:2F:8F:A4:01:8A:F4:38:1D:C5:4C:FA:A8:44:50:46:1E:ED:09:45:4D:E9
Alias name: xrampglobalca
MD5: A1:0B:44:B3:CA:10:D8:00:6E:9D:0F:D8:0F:92:0A:D1
SHA1: B8:01:86:D1:EB:9C:86:A5:41:04:CF:30:54:F3:4C:52:B7:E5:58:C6
277
SHA256:
CE:CD:DC:90:50:99:D8:DA:DF:C5:B1:D2:09:B7:37:CB:E2:C1:8C:FB:2C:10:C0:FF:0B:CF:0D:32:86:FC:1A:A2
MD5: AA:08:8F:F6:F9:7B:B7:F2:B1:A7:1E:9B:EA:EA:BD:79
SHA1: CF:9E:87:6D:D3:EB:FC:42:26:97:A3:B5:A3:7A:A0:76:A9:06:23:48
SHA256:
BF:D8:8F:E1:10:1C:41:AE:3E:80:1B:F8:BE:56:35:0E:E9:BA:D1:A6:B9:BD:51:5E:DC:5C:6D:5B:87:11:AC:44
Alias name: valicertclass2ca
MD5: A9:23:75:9B:BA:49:36:6E:31:C2:DB:F2:E7:66:BA:87
SHA1: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6
SHA256:
58:D0:17:27:9C:D4:DC:63:AB:DD:B1:96:A6:C9:90:6C:30:C4:E0:87:83:EA:E8:C1:60:99:54:D6:93:55:59:6B
MD5: 34:FC:B8:D0:36:DB:9E:14:B3:C2:F2:DB:8F:E4:94:C7
SHA1: 37:9A:19:7B:41:85:45:35:0C:A6:03:69:F3:3C:2E:AF:47:4F:20:79
SHA256:
A0:23:4F:3B:C8:52:7C:A5:62:8E:EC:81:AD:5D:69:89:5D:A5:68:0D:C9:1D:1C:B8:47:7F:33:F8:78:B9:5B:0B
MD5: B0:01:EE:14:D9:AF:29:18:94:76:8E:F1:69:33:2A:84
SHA1: 6E:3A:55:A4:19:0C:19:5C:93:84:3C:C0:DB:72:2E:31:30:61:F0:B1
SHA256:
0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
Alias name: geotrustprimaryca
MD5: 02:26:C3:01:5E:08:30:37:43:A9:D0:7D:CF:37:E6:BF
SHA1: 32:3C:11:8E:1B:F7:B8:B6:52:54:E2:E2:10:0D:D6:02:90:37:F0:96
SHA256:
37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C
MD5: 8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
SHA1: 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
SHA256:
8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F
MD5: DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83
SHA1: 27:3E:E1:24:57:FD:C4:F9:0C:55:E8:2B:56:16:7F:62:F5:32:E5:47
SHA256:
34:1D:E9:8B:13:92:AB:F7:F4:AB:90:A9:60:CF:25:D4:BD:6E:C6:5B:9A:51:CE:6E:D0:67:D0:0E:C7:CE:9B:7F
MD5: 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16
SHA1: 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
SHA256:
C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA
MD5: 17:35:74:AF:7B:61:1C:EB:F4:F9:3C:E2:EE:40:F9:A2
SHA1: 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:E8:25:6F:3F
SHA256:
56:8D:69:05:A2:C8:87:08:A4:B3:02:51:90:ED:CF:ED:B1:97:4A:60:6A:13:C6:E5:29:0F:CB:2A:E6:3E:DA:B5
MD5: 64:9C:EF:2E:44:FC:C6:8F:52:07:D0:51:73:8F:CB:3D
SHA1: DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41
SHA256:
CF:56:FF:46:A4:A1:86:10:9D:D9:65:84:B5:EE:B5:8A:51:0C:42:75:B0:E5:F9:4F:40:BB:AE:86:5E:19:F6:73
Alias name: geotrustglobalca
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256:
FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
MD5: 91:1B:3F:6E:CD:9E:AB:EE:07:FE:1F:71:D2:B3:61:27
SHA1: E1:9F:E3:0E:8B:84:60:9E:80:9B:17:0D:72:A8:C5:BA:6E:14:09:BD
SHA256:
3F:06:E5:56:81:D4:96:F5:BE:16:9E:B5:38:9F:9F:2B:8F:F6:1E:17:08:DF:68:81:72:48:49:CD:5D:27:CB:69
MD5: 79:E4:A9:84:0D:7D:3A:96:D7:C0:4F:E2:43:4C:89:2E
SHA1: A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
278
SHA256:
43:48:A0:E9:44:4C:78:CB:26:5E:05:8D:5E:89:44:B4:D8:4F:96:62:BD:26:DB:25:7F:89:34:A4:43:C7:01:61
Alias name: comodoaaaca
MD5: 49:79:04:B0:EB:87:19:AC:47:B0:BC:11:51:9B:74:D0
SHA1: D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
SHA256:
D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4
MD5: F8:49:F4:03:BC:44:2D:83:BE:48:69:7D:29:64:FC:B1
SHA1: 89:DF:74:FE:5C:F4:0F:4A:80:F9:E3:37:7D:54:DA:91:E1:01:31:8E
SHA256:
3C:5F:81:FE:A5:FA:B8:2C:64:BF:A2:EA:EC:AF:CD:E8:E0:77:FC:86:20:A7:CA:E5:37:16:3D:F3:6E:DB:F3:78
Alias name: certplusclass2primaryca
MD5: 88:2C:8C:52:B8:A2:3C:F3:F7:BB:03:EA:AE:AC:42:0B
SHA1: 74:20:74:41:72:9C:DD:92:EC:79:31:D8:23:10:8D:C2:81:92:E2:BB
SHA256:
0F:99:3C:8A:EF:97:BA:AF:56:87:14:0E:D5:9A:D1:82:1B:B4:AF:AC:F0:AA:9A:58:B5:D5:7A:33:8A:3A:FB:CB
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256:
FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
Alias name: ttelesecglobalrootclass2ca
MD5: 2B:9B:9E:E4:7B:6C:1F:00:72:1A:CC:C1:77:79:DF:6A
SHA1: 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:17:D8:94:E9
SHA256:
91:E2:F5:78:8D:58:10:EB:A7:BA:58:73:7D:E1:54:8A:8E:CA:CD:01:45:98:BC:0B:14:3E:04:1B:17:05:25:52
MD5: 37:A5:6E:D4:B1:25:84:97:B7:FD:56:15:7A:F9:A2:00
SHA1: B4:35:D4:E1:11:9D:1C:66:90:A7:49:EB:B3:94:BD:63:7B:A7:82:B7
SHA256:
C4:70:CF:54:7E:23:02:B9:77:FB:29:DD:71:A8:9A:7B:6C:1F:60:77:7B:03:29:F5:60:17:F3:28:BF:4F:6B:E6
Alias name: digicerthighassuranceevrootca
MD5: D4:74:DE:57:5C:39:B2:D3:9C:85:83:C5:C0:65:49:8A
SHA1: 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25
SHA256:
74:31:E5:F4:C3:C1:CE:46:90:77:4F:0B:61:E0:54:40:88:3B:A9:A0:1E:D0:0B:A6:AB:D7:80:6E:D3:B1:18:CF
Alias name: amzninternalinfoseccag3
MD5: E9:34:94:02:BA:BB:31:6B:22:E6:2B:A9:C4:F0:26:04
SHA1: B9:B1:CA:38:F7:BF:9C:D2:D4:95:E7:B6:5E:75:32:9B:A8:78:2E:F6
SHA256:
81:03:0B:C7:E2:54:DA:7B:F8:B7:45:DB:DD:41:15:89:B5:A3:81:86:FB:4B:29:77:1F:84:0A:18:D9:67:6D:68
MD5: 21:BC:82:AB:49:C4:13:3B:4B:B2:2B:5C:6B:90:9C:19
SHA1: 8B:AF:4C:9B:1D:F0:2A:92:F7:DA:12:8E:B9:1B:AC:F4:98:60:4B:6F
SHA256:
E2:83:93:77:3D:A8:45:A6:79:F2:08:0C:C7:FB:44:A3:B7:A1:C3:79:2C:B7:EB:77:29:FD:CB:6A:8D:99:AE:A7
MD5: AE:B9:C4:32:4B:AC:7F:5D:66:CC:77:94:BB:2A:77:56
SHA1: 2B:B1:F5:3E:55:0C:1D:C5:F1:D4:E6:B7:6A:46:4B:55:06:02:AC:21
SHA256:
F3:56:BE:A2:44:B7:A9:1E:B3:5D:53:CA:9A:D7:86:4A:CE:01:8E:2D:35:D5:F8:F9:6D:DF:68:A6:F4:1A:A4:74
Alias name: globalsignca
MD5: 3E:45:52:15:09:51:92:E1:B7:5D:37:9F:B1:87:29:8A
SHA1: B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
SHA256:
EB:D4:10:40:E4:BB:3E:C7:42:C9:E3:81:D3:1E:F2:A4:1A:48:B6:68:5C:96:E7:CE:F3:C1:DF:6C:D4:33:1C:99
MD5: 45:E1:A5:72:C5:A9:36:64:40:9E:F5:E4:58:84:67:8C
SHA1: 6B:2F:34:AD:89:58:BE:62:FD:B0:6B:5C:CE:BB:9D:D9:4F:4E:39:F3
SHA256:
EB:F3:C0:2A:87:89:B1:FB:7D:51:19:95:D6:63:B7:29:06:D9:13:CE:0D:5E:10:56:8A:8A:77:E2:58:61:67:E7
MD5: 8E:AD:B5:01:AA:4D:81:E4:8C:1D:D1:E1:14:00:95:19
279
Usar planes de uso de API Gateway
SHA256:
MD5: 5B:04:69:EC:A5:83:94:63:18:A7:86:D0:E4:F2:6E:19
SHA1: 77:47:4F:C6:30:E4:0F:4C:47:64:3F:84:BA:B8:C6:95:4A:8A:41:EC
SHA256:
F0:9B:12:2C:71:14:F4:A0:9B:D4:EA:4F:4A:99:D5:58:B4:6E:4C:25:CD:81:14:0D:29:C0:56:13:91:4C:38:41
Alias name: trustcenterclass2caii
MD5: CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
SHA1: AE:50:83:ED:7C:F4:5C:BC:8F:61:C6:21:FE:68:5D:79:42:21:15:6E
SHA256:
E6:B8:F8:76:64:85:F8:07:AE:7F:8D:AC:16:70:46:1F:07:C0:A1:3E:EF:3A:1F:F7:17:53:8D:7A:BA:D3:91:B4
MD5: C9:3B:0D:84:41:FC:A4:76:79:23:08:57:DE:10:19:16
SHA1: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
SHA256:
E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11
MD5: CB:17:E4:31:67:3E:E2:09:FE:45:57:93:F3:0A:FA:1C
SHA256:
Alias name: geotrustprimarycag3
MD5: B5:E8:34:36:C9:10:44:58:48:70:6D:2E:83:D4:B8:05
SHA1: 03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
SHA256:
B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4
Alias name: geotrustprimarycag2
MD5: 01:5E:D8:6B:BD:6F:3D:8E:A1:31:F8:12:E0:98:73:6A
SHA1: 8D:17:84:D5:37:F3:03:7D:EC:70:FE:57:8B:51:9A:99:E6:10:D7:B0
SHA256:
5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66
MD5: 15:AC:A5:C2:92:2D:79:BC:E8:7F:CB:67:ED:02:CF:36
SHA1: E7:B4:F6:9D:61:EC:90:69:DB:7E:90:A7:40:1A:3C:F4:7D:4F:E8:EE
SHA256:
A7:12:72:AE:AA:A3:CF:E8:72:7F:7F:B3:9F:0F:B3:D1:E5:42:6E:90:60:B0:6E:E6:F1:3E:9A:3C:58:33:CD:43
Alias name: affirmtrustpremiumeccca
MD5: 64:B0:09:55:CF:B1:D5:99:E2:BE:13:AB:A6:5D:EA:4D
SHA1: B8:23:6B:00:2F:1D:16:86:53:01:55:6C:11:A4:37:CA:EB:FF:C3:BB
SHA256:
BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23
MD5: B8:08:9A:F0:03:CC:1B:0D:C8:6C:0B:76:A1:75:64:23
SHA1: A0:A1:AB:90:C9:FC:84:7B:3B:12:61:E8:97:7D:5F:D3:22:61:D3:CC
SHA256:
0F:4E:9C:DD:26:4B:02:55:50:D1:70:80:63:40:21:4F:E9:44:34:C9:B0:2F:69:7E:C7:10:FC:5F:EA:FB:5E:38
Crear usar planes de uso de API Gateway

Después de crear, probar e implementar sus API, puede ampliarlas como ofertas de productos para los
clientes. Puede proporcionar planes de uso para permitir que determinados clientes tengan acceso a
las API seleccionadas de acuerdo con las tarifas y cuotas de solicitudes acordadas en función de sus
requisitos empresariales y restricciones presupuestarias.
¿Qué es un plan de uso?

Un plan de uso proporciona acceso a una o más etapas de la API implementada con limitaciones
de solicitudes y límites de cuota configurables aplicados a las claves de API de cada cliente. Los
intermediarios de la API se identifican mediante claves de API que API Gateway puede generar o que
se pueden importar de orígenes externos. La limitación de solicitudes establece los límites de tasa de
solicitudes aplicados a cada clave de API. Las cuotas son el número máximo de solicitudes con una clave
280
de API determinada enviadas en un intervalo de tiempo especificado. Se pueden configurar distintos

métodos de la API para exigir la autorización de la clave de API en función de la configuración del plan de
uso. Una etapa de API se identifica mediante un identificador de API y un nombre de etapa.
Note
La limitación de solicitudes y los límites de cuota se aplican a las solicitudes de claves de API
individuales que se van acumulando en todas las etapas de la API dentro de un plan de uso.
¿Cómo se configura un plan de uso?

Los siguientes pasos describen cómo usted, como propietario de la API, configura un plan de uso para los
clientes.
Para configurar un plan de uso
1. Cree una o varias API, configure los métodos que requieren una clave de API e implemente las API en
etapas.
2. Genere claves de API y distribuya las claves a los desarrolladores de aplicaciones (sus clientes) a
través de las API.
3. Cree el plan de uso con la limitación de solicitudes y los límites de cuota que desee.
4. Asocie las etapas y las claves de API seleccionadas al plan de uso.
Los intermediarios de la API tendrán que proporcionar una clave de API asignada en el encabezado x-
api-key de las solicitudes a la API.
Note
Para aplicar la autorización de la clave de API en las solicitudes a la API, deben configurarse
distintos métodos para exigir una clave de API (p. 281). Con esta configuración se asegurará de
que la clave de API de entrada esté autorizada de acuerdo con la configuración del plan de uso.
En las secciones siguientes se proporcionan instrucciones detalladas para estas tareas.
Configurar claves de API mediante la consola de API Gateway

Para configurar las claves de API, haga lo siguiente:
• Configure los métodos de la API para que exijan una clave de API.
• Cree o importe una clave de API para la API de una región.
Antes de configurar las claves de API, debe haber creado una API y haberla implementado hasta una fase.
Para obtener instrucciones sobre cómo crear e implementar una API mediante la consola de API Gateway,
consulte Crear una API (p. 73) y Implementar una API (p. 294), respectivamente.
Temas
• Exigir una clave de API en un método (p. 281)
• Crear una clave de API (p. 282)
• Importar claves de API (p. 283)
Exigir una clave de API en un método

El siguiente procedimiento describe cómo configurar un método de API para exigir una clave de API.
281
Para configurar un método de API para exigir una clave de API
1. Inicie sesión en la Consola de administración de AWS y abra la consola de API Gateway en https://
console.aws.amazon.com/apigateway/.
2. En el panel de navegación principal de API Gateway, seleccione Resources.
3. En Resources, cree un método nuevo o elija uno existente.
5. En la sección Authorization Settings, elija true en API Key Required.
6. Seleccione el icono de marca de verificación para guardar la configuración.
7. Implemente o redistribuya la API para que el requisito surta efecto.
Si la opción API Key Required está establecida false y no ejecuta los pasos anteriores, las claves de API
asociadas a una etapa de API no se usarán para el método.
Crear una clave de API

Si ya ha creado o importado claves de API para su uso con planes de uso, puede omitir este procedimiento
y el siguiente.
Para crear una clave de API
1. Inicie sesión en la Consola de administración de AWS y abra la consola de API Gateway en https://
console.aws.amazon.com/apigateway/.
2. En el panel de navegación principal de API Gateway, seleccione API Keys.
3. En el menú desplegable Actions, elija Create API key.
282
4. En Create API Key, haga lo siguiente:
a. Escriba un nombre de clave de API (por ejemplo, MiPrimeraClave) en el campo de entrada

Name.
b. Elija Auto Generate para que API Gateway genere el valor de la clave o elija Custom para
especificar la clave manualmente.
c. Seleccione Save.
5. Repita los pasos anteriores para crear varias claves de API, si es necesario.
Importar claves de API

El siguiente procedimiento describe cómo importar claves de API para usarlas con planes de uso.
Para importar claves de API
1. En el panel de navegación principal, seleccione API Keys.

2. En el menú desplegable Actions, elija Import API keys.
3. Para cargar un archivo de claves separado por comas, elija Select CSV File. También puede escribir
las claves manualmente. Para obtener información sobre el formato de los archivos, consulte Formato
de archivo de clave de API de API Gateway (p. 291).
283
4. Elija Fail on warnings para detener la importación cuando se produzca un error o elija Ignore warnings
para seguir importando entradas de clave válidas cuando se produzca un error.
5. Para empezar a importar las claves de API seleccionadas, elija Import.
Ahora que ha configurado la clave de API, puede empezar a crear y utilizar un plan de uso (p. 284).
Crear, configurar y probar los planes de uso con la consola de

API Gateway
Antes de crear un plan de uso, asegúrese de que ha configurado las claves de API deseadas.
Para obtener más información, consulte Configurar claves de API mediante la consola de API
Gateway (p. 281).
En esta sección se describen los pasos necesarios para crear y utilizar un plan de uso mediante la consola
de API Gateway.
Temas
• Migrar a planes de uso predeterminados (p. 284)
• Crear planes de uso (p. 285)
• Probar un plan de uso (p. 287)
• Mantener el plan de uso (p. 287)
Migrar a planes de uso predeterminados

Si empieza a utilizar API Gateway después del 11 de agosto de 2016 (fecha en la que se implementó la
característica de planes de uso), los planes de uso estarán habilitados de forma predeterminada en todas
las regiones compatibles.
284
Si empezó a utilizar API Gateway antes de esa fecha, se le mostrará la opción Enable Usage Plans antes
de usar Usage Plans por primera vez en la región seleccionada. Al activar esta opción, dispondrá de
planes de uso predeterminados para cada etapa de API asociada con claves de API existentes. En el
plan de uso predeterminado, las limitaciones de solicitudes y los límites de cuota no están establecidos
inicialmente, las claves de API existentes se han convertido en una colección de recursos UsagePlanKey
y las claves de API existentes se han convertido en identificadores de etapa de API. La API se comportará
igual que antes. Sin embargo, debe usar la propiedad UsagePlan apiStages para asociar los valores de
etapa de API especificados (apiId y stage) con claves de API incluidas (a través de UsagePlanKey), en
lugar de usar la propiedad ApiKey stageKeys.
Crear planes de uso

El siguiente procedimiento describe cómo crear un plan de uso.
Para crear un plan de uso
1. En el panel de navegación principal de Amazon API Gateway, elija Usage Plans y, a continuación, elija
Create.
2. En Create Usage Plan, haga lo siguiente:
a. En Name, escriba un nombre para su plan (por ejemplo, Plan_A).

b. En Description, escriba un nombre y la descripción del plan.
c. Seleccione Enable throttling y configure Rate (por ejemplo, 100) y Burst (por ejemplo, 200).
d. Elija Enable quota y defina sus límites (por ejemplo, 5000) durante un intervalo de tiempo
seleccionado (por ejemplo, Month).
e. Seleccione Save.
3. Para añadir una etapa al plan, haga lo siguiente en el panel Associated API Stages:
a. Elija Add API Stage.

b. Elija una API (por ejemplo, PetStore) en la lista desplegable API.
285
c. Elija una etapa (por ejemplo, Etapa_1) en la lista desplegable Stage.

d. Elija el icono de marca de verificación para guardar.
e. Seleccione Next.
4. Para añadir una clave al plan, haga lo siguiente en el panel Usage Plan API Keys:
a. Para utilizar una clave existente, elija Add API Key to Usage Plan.
b. En Name, escriba un nombre para la clave que desea agregar (por ejemplo, MiPrimeraClave).
c. Elija el icono de marca de verificación para guardar.
d. Si lo desea, repita los pasos anteriores para añadir otras claves de API existentes a este plan de
uso.
286
Note
Para añadir una nueva clave de API al plan de uso, elija Create API Key and add to Usage
Plan y siga las instrucciones.
5. Para terminar de crear el plan de uso, elija Done.
6. Si desea añadir más etapas de API al plan de uso, elija Add API Stage para repetir los pasos
anteriores.
Probar un plan de uso

Para probar el plan de uso, puede utilizar un SDK de AWS la AWS CLI o un cliente de API REST como
Postman. Para ver un ejemplo de uso de Postman para probar el plan de uso, consulte Probar planes de
uso (p. 290).
Mantener el plan de uso

El mantenimiento de un plan de uso implica monitorizar las cuotas usadas y restantes durante un
período de tiempo determinado y ampliar las cuotas restantes en una cantidad específica. Los siguientes
procedimientos describen cómo monitorizar y ampliar las cuotas.
Para monitorizar las cuotas usadas y restantes
1. En el panel de navegación principal de API Gateway, seleccione Usage Plans.

2. Elija un plan de uso en la lista de planes de uso del panel de navegación secundario situado en la
parte central.
3. En el plan especificado, elija API Keys.
4. Elija una clave de API. A continuación, elija Usage para ver Subscriber's Traffic desde el plan que va a
monitorizar.
5. Si lo desea, elija Export, elija una fecha From y una fecha To, elija JSON o CSV para el formato de los
datos exportados y, a continuación, elija Export.
El siguiente ejemplo muestra un archivo exportado.
{
"thisPeriod": {
"px1KW6...qBazOJH": [
[
0,
5000
],
[
0,
5000
],
[
0,
10
]
]
},
"startDate": "2016-08-01",
"endDate": "2016-08-03"
}
Los datos de uso del ejemplo muestran los datos de uso diario de un cliente de API identificado por la
clave de API (px1KW6...qBazOJH), entre el 1 de agosto de 2016 y el 3 de agosto de 2016. Cada dato
de uso diario muestra las cuotas usadas y restantes. En este ejemplo, el suscriptor aún no ha utilizado
287
ninguna de las cuotas asignadas y el propietario o el administrador de la API han reducido la cuota
restante de 5000 a 10 el tercer día.
Para ampliar las cuotas restantes
1. Repita los pasos 1-3 del procedimiento anterior.

2. En la página del plan de uso, elija Extension en la ventana del plan de uso.
3. Escriba un número para las cuotas de solicitud Remaining.
4. Seleccione Save.
Configurar claves de API mediante la API REST de API Gateway

Para configurar las claves de API, haga lo siguiente:
• Configure los métodos de la API para que exijan una clave de API.
• Cree o importe una clave de API para la API de una región.
Antes de configurar las claves de API, debe haber creado una API y haberla implementado hasta una fase.
Para usar llamadas de API REST para crear e implementar una API, consulte restapi:create y
deployment:create, respectivamente.
Temas
• Exigir una clave de API en un método (p. 288)
• Crear o importar claves de API (p. 288)
Exigir una clave de API en un método

Para exigir una clave de API en un método, realice alguna de las siguientes operaciones:
• Llame a method:put para crear un método estableciendo apiKeyRequired en true en la carga de

solicitudes.
• Llame a method:update para establecer apiKeyRequired en true.
Crear o importar claves de API

Para crear o importar una clave de API, realice alguna de las siguientes operaciones:
• Llame a apikey:create para crear una clave de API.

• Llame a apikey:import para importar una clave de API desde un archivo. Para el formato de archivo,
consulte Formato de archivo de clave de API de API Gateway (p. 291).
Con la clave de API creada, ahora puede continuar con Crear, configurar y probar los planes de uso con la
API REST de API Gateway (p. 288).
Crear, configurar y probar los planes de uso con la API REST de

API Gateway
Antes de configurar un plan de uso, debe haber configurado métodos de una API seleccionada para exigir
claves de API, debe haber implementado o vuelto a implementar la API en una etapa y debe haber creado
288
o importado una o varias claves de API. Para obtener más información, consulte Configurar claves de API
mediante la API REST de API Gateway (p. 288).
Para configurar un plan de uso mediante la API REST de API Gateway, use las siguientes instrucciones, si
ya ha creado las API que se van a añadir al plan de uso.
Temas
• Migrar a planes de uso predeterminados (p. 289)
• Crear un plan de uso (p. 289)
• Administrar un plan de uso (p. 290)
• Probar planes de uso (p. 290)
Migrar a planes de uso predeterminados

Cuando cree un plan de uso por primera vez, puede migrar las etapas de API existentes asociadas con
claves de API seleccionadas a un plan de uso llamando a account:update con el cuerpo siguiente:
{
"op" : "add",
"path" : "/features",
"value" : "UsagePlans"
} ]
}
Para obtener más información sobre cómo migrar etapas de API asociadas con claves de API consulte
Migrar a planes de uso predeterminados en la consola de API Gateway (p. 284).
Crear un plan de uso

El siguiente procedimiento describe cómo crear un plan de uso.
Para crear un plan de uso con la API REST
1. Llame a usageplan:create para crear un plan de uso especificando en la carga el nombre y la

descripción del plan, las etapas de API asociadas, los límites de tarifa y las cuotas.
Anote el identificador del plan de uso resultante. Lo necesitará en el siguiente paso.

a. Llame a usageplankey:create para agregar una clave de API al plan de uso, especificando keyId
y keyType en la carga.
Para añadir más claves de API al plan de uso, repita la llamada anterior usando una clave de API
cada vez.
b. Llame a apikey:import para agregar una o varias claves de API directamente al plan de uso
especificado. La carga de solicitudes debe incluir los valores de clave de API, el identificador de
plan de uso asociado, los indicadores booleanos que indican que las claves están habilitadas
para el plan de uso y, posiblemente, los nombres y descripciones de las claves de API.
El siguiente ejemplo de la solicitud apikey:import añadirá tres claves de API (identificadas

mediante key, namey description) a un plan de uso (identificado mediante usageplanIds):
POST /apikeys?mode=import&format=csv&failonwarnings=fase HTTP/1.1

Content-Type: text/csv
Authorization: ...
289
key,name, description, enabled, usageplanIds

abcdef1234ghijklmnop8901234567, importedKey_1, firstone, tRuE, n371pt
abcdef1234ghijklmnop0123456789, importedKey_2, secondone, TRUE, n371pt
abcdef1234ghijklmnop9012345678, importedKey_3, , true, n371pt
Como resultado, se crearán tres recursos UsagePlanKey y se añadirán a UsagePlan.
También puede añadir claves de API a varios planes de uso de esta manera. Para ello, cambie
cada valor de la columna usageplanIds por una cadena separada por comas que contenga
los identificadores del plan de uso seleccionado incluidos entre comillas ("n371pt,m282qs" o
'n371pt,m282qs').
Administrar un plan de uso

El siguiente procedimiento describe cómo administrar un plan de uso.
Para administrar un plan de uso con la API REST
1. Llame a usageplan:by-id para obtener un plan de uso para un identificador de plan determinado. Para
ver los planes de uso disponibles, llame a apigateway:usage-plans.
2. Llame a usageplan:update para añadir una nueva etapa de API al plan, para sustituir una etapa de API
existente en el plan, para eliminar una etapa de API del plan o para modificar los límites de tarifas o
las cuotas.
3. Llame a usage:get para consultar los datos de uso en un intervalo de tiempo especificado.
4. Llame a usage:update para aplicar una extensión al uso actual en un plan de uso.
Probar planes de uso

A modo de ejemplo, vamos a utilizar la API PetStore, creada en Crear una API de API Gateway a
partir de un ejemplo (p. 9). Supongamos que la API está configurada para utilizar una clave de API de
Hiorr45VR...c4GJc. Los siguientes pasos describen cómo probar un plan de uso.
Para probar su plan de uso
• Realice una solicitud GET en el recurso Pets (/pets), con los parámetros de consulta ?
type=...&page=... de la API (por ejemplo, xbvxlpijch) en un plan de uso:
GET /testStage/pets?type=dog&page=1 HTTP/1.1

x-api-key: Hiorr45VR...c4GJc
Content-Type: application/x-www-form-urlencoded
Host: xbvxlpijch.execute-api.ap-southeast-1.amazonaws.com
X-Amz-Date: 20160803T001845Z
Authorization: AWS4-HMAC-SHA256 Credential={access_key_ID}/20160803/ap-southeast-1/
execute-api/aws4_request, SignedHeaders=content-type;host;x-amz-date;x-api-key,
Signature={sigv4_hash}
Note
Debe enviar esta solicitud al componente execute-api de API Gateway y proporcionar la
clave de API necesaria (por ejemplo, Hiorr45VR...c4GJc) en el encabezado x-api-key
necesario.
La respuesta, si se ejecuta correctamente, devuelve un código de estado 200 OK y una carga que
contiene los resultados solicitados del backend. Si olvidó establecer el encabezado x-api-key o lo
estableció con una clave incorrecta, obtendrá una respuesta 403 Forbidden. Por otra parte, si no
configuró el método para exigir una clave de API, probablemente obtendrá una respuesta 200 OK tanto
290
Mantener una API
si estableció el encabezado x-api-key correctamente como si no, y las limitaciones de solicitudes y

los límites de cuota del plan de uso se omitirán.
Ocasionalmente, cuando se produce un error interno que impide a API Gateway imponer limitaciones
de solicitudes o límites de cuota del plan de uso para la solicitud, API Gateway servirá la solicitud
sin aplicar dichos límites, pero registrará el mensaje de error Usage Plan check failed due to an
internal error en los logs de CloudWatch. Puede obviar este tipo de errores ocasionales.
Formato de archivo de clave de API de API Gateway

API Gateway puede importar claves de API de archivos externos con un formato de valores separados
por comas (CSV) y asociar las claves importadas a uno o varios planes de uso. El archivo importado
debe contener las columnas Name y Key. Los nombres de encabezado de columna no distinguen entre
mayúsculas y minúsculas, y las columnas pueden estar en cualquier orden, tal y como se muestra en el
ejemplo siguiente:
Key,name
apikey1234abcdefghij0123456789,MyFirstApiKey
Un valor de Key debe estar comprendido entre 30 y 128 caracteres.
Un archivo de claves de API puede tener las columnas Description, Enabledo UsagePlanIds, como se
muestra en el ejemplo siguiente:
Name,key,description,Enabled,usageplanIds
MyFirstApiKey,apikey1234abcdefghij0123456789,An imported key,TRUE,c7y23b
Cuando una clave está asociada a más de un plan de uso, el valor de UsagePlanIds es una cadena
separada por comas de los identificadores del plan de uso incluidos entre comillas simples o dobles, como
se muestra en el ejemplo siguiente:
Enabled,Name,key,UsageplanIds
true,MyFirstApiKey,apikey1234abcdefghij0123456789,"c7y23b,glvrsr"
Se pueden usar columnas no reconocidas, pero se omitirán. El valor predeterminado es una cadena vacía
o un valor booleano true.
La misma clave de API se puede importar varias veces con la versión más reciente sobrescribiendo la
anterior. Dos claves de API son idénticas si tienen el mismo valor de key.
Mantener una API en Amazon API Gateway

Temas
• Ver una lista de API en API Gateway (p. 291)
• Eliminar una API en API Gateway (p. 292)
• Eliminar un recurso en API Gateway (p. 292)
• Ver una lista de métodos en API Gateway (p. 293)
• Eliminar un método en API Gateway (p. 293)
Ver una lista de API en API Gateway

Usar la consola de API Gateway para ver una lista de API.
291
Eliminar una API
Temas
• Ver una lista de API con la consola de API Gateway (p. 292)
Requisitos previos
Ver una lista de API con la consola de API Gateway

2. Se muestra la lista de API.
Eliminar una API en API Gateway

Use la consola de API Gateway para eliminar una API.
Warning
Eliminar una API significa que ya no puede llamarla. Esta acción no se puede deshacer.
Temas
• Eliminar una API con la consola de API Gateway (p. 292)
Requisitos previos
• Debe haber implementado la API al menos una vez. Siga las instrucciones en Implementar una
API (p. 294).
Eliminar una API con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API que desea eliminar, elija Resources.
3. Elija Delete API.
4. Cuando se le pida que elimine la API, elija Ok.
Eliminar un recurso en API Gateway

Use la consola de API Gateway para eliminar un recurso.
Warning
Cuando se elimina un recurso, también se eliminan sus métodos y recursos secundarios.
La eliminación de un recurso puede dejar inservible la parte de la API correspondiente. La
eliminación de un recurso no se puede deshacer.
Eliminar un recurso con la consola de API Gateway

292
Ver una lista de métodos
2. En el cuadro que contiene el nombre de la API para el recurso que desea eliminar, elija Resources.
3. En el panel Resources, elija el recurso y, a continuación, elija Delete Resource.
Ver una lista de métodos en API Gateway

Usar la consola de API Gateway para ver una lista de métodos de un recurso.
Temas
• Ver una lista de métodos con la consola de API Gateway (p. 293)
Requisitos previos
• Debe tener métodos disponibles en API Gateway. Siga las instrucciones en Cree una API de API
Ver una lista de métodos con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API, elija Resources.
3. La lista de métodos se muestra en el panel Resources.
Tip
Es posible que tenga que elegir la flecha situada junto a uno o más recursos para mostrar
todos los métodos disponibles.
Eliminar un método en API Gateway

Use la consola de API Gateway para eliminar un método.
Warning
La eliminación de un método puede causar que parte de la API correspondiente quede inservible.
La eliminación de un método no se puede deshacer.
Eliminar un método con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API para el método, elija Resources.
3. En el panel Resources, elija la flecha situada junto al recurso del método.
4. Elija el método y después elija Delete Method.
293
Implementar una API en Amazon API

Gateway
Después de crear la API, debe implementarla para que los usuarios puedan llamarla. Una implementación
de la API representa una snapshot de API y los usuarios de la API podrán llamarla cuando se asocie a una
etapa. Implementar una API implica crear una implementación y una etapa y asociar la implementación con
la etapa.
Una etapa define una URL base única (con el formato https://{restapi-id}.execute-
api.{region}amazonaws.com/{stageName}) para que los usuarios llamen a la snapshot de la API
asociada. Usando diferentes combinaciones de etapa e implementación, puede permitir un control de
versiones más sencillo y robusto de la API.
Para cada etapa, puede optimizar el desempeño de la API ajustando los límites de solicitudes de nivel
de cuenta predeterminados y habilitando el almacenamiento en caché de la API. También puede activar
el registro de llamadas a la API en CloudTrail o CloudWatch y seleccionar un certificado cliente para que
el backend autentique las solicitudes de la API. Además, puede invalidar la configuración de nivel de
etapa para los distintos métodos y definir variables de etapa para pasar contextos de entorno específicos
de la etapa a la integración de la API en tiempo de ejecución. En una etapa de API, puede exportar las
definiciones de API y generar un SDK para que los usuarios llamen a la API a través de un lenguaje de
programación compatible.
Cada vez que actualiza una API o su configuración de etapa, debe volver a implementar la API creando
una nueva snapshot de la API y asociando la nueva implementación a una etapa nueva o existente para
que los cambios estén disponibles para los usuarios.
Para simplificar la URL base predeterminada de una API para sus usuarios, puede crear un nombre
de dominio personalizado (por ejemplo, myapi.mydomain.com) para sustituir el nombre de host de la
API. Con el nombre de dominio personalizado de ejemplo, la URL base de la API pasa a ser https://
myapi.mydomain.com/stage.
En esta sección se explica cómo realizar estas tareas relacionadas con la implementación, utilizando la
consola de API Gateway o llamando a la API REST de API Gateway. Para utilizar otras herramientas,
consulte la documentación de CLI de AWS o un SDK de AWS.
Para monetizar su implementación de la API, puede usar la integración de API Gateway con AWS
Marketplace para comercializar la API como un producto de software como servicio (SaaS). Las
instrucciones se incluyen también en este capítulo.
Temas
• Implementar una API desde la consola de API Gateway (p. 295)
294
Implementar una API desde la consola
• Administrar una etapa de API (p. 296)

• Optimizar el desempeño de la API (p. 299)
• Configurar variables de etapa para la implementación de la API (p. 307)
• Exportar una API de API Gateway (p. 317)
• Generar el SDK para una API (p. 319)
• Configurar nombres de dominio personalizados para el nombre de host de la API (p. 332)
• Vender su API de API Gateway a través de AWS Marketplace (p. 343)
Implementar una API desde la consola de API

Gateway
Debe haber creado una API antes de implementarla por primera vez. Para obtener más información,
consulte Crear una API (p. 73).
Temas
• Implementar una API en una etapa (p. 295)
• Actualizar la configuración de etapas de una implementación (p. 295)
• Establecer variables de etapa para la implementación (p. 296)
• Asociación de una etapa a una implementación diferente (p. 296)
Implementar una API en una etapa

La consola de API Gateway le permite implementar una API creando una implementación y asociándola a
una etapa nueva o existente.
Note
Para asociar una etapa en API Gateway con otra implementación, consulte Asociación de una
etapa a una implementación diferente (p. 296) en su lugar.

2. En el panel de navegación APIs, elija la API que desea implementar.
3. En el panel de navegación Resources, elija Actions.
4. En el menú desplegable Actions, elija Deploy API.
5. En el cuadro de diálogo Deploy API, elija una entrada en la lista desplegable Deployment stage.
6. Si elige [New Stage], escriba un nombre en Stage name y, de forma opcional, proporcione una
descripción de la etapa y la implementación en Stage description y Deployment description. Si elige
una etapa existente, tal vez desee proporcionar una descripción de la nueva implementación en
Deployment description.
7. Elija Deploy para implementar la API en la etapa especificada con la configuración de etapa
predeterminada.
Actualizar la configuración de etapas de una

implementación
Una vez que se implementa una API, puede modificar la configuración de las etapas para habilitar o
deshabilitar el almacenamiento en caché, el registro o los límites de solicitudes de la API. También puede
295
Establecer variables de etapa para la implementación
elegir un certificado cliente para que el backend autentique API Gateway y definir variables de etapa para
pasar el contexto de implementación a la integración de la API en tiempo de ejecución. Para obtener más
información, consulte Actualizar la configuración de etapas (p. 297).
Note
Si la configuración actualizada, como la habilitación del registro, requiere un nuevo rol de IAM,
puede añadir el rol de IAM necesario sin tener que volver a implementar la API. Sin embargo,
este nuevo rol de IAM puede tardar unos minutos en entrar en vigor. Antes de que esto ocurra,
los registros de seguimiento de las llamadas a la API no se registrarán aunque haya habilitado la
opción de registro.
Establecer variables de etapa para la implementación

Para una implementación, puede definir o modificar variables de etapa para pasar datos específicos de
la implementación a la integración de la API en tiempo de ejecución. Puede hacer esto en la pestaña
Stage Variables en Stage Editor. Para obtener más información, consulte las instrucciones de Configurar
variables de etapa para la implementación de la API (p. 307).
Asociación de una etapa a una implementación

diferente
Como una implementación representa una snapshot de API y una etapa define una ruta en una snapshot,
puede elegir diferentes combinaciones de etapas de implementación para controlar la forma en que los
usuarios llaman a diferentes versiones de la API. Esto resulta útil, por ejemplo, cuando desea restaurar el
estado de la API a una implementación anterior o combinar una "ramificación privada" de la API con una
pública.
El siguiente procedimiento muestra cómo hacer esto utilizando el Stage Editor en la consola de API
Gateway. Se supone que debe haber implementado una API más de una vez.
1. Si aún no está en Stage Editor, elija la etapa cuya implementación desea actualizar en la opción
Stages de la API en el panel de navegación principal APIs.
2. En la pestaña Deployment History, elija la opción que aparece junto a la implementación que desea
que utilice la etapa.
3. Elija Change Deployment.
Administrar una etapa de API

Temas
• Asociar una implementación existente con una nueva etapa (p. 296)
• Actualizar la configuración de etapas (p. 297)
• Eliminar una etapa de una API (p. 299)
Asociar una implementación existente con una nueva

etapa
Después de la implementación inicial, puede añadir más etapas y asociarlas con las implementaciones
existentes. Puede utilizar la consola de API Gateway para crear y utilizar una nueva etapa o elegir
una etapa existente mientras implementa una API. En general, puede agregar una nueva etapa a la
296
Actualizar la configuración de etapas
implementación de una API antes de volver a implementar la API. Para hacerlo a través de la consola de
API Gateway, siga las instrucciones que se indican a continuación.

2. En el panel de navegación APIs, elija Stages en una API.
3. En el panel de navegación Stages, elija Create.
4. En Create Stage, escriba una nombre de etapa, por ejemplo, prod, para Stage name.
5. Si lo desea, escriba una descripción de etapa para Stage description.
6. En la lista desplegable Deployment, seleccione la fecha y la hora de la implementación de la API
existente que vaya a asociar con esta etapa.

Después de una implementación correcta de una API, la etapa se rellena con la configuración
predeterminada. Puede utilizar la consola o la API REST de API Gateway para cambiar la configuración de
las etapas, incluido el almacenamiento en caché de la API y el registro. A continuación, mostramos cómo
hacer esto a través del Stage Editor de la consola de API Gateway.
Actualizar la configuración de etapas mediante la consola de API

Gateway
Asegúrese de que ya haya implementado la API y creado una etapa al menos una vez antes de continuar.

2. En el panel APIs, elija la API para la que desea actualizar la configuración de etapas y, a continuación,
elija Stages.
3. En el panel Stages, elija el nombre de la etapa.
4. En el panel Stage Editor, elija la pestaña Settings.
5. Para habilitar el almacenamiento en caché de la API, seleccione la opción Enable API cache en
la sección Cache Settings. A continuación, elija las opciones y los valores asociados que desee
para Cache capacity, Encrypt cache data, Cache time-to-live (TTL), así como los requisitos de la
invalidación de caché para cada clave. Para obtener más información sobre la configuración de caché
de nivel de etapa, consulte Habilitar el almacenamiento en caché de la API (p. 301).
Important
Al seleccionar esta opción, puede que se realicen cargos en su cuenta de AWS por el
almacenamiento en caché de la API.
Tip
Puede invalidar la configuración de caché de nivel de etapa habilitada. Para ello, expanda
la etapa en el panel de navegación secundario Stages y elija un método. A continuación,
en el editor de etapas, elija la opción Override for this method para Settings. En el área
Cache Settings que aparece, desactive Enable Method Cache o personalice las opciones que
desee, antes de elegir Save Changes. Para obtener más información sobre la configuración
de caché de nivel de método, consulte Habilitar el almacenamiento en caché de la
API (p. 301).
6. Para habilitar Amazon CloudWatch Logs para todos los métodos asociados a esta etapa de esta API
de API Gateway, haga lo siguiente:
a. En la sección CloudWatch Settings, seleccione la opción Enable CloudWatch Logs Logs.
297
Tip
Para habilitar la configuración de CloudWatch de nivel de método, expanda la etapa en

el panel de navegación secundario Stages, elija todos los métodos que desee y, en el
editor de etapas, elija Override for this method para Settings. En el área CloudWatch
Settings que aparece, asegúrese de seleccionar Log to CloudWatch Logs y todas las
demás opciones que desee, antes de elegir Save Changes.
Important
Se realizará un cargo en su cuenta por obtener acceso a las métricas de CloudWatch de

nivel de método, pero no por las métricas de nivel de API o de etapa.
b. En Log level, elija ERROR para escribir únicamente entradas de nivel de error en CloudWatch
Logs o elija INFO para incluir todos los eventos ERROR, así como eventos informativos
adicionales.
c. Para registrar toda la solicitud de llamada a la API y la información de respuesta, seleccione Log
full requests/responses data. No se registrará información confidencial a menos que se seleccione
la opción Log full requests/responses data.
d. Para que API Gateway registre en CloudWatch las métricas de la API de API calls, Latency,
Integration latency, 400 errors y 500 errors, seleccione la opción Enable Detailed
CloudWatch Metrics. Para obtener más información sobre CloudWatch, consulte la Guía del
usuario de Amazon CloudWatch.
e. Elija Save Changes. La nueva configuración se aplicará después de una nueva implementación.
Important
Para habilitar CloudWatch Logs para todos o solo algunos de los métodos, debe
especificar el ARN de un rol de IAM para el que API Gateway haya otorgado permiso
para escribir información en CloudWatch Logs en nombre del usuario de IAM. Para
ello, elija Settings en el panel de navegación principal APIs. A continuación, escriba el
ARN de un rol de IAM en el campo de texto CloudWatch log role ARN. Para escenarios
de aplicaciones comunes, el rol de IAM podría asociar la política administrada de
AmazonAPIGatewayPushToCloudWatchLogs, que contiene la siguiente instrucción de
política de acceso:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents"
],
"Resource": "*"
}
]
}
El rol de IAM también debe incluir la siguiente instrucción de relación de confianza:
{
"Version": "2012-10-17",
298
Eliminar una etapa
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
Para obtener más información sobre CloudWatch, consulte la Guía del usuario de
Amazon CloudWatch.
7. Para definir la limitación de solicitudes en el nivel de etapa para todos los métodos asociados a esta
API, haga lo siguiente en la sección Default Method Throttling:
a. En Rate, escriba el número máximo de solicitudes de estado estable de nivel de etapa por
segundo que API Gateway puede realizar sin devolver una respuesta 429 Too Many Requests.
Este límite de nivel de etapa no debe ser superior al límite de nivel de cuenta (p. 300)
especificado en Límites de API Gateway para configurar y ejecutar una API (p. 471).
b. En Burst, escriba el número máximo de solicitudes simultáneas de nivel de etapa que API
Gateway puede realizar sin devolver una respuesta 429 Too Many Requests. Este límite de
ráfaga de nivel de etapa no debe ser superior al límite de ráfaga de nivel de cuenta (p. 300)
especificado en Límites de API Gateway para configurar y ejecutar una API (p. 471).
8. Para invalidar la limitación de solicitudes de nivel de etapa de los distintos métodos, expanda la etapa
bajo el panel de navegación secundario Stages, elija el método que desee y, en el editor de etapas,
elija Override for this method para Settings. En el área Default Method Throttling, seleccione las
opciones apropiadas.
Eliminar una etapa de una API

Cuando ya no necesite una etapa, puede eliminarla para evitar pagar por recursos que no utiliza. A
continuación, se explica cómo utilizar la consola de API Gateway para eliminar una etapa .
Warning
La eliminación de una etapa puede provocar que parte o la totalidad de la API correspondiente
quede inservible para los intermediarios de la API. La eliminación de una etapa no se puede
deshacer, pero puede volver a crear la etapa y asociarla a la misma implementación.
Eliminar una etapa con la consola de API Gateway

2. En el cuadro que contiene el nombre de la API para la etapa, elija Stages.
3. En el panel Stages, elija la etapa que desea eliminar y, a continuación, elija Delete Stage.
Optimizar el desempeño de la API

Puede optimizar el desempeño de la API limitando las solicitudes para evitar que la API se colapse y
habilitando el almacenamiento en caché de la API para mejorar su capacidad de respuesta.
299
Limitar las solicitudes de la API
Temas
• Limitar las solicitudes de la API para mejorar el desempeño (p. 300)
• Habilitar el almacenamiento en caché de la API para mejorar la capacidad de respuesta (p. 301)
Limitar las solicitudes de la API para mejorar el

desempeño
Para evitar que la API resulte colapsada por un enorme número de solicitudes, Amazon API Gateway
limita las solicitudes a la API utilizando el algoritmo de bucket de tokens, donde un token da cuenta de una
solicitud. En concreto, API Gateway establece un ratio de solicitudes en estado estable y una ráfaga de
envíos de solicitudes para todas las API de su cuenta. En el algoritmo del bucket de tokens, una ráfaga es
el tamaño máximo del bucket.
Cuando los envíos de solicitudes superan los límites de ratio de solicitudes en estado estable y de ráfaga,
API Gateway no acepta las solicitudes que exceden el límite y devuelve respuestas de error 429 Too Many
Requests al cliente. Tras capturar estas excepciones, el cliente puede reenviar las solicitudes que han
producido un error de acuerdo con los límites de ratio y los límites de solicitudes de API Gateway.
Como desarrollador de la API, puede configurar los límites para distintas etapas o métodos de la API
con el fin de mejorar el desempeño general de todas las API de su cuenta. También puede activar
planes de uso (p. 280) para restringir los envíos de solicitudes de cliente a determinados ratios y cuotas
de solicitudes. De esta manera, restringirá los envíos generales de solicitudes para que no superen
significativamente las limitaciones de nivel de cuenta.
Limitaciones de nivel de cuenta

De forma predeterminada, API Gateway limita el ratio de solicitudes en estado estable a 10 000 solicitudes
por segundo (sps). Limita la ráfaga (es decir, el tamaño máximo del bucket) a 5 000 solicitudes en
todas las API dentro de una cuenta de AWS. En API Gateway, el límite de ráfaga se corresponde con el
número máximo de envíos de solicitudes simultáneas que API Gateway puede abordar en un momento
determinado sin devolver respuestas de error 429 Too Many Requests.
Para ayudarle a entender estos límites de la limitación controlada, aquí se presentan varios ejemplos, dada
la tasa de nivel de cuenta y límites de ráfaga predeterminados:
• Si un intermediario envía 10 000 solicitudes en un período de un segundo de manera uniforme (por

ejemplo, 10 solicitudes cada milisegundo), API Gateway procesa todas las solicitudes sin cancelar
ninguna.
• Si el intermediario envía 10 000 solicitudes en el primer milisegundo, API Gateway sirve 5 000 de estas
solicitudes y limita el resto al periodo de un segundo.
• Si el intermediario envía 5 000 solicitudes en el primer milisegundo y, a continuación, distribuye de
manera uniforme otras 5 000 solicitudes en los 999 milisegundos restantes (por ejemplo, unas 5
solicitudes cada milisegundo), API Gateway procesa las 10 000 solicitudes en el periodo de un segundo
sin devolver respuestas de error 429 Too Many Requests.
• Si el intermediario envía 5 000 solicitudes en el primer milisegundo y espera hasta el milisegundo
101 para enviar otras 5 000, API Gateway procesa 6 000 solicitudes y limita el resto al periodo de un
segundo. Esto ocurre porque, a una velocidad de 10 000 rps, API Gateway ha servido 1 000 solicitudes
después de los primeros 100 milisegundos y, por lo tanto, ha vaciado el bucket por la misma cantidad.
Del próximo pico de 5 000 solicitudes, 1 000 llenan el bucket y están en cola para ser procesadas. Las
otras 4 000 superan la capacidad de bucket y se descartan.
• Si el intermediario envía 5 000 solicitudes en el primer milisegundo, envía 1 000 solicitudes en
milisegundo 101 y, a continuación, distribuye de manera uniforme otras 4 000 solicitudes a través de los
300
Habilitar el almacenamiento en caché de la API
899 milisegundos restantes, API Gateway procesa las 10 000 solicitudes en el periodo de un segundo
sin limitación controlada.
De forma más general, en un momento dado, cuando un bucket contiene b y su capacidad máxima es B,
el número máximo de tokens adicionales que se pueden añadir al bucket es #=B-b. Este número máximo
de tokens adicionales se corresponde con el número máximo de solicitudes simultáneas adicionales que
un cliente puede enviar sin recibir respuestas de error 429. En general, # varía con el tiempo. El valor oscila
entre cero cuando el bucket está lleno (es decir, b=B) y B cuando el bucket está vacío (es decir, b=0). El
intervalo depende de la velocidad de procesamiento de las solicitudes, que es la velocidad a la que los
tokens se eliminan del bucket, y de la velocidad del límite de ratio, que es la velocidad a la que los tokens
se añaden al bucket.
A continuación, se muestra un esquema de los comportamientos generales de #, el número máximo de

solicitudes simultáneas adicionales, como una función de tiempo. El esquema asume que los tokens de
bucket disminuyen a una tasa combinada de r a partir de un bucket vacío.
Los límites de ratio y ráfaga de nivel de cuenta se pueden aumentar previa solicitud. Para solicitar un
aumento de los límites de nivel de cuenta, póngase en contacto con el Centro de AWS Support. Para
obtener más información, consulte Límites de API Gateway (p. 471).
Limitación controlada de método predeterminada

Como propietario de la API, puede definir la limitación controlada del método predeterminado para anular
los límites de limitación controlada de las solicitudes de nivel de cuenta de una determinada etapa o de
los métodos individuales de una API. Los límites de la limitación controlada del método predeterminado
se rigen por los límites de ratio de nivel de cuenta, aunque defina los límites de la limitación controlada del
método predeterminado por encima de los de nivel de cuenta.
Puede definir límites de la limitación controlada del método predeterminado mediante la consola de API
Gateway o llamando a la API REST de API Gateway (p. 470). Para obtener instrucciones sobre cómo
utilizar la consola, consulte Actualizar la configuración de etapas (p. 297).
Habilitar el almacenamiento en caché de la API para

mejorar la capacidad de respuesta
Puede habilitar el almacenamiento en caché de la API en Amazon API Gateway para almacenar en
caché la respuesta del punto de enlace. Con el almacenamiento en caché, puede reducir el número de
llamadas realizadas al punto de enlace y mejorar también la latencia de las solicitudes a la API. Cuando
habilita el almacenamiento en caché para una etapa, API Gateway almacena en caché las respuestas del
301
punto de enlace durante el período de tiempo de vida (TTL) especificado, en segundos. A continuación,
API Gateway responde a la solicitud buscando la respuesta del punto de enlace en la caché en lugar de
realizar una solicitud al punto de enlace. El valor de TTL predeterminado para el almacenamiento en caché
de la API es de 300 segundos. El valor de TTL máximo es de 3 600 segundos. TTL = 0 significa que el
almacenamiento en caché está deshabilitado.
Note
El almacenamiento en caché se cobra por hora y no está disponible para la capa de uso gratuito
de AWS.
Habilitar el almacenamiento en caché de Amazon API Gateway

En API Gateway, puede habilitar el almacenamiento en caché para todos los métodos de una etapa
especificada. Al habilitar el almacenamiento en caché, debe elegir una capacidad de caché. En general,
una capacidad mayor ofrece un mejor desempeño, pero también cuesta más.
API Gateway permite el almacenamiento en caché creando una instancia de caché dedicada. Este proceso
puede tardar hasta cuatro minutos.
API Gateway cambia la capacidad de almacenamiento en caché eliminando al instancia de caché y

volviendo a crear una nueva con una capacidad modificada. Todos los datos almacenados en la memoria
caché existente se eliminan.
En la consola de API Gateway, el almacenamiento en caché se configura en la pestaña Settings de un

Stage Editor con nombre.
Para configurar el almacenamiento en caché de la API para una determinada etapa:
1. Vaya a la consola de API Gateway.

2. Vaya al Stage Editor de la etapa para la que desea habilitar el almacenamiento en caché.
3. Elija Settings.
4. Seleccione Enable API cache.
5. Espera a que se complete la creación de la caché.
Note
La creación o eliminación de una memoria caché tarda unos cuatro minutos en completarse en
API Gateway. Cuando se crea la caché, el valor de Cache status cambia de CREATE_IN_PROGRESS
a AVAILABLE. Cuando se completa la eliminación de la caché, el valor de Cache status cambia de
DELETE_IN_PROGRESS a una cadena vacía.
Al habilitar el almacenamiento en caché en Cache Settings para una etapa, se habilita el almacenamiento
en caché para todos los métodos de dicha etapa.
Si desea comprobar si el almacenamiento en caché funciona según lo previsto, tiene dos opciones
generales:
• Revise las métricas de CacheHitCount y CacheMissCount de CloudWatch para la API y la etapa.

• Inserte una marca de tiempo en la respuesta.
Note
No debe utilizar el encabezado X-Cache de la respuesta de CloudFront para determinar si la API

se está sirviendo desde la instancia de caché de API Gateway.
302
Invalidar el almacenamiento en caché de nivel de etapa de API

Gateway para el almacenamiento en caché de nivel de método
Si desea más detalle en la configuración del almacenamiento en caché, puede invalidar el almacenamiento
en caché de nivel de etapa para los distintos métodos. Esto incluye deshabilitar el almacenamiento en
caché de un determinado método, aumentar o disminuir su periodo de TTL y activar o desactivar el cifrado
de la respuesta almacenada en caché. Si prevé que un método va a recibir información confidencial en sus
respuestas, en Cache Settings, elija Encrypt cache data.
Para configurar los métodos individuales de almacenamiento en caché de la API para utilizar la
consola:
1. Elija Stages de una API desde el panel de navegación principal.

2. Elija un método de la API en la etapa elegida, desde el panel de navegación secundario.
3. Elija Override for this method en Settings.
4. Elija la configuración apropiada en la sección Cache Settings (que se muestra únicamente si el
almacenamiento en caché de nivel de etapa está habilitado).
Usar parámetros de método o integración como claves de caché

para indexar las respuestas almacenadas en caché
Cuando un método o una integración almacenados en caché tienen parámetros, que pueden adoptar
la forma de encabezados personalizados, rutas URL o cadenas de consulta, puede utilizar algunos o
todos los parámetros para crear claves de caché. API Gateway puede almacenar en memoria caché las
respuestas del método, en función de los valores de los parámetros utilizados.
Suponga, por ejemplo, que tiene una solicitud con el siguiente formato:
GET /users?type=... HTTP/1.1

host: example.com
...
En esta solicitud, type puede tomar un valor de admin o regular. Si incluye el parámetro type como parte
de la clave de caché, las respuestas de GET /users?type=admin se almacenarán en caché por separado
de las de GET /users?type=regular.
Cuando una solicitud de método o integración toma más de un parámetro, puede elegir algunos o todos
los parámetros para crear la clave de caché. Por ejemplo, puede incluir solamente el parámetro type en la
clave de caché para la siguiente solicitud, realizada en el orden indicado dentro de un período de TTL:
GET /users?type=admin&department=A HTTP/1.1

host: example.com
...
La respuesta de esta solicitud se almacenará en caché y se utilizará para atender la siguiente solicitud:
GET /users?type=admin&department=B HTTP/1.1

host: example.com
...
303
Para incluir un parámetro de solicitud de método o integración como parte de una clave de caché en la
consola de API Gateway, seleccione Caching después de añadir el parámetro.
Vaciar la caché de etapas de API en API Gateway

Cuando el almacenamiento en caché de la API está habilitado, puede vaciar toda la caché de etapas de
API para asegurarse de que los clientes de la API obtengan las respuestas más recientes de los puntos de
enlace de integración.
Para vaciar la caché de etapas de la API, puede elegir el botón Flush Cache en la pestaña Stage de la
consola de API Gateway. Tenga en cuenta que el vaciado de la caché hará que las respuestas a las
solicitudes siguientes se sirvan desde el backend hasta que se vuelva a crear la caché. Durante este
período, el número de solicitudes enviadas al punto de enlace de integración puede aumentar. Esto puede
afectar a la latencia total de la API.
Invalidar una entrada de caché de API Gateway

Un cliente de la API puede invalidar una entrada de caché y volver a cargarla desde el punto de enlace de
integración para las distintas solicitudes. El cliente debe enviar una solicitud que contenga el encabezado
Cache-Control: max-age=0. El cliente recibe la respuesta directamente del punto de enlace de integración
en lugar de la caché, siempre que el usuario esté autorizado para ello. Esto sustituye la entrada de caché
existente por la nueva respuesta, que se obtiene del punto de enlace de integración.
Para conceder permiso a un intermediario, asocie una política con el siguiente formato a un rol de
ejecución de IAM del usuario.
304
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:InvalidateCache"
],
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage-name/HTTP-VERB/resource-path-
specifier"
]
}
]
}
Esta política permite al servicio de ejecución de API Gateway invalidar la caché para las solicitudes en
el recurso o recursos especificados. Para especificar un grupo de recursos de destino, utilice el carácter
comodín (*) para account-id, api-id y otras entradas en el valor de ARN de Resource. Para obtener más
información sobre cómo establecer permisos para el servicio de ejecución de API Gateway, consulte Usar
permisos de IAM (p. 221).
Si no impone una política InvalidateCache, cualquier cliente puede invalidar la caché de la API. Si todos
o la mayoría de los clientes invalidan la caché de la API, podría aumentar considerablemente la latencia de
la API.
Cuando se aplica la política, el almacenamiento en caché está habilitado y se requiere autorización, puede
controlar la forma en que se administran las solicitudes no autorizadas eligiendo una opción de Handle
unauthorized requests en la consola de API Gateway.
305
Las tres opciones producen los siguientes comportamientos:
• Fail the request with 403 status code: devuelve una respuesta 403 Unauthorized.
Para establecer esta opción mediante la API, use FAIL_WITH_403.

• Ignore cache control header; Add a warning in response header: procesa la solicitud y añade un
encabezado de advertencia en la respuesta.
Para establecer esta opción mediante la API, use SUCCEED_WITH_RESPONSE_HEADER.

• Ignore cache control header:: procesa la solicitud y no añade un encabezado de advertencia en la
respuesta.
Para establecer esta opción mediante la API, use SUCCEED_WITHOUT_RESPONSE_HEADER.
306
Configurar variables de etapa
Configurar variables de etapa para la

implementación de la API
Las variables de etapa son pares de nombre-valor que puede definir como atributos de configuración
asociados a una etapa de implementación de una API. Actúan como variables de entorno y se pueden usar
en la configuración y las plantillas de asignación de la API.
Por ejemplo, puede definir una variable de etapa en una configuración de etapa y, a continuación,
configurar su valor como la cadena URL de una integración HTTP para un método de la API.
Posteriormente, puede hacer referencia a la cadena URL mediante el nombre de la variable de etapa
asociada desde la configuración de la API. De esta forma, puede utilizar la misma configuración de API con
un punto de enlace distinto en cada etapa restableciendo el valor de la variable de etapa en las direcciones
URL correspondientes. También puede tener acceso a las variables de etapa de las plantillas de mapeo o
transmitir parámetros de configuración al backend de AWS Lambda o HTTP.
Para obtener más información sobre las plantillas de asignación, consulte Funciones y variables integradas
en la plantilla de asignación (p. 158).
Casos de uso
Con las etapas de implementación de API Gateway, puede administrar varias etapas de lanzamiento
para cada API, como alfa, beta y producción. Con las variables de etapa puede configurar una etapa
de implementación de la API para interactuar con distintos puntos de enlace del backend. Por ejemplo,
la API puede transmitir una solicitud GET como un proxy HTTP al host web del backend (por ejemplo,
http://example.com). En este caso, el host web del backend está configurado en una variable de etapa,
de modo que cuando los desarrolladores llaman a su punto de enlace de producción, API Gateway llama
a example.com. Cuando llama al punto de enlace beta, API Gateway utiliza el valor configurado en la
variable de etapa para la etapa beta y llama a otro host web (por ejemplo, beta.example.com). Asimismo,
las variables de etapa se pueden utilizar para especificar otro nombre de función AWS Lambda para cada
etapa de la API.
También puede utilizar las variables de etapa para pasar parámetros de configuración a una función
Lambda a través de sus plantillas de asignación. Por ejemplo, es posible que desee volver a utilizar la
misma función Lambda para varias etapas de la API, pero esta vez la función debe leer los datos de
una tabla de Amazon DynamoDB diferente en función de la etapa a la que se llame. En las plantillas de
asignación que generan la solicitud de la función Lambda, puede utilizar variables de etapa para pasar el
nombre de la tabla a Lambda.
Ejemplos
Para utilizar una variable de etapa para personalizar el punto de enlace de integración HTTP, primero
debe configurar una variable de etapa de un nombre especificado ( por ejemplo, url) y, a continuación,
asignarle un valor (p. ej., example.com). A continuación, desde la configuración del método, configure una
integración de proxy HTTP, y en lugar de introducir la dirección URL del punto de enlace, puede indicar a
API Gateway que use el valor de la variable de etapa, http://${stageVariables.url}. Este valor indica
a API Gateway que sustituya la variable de etapa ${} en tiempo de ejecución, en función de la etapa que
esté ejecutando la API. Puede hacer referencia a variables de etapa de forma similar para especificar un
nombre de función Lambda, una ruta de proxy de servicio de AWS o el ARN de un rol de AWS en el campo
de credenciales.
Cuando especifica un nombre de función Lambda como un valor de variable de etapa, debe configurar los
permisos en la función Lambda manualmente. Para ello, puede utilizar la AWS Command Line Interface.
aws lambda add-permission --function-name arn:aws:lambda:XXXXXX:your-lambda-function-

name --source-arn arn:aws:execute-api:us-east-1:YOUR_ACCOUNT_ID:api_id/*/HTTP_METHOD/
307
Establecer variables de etapa
resource --principal apigateway.amazonaws.com --statement-id apigateway-access --action

lambda:InvokeFunction
El siguiente ejemplo asigna permiso a API Gateway para invocar una función Lambda denominada
helloWorld alojada en la región EE.UU. Oeste (Oregón) de una cuenta de AWS en nombre del método de
la API.
arn arn:aws:execute-api:us-west-2:123123123123:bmmuvptwze/*/GET/hello
Este el mismo comando que cuando se usa la AWS CLI.
aws lambda add-permission --function-name arn:aws:lambda:us-

east-1:123123123123:function:helloWorld --source-arn arn:aws:execute-api:us-
west-2:123123123123:bmmuvptwze/*/GET/hello --principal apigateway.amazonaws.com --
statement-id apigateway-access --action lambda:InvokeFunction
Establecer variables de etapa mediante la consola de

Amazon API Gateway
En este tutorial, aprenderá a configurar variables de etapa para dos etapas de implementación de una
API de ejemplo mediante la consola de Amazon API Gateway. Antes de comenzar, asegúrese de que se
cumplen los siguientes requisitos previos:
• Debe haber implementado la API al menos una vez. Siga las instrucciones en Implementar una
API (p. 294).
• Debe haber creado la primera etapa de una API implementada. Siga las instrucciones en Asociar una
implementación existente con una nueva etapa (p. 296).
Para declarar variables de etapa mediante la consola de API Gateway

2. Cree una API y cree un método GET en el recurso raíz de la API, si aún no lo ha hecho. Establezca el
valor de Endpoint URL de HTTP como "http://${stageVariables.url}" y, a continuación, elija Save.
3. Elija Deploy API. Elija New Stage y escriba"beta" para Stage name. Elija Deploy.
308
Establecer variables de etapa
4. En el panel beta Stage Editor, elija la pestaña Stage Variables y, a continuación, elija Add Stage
Variable.
5. Escriba la cadena "url" en el campo Name y "httpbin.org/get" en el campo Value. Elija el icono de
marca de verificación para guardar la configuración de la variable de etapa.
6. Repita el paso anterior para añadir dos variables de etapa más: version y function. Establezca sus
valores en "v-beta" y"HelloWorld", respectivamente.
Note
Cuando configure una función Lambda como el valor de una variable de etapa, utilice el
nombre local de la función y, si es posible, incluya su alias o especificación de versión, como
en HelloWorld, HelloWorld:1 o HelloWorld:alpha. No utilice el ARN de la función (por
ejemplo, arn:aws:lambda:us-east-1:123456789012:function:HelloWorld). La consola
de API Gateway asume que el valor de la variable de etapa de una función Lambda es el
nombre de función incompleto y expandirá la variable de etapa especificada en un ARN.
7. En el panel de navegación Stages, elija Create. En Stage name, escriba prod. Seleccione una
implementación reciente en Deployment y, a continuación, elija Create.
309
Usar variables de etapa
8. Al igual que con la etapa beta, establezca las mismas tres variables de etapa (url, version y function)
en diferentes valores ("petstore-demo-endpoint.execute-api.com/petstore/pets", "v-prod" y
"HelloEveryone"), respectivamente.
Usar variables de etapa de Amazon API Gateway

Puede utilizar variables de etapa de API Gateway para tener acceso a los backends HTTP y Lambda para
diferentes etapas de implementación de la API y para transmitir metadatos de configuración específicos de
la etapa en un backend HTTP como un parámetro de consulta y en una función Lambda como una carga
generada en una plantilla de mapeo de entrada.
Requisitos previos
Debe crear dos etapas con una variable url establecida en dos puntos de enlace HTTP diferentes: una
variable de etapa function asignada a dos funciones Lambda diferentes y una variable de etapa version
que contenga los metadatos específicos de la etapa. Siga las instrucciones en Establecer variables de
etapa mediante la consola de Amazon API Gateway (p. 308).
Acceso a un punto de enlace HTTP a través de una API con una

variable de etapa
1. En el panel de navegación Stages, elija beta. En beta Stage Editor, elija el enlace Invoke URL.
Comenzará la solicitud GET de la etapa beta en el recurso raíz de la API.
Note
El enlace Invoke URL apunta al recurso raíz de la API en su etapa beta. Al navegar a la
dirección URL eligiendo el enlace se llama al método GET de la etapa beta en el recurso
raíz. Si los métodos se definen en recursos secundarios y no en el propio recurso raíz, al
elegir el enlace Invoke URL se devolverá una respuesta de error {"message":"Missing
Authentication Token"}. En este caso, debe añadir el nombre de un recurso secundario
específico al enlace Invoke URL.
2. La respuesta obtenida de la solicitud GET de la etapa beta se muestra a continuación. También puede
verificar el resultado usando un navegador para ir a http://httpbin.org/get. Este valor se asignó a la
variable url en la etapa beta. Las dos respuestas son idénticas.
3. En el panel de navegación Stages, elija la etapa prod. En prod Stage Editor, elija el enlace Invoke
URL. Comenzará la solicitud GET de la etapa prod en el recurso raíz de la API.
4. La respuesta obtenida de la solicitud GET de la etapa prod se muestra a continuación. También
puede verificar el resultado usando un navegador para ir a http://petstore-demo-endpoint-execute-
api.com/petstore/pets. Este valor se asignó a la variable url en la etapa prod. Las dos respuestas son
idénticas.
Transmitir metadatos específicos de una etapa a un backend

de HTTP a través de una variable de etapa en una expresión de
parámetro de consulta
Este procedimiento describe cómo utilizar el valor de una variable de etapa en una expresión de parámetro
de consulta para pasar los metadatos específicos en una etapa a un backend HTTP. Utilizaremos la
variable de etapa version declarada en Establecer variables de etapa mediante la consola de Amazon API
Gateway (p. 308).
310
1. En el panel de navegación Resource, elija el método GET. Para añadir un parámetro de cadena de
consulta a la URL del método, en Method Execution, elija Method Request. Escriba version para el
nombre del parámetro.
2. En Method Execution elija Integration Request. Edite el valor Endpoint URL para añadir ?version=
${stageVariables.version} al valor de URL definido anteriormente, que, en este caso, también se
expresa con la variable de etapa url. Elija Deploy API para implementar estos cambios.
311
3. En el panel de navegación Stages, elija la etapa beta. En beta Stage Editor, verifique que la etapa
actual está en la implementación más reciente y, a continuación, elija el enlace Invoke URL.
Note
Utilizamos la etapa beta aquí porque el punto de enlace HTTP, tal como lo especifica la
variable url, "http://httpbin.org/get", acepta expresiones de parámetro de consulta y las
devuelve como el objeto args en su respuesta.
4. La respuesta se muestra a continuación. Observe que el valor v-beta, asignado a la variable de etapa
version, se transmite al backend como el argumento version.
312
Llamar a la función Lambda a través de la API con una variable

de etapa
Este procedimiento describe cómo utilizar una variable de etapa para llamar a una función Lambda
como un backend de la API. Utilizaremos la variable de etapa function declarada anteriormente. Para
obtener más información, consulte Establecer variables de etapa mediante la consola de Amazon API
Gateway (p. 308).
1. En el panel Resources, cree un recurso secundario /lambdasv1 en el directorio raíz y, a continuación,

cree un método GET en el recurso secundario. Establezca Integration type en Lambda Function, y en
Lambda Function escriba ${stageVariables.function}. Seleccione Save.
Tip
Cuando vea Add Permision to Lambda Function, anote el comando de la CLI de AWS antes
de elegir OK. Debe ejecutar el comando en cada función Lambda que esté asignada o se
vaya a asignar a la variable de etapa function para cada uno de los métodos de la API
recién creados. Por ejemplo, si el valor $stageVariables.function es HelloWorld y no ha
añadido todavía permiso para esta función, debe ejecutar el siguiente comando de la AWS
CLI:
aws lambda add-permission --function-name arn:aws:lambda:us-east-1:account-

id:function:HelloWorld --source-arn arn:aws:execute-api:us-east-1:account-
id:api-id/*/GET/lambdasv1 --principal apigateway.amazonaws.com --statement-
id statement-id-guid --action lambda:InvokeFunction
En caso contrario, se producirá una respuesta 500 Internal Server Error al llamar al
método. Asegúrese de sustituir ${stageVariables.function} por el nombre de la función
Lambda asignada a la variable de etapa.
313
2. Implemente la API en las etapas disponibles.

3. En el panel de navegación Stages, elija la etapa beta. Compruebe que su implementación más
reciente se encuentra en fase beta Stage Editor. Copie el enlace Invoke URL, péguelo en la barra de
direcciones del navegador y añada /lambdasv1 a esa dirección URL. De este modo, se llamará a la
función Lambda subyacente a través del método GET en el recurso secundario LambdaSv1 de la API.
Note
Su función Lambda HelloWorld implementa el siguiente código.

if (event.version)
callback(null, 'Hello, World! (' + event.version + ')' );
else
callback(null, "Hello, world! (v-unknown)");
};
Esta implementación produce las siguientes respuestas.
"Hello, world! (v-unknown)"
Pasar metadatos específicos de una etapa a una función Lambda

a través de una variable de etapa
Este procedimiento describe cómo utilizar una variable de etapa para pasar metadatos de configuración
específicos de una etapa a funciones Lambda. Utilizaremos un método POST y una plantilla de asignación
de entrada para generar la carga mediante la variable de etapa version declarada anteriormente.
1. En el panel Resources, elija el recurso secundario /lambdasv1. Cree un método POST el recurso
secundario, establezca Integration type en Lambda Function y escriba ${stageVariables.function}
en Lambda Function. Seleccione Save.
Tip
Este paso es similar al paso que usó para crear el método GET. Para obtener más
información, consulte Llamar a la función Lambda a través de la API con una variable de
etapa (p. 313).
2. En el panel /Method Execution, elija Integration Request. En el panel Integration Request, amplíe
Mapping Templates y, a continuación, elija Add mapping template para agregar una plantilla para el
tipo de contenido application/json, tal y como se muestra a continuación.
314
Note
En una plantilla de asignación, se debe hacer referencia a una variable de etapa usando
comillas (como en "$stageVariables.version" o "${stageVariables.version}"), mientras
que en otros lugares no deben usarse las comillas (como en ${stageVariables.function}).
3. Implemente la API en las etapas disponibles.
4. En el panel de navegación Stages, elija beta. En beta Stage Editor, verifique que la etapa actual tiene
la implementación más reciente. Copie el enlace Invoke URL, péguelo en el campo de entrada URL
de un cliente de la API REST, añada /lambdasv1 a esa dirección URL y, a continuación, envíe una
solicitud POST a la función Lambda subyacente.
Note
Obtendrá la siguiente respuesta.
"Hello, world! (v-beta)"
Para resumir, hemos mostrado cómo usar variables de etapa de API Gateway para interactuar con
diferentes backends HTTP y Lambda en diferentes etapas de la implementación de la API. Además,
hemos mostrado cómo utilizar las variables de etapa para pasar datos de configuración específicos de una
etapa a backends HTTP y Lambda. Juntos, estos procedimientos muestran la versatilidad de las variables
de etapa de API Gateway a la hora de administrar la implementación de una API.
315
Referencia de variables de etapa
Referencia de variables de etapa de Amazon API

Gateway
Puede utilizar las variables de etapa de API Gateway en los siguientes casos.
Expresiones de asignación de parámetros

Una variable de etapa se puede usar en una expresión de asignación de parámetros para un parámetro
de encabezado de solicitud o respuesta de un método de la API sin ninguna sustitución parcial. En el
siguiente ejemplo, se hace referencia a la variable de etapa sin $ y sin utilizar {...}.
• stageVariables.<variable_name>
Una variable de etapa se puede utilizar en cualquier lugar de una plantilla de asignación, tal y como se
muestra en los siguientes ejemplos.
• { "name" : "$stageVariables.<variable_name>"}
• { "name" : "${stageVariables.<variable_name>}"}
URI de integración HTTP

Una variable de etapa se puede utilizar como parte de una URL de integración HTTP, tal y como se
muestra en los siguientes ejemplos.
• Una URI completa sin protocolo (por ejemplo, http://${stageVariables.<variable_name>})

• Un dominio completo (por ejemplo, http://${stageVariables.<variable_name>}/resource/
operation)
• Un subdominio (por ejemplo, http://${stageVariables.<variable_name>}.example.com/resource/
operation)
• Una ruta (por ejemplo, http://example.com/${stageVariables.<variable_name>}/bar)
• Una cadena de consulta ( http://example.com/foo?q=${stageVariables.<variable_name>})
URI de integración de AWS

Una variable de etapa se puede utilizar como parte de los componentes de acción o ruta de un URI de
AWS, tal y como se muestra en el siguiente ejemplo.
• arn:aws:apigateway:<region>:<service>:${stageVariables.<variable_name>}
URI de integración de AWS (funciones Lambda)

Una variable de etapa puede utilizarse en lugar de un nombre de función Lambda o versión/alias, tal y
como se muestra en los siguientes ejemplos.
• arn:aws:apigateway:<region>:lambda:path/2015-03-31/functions/
arn:aws:lambda::<account_id>:function:${stageVariables.<function_variable_name>}/
invocations
316
Exportar una API
• arn:aws:apigateway:<region>:lambda:path/2015-03-31/functions/
arn:aws:lambda::<account_id>:function:<function_name>:
${stageVariables.<version_variable_name>}/invocations
Credenciales de integración de AWS

Una variable de etapa se puede utilizar como parte del ARN de credenciales de roles/usuarios de AWS, tal
y como se muestra en el siguiente ejemplo.
• arn:aws:iam::<account_id>:${stageVariables.<variable_name>}
Exportar una API de API Gateway

Una vez que haya creado y configurado una API en API Gateway mediante la consola de API Gateway
o de otra forma, puede exportarla a un archivo de Swagger mediante la API Export de API Gateway,
que forma parte del servicio de control de Amazon API Gateway. Dispone de opciones para incluir las
extensiones de integración de API Gateway, así como las extensiones de Postman, en el archivo de
definición de Swagger exportado.
No puede exportar una API si sus cargas no son del tipo application/json. Si lo intenta, obtendrá una
respuesta de error en la que se indica que no se encuentran los modelos del cuerpo JSON.
Solicitar la exportación de una API

Con la API Export, puede exportar una API existente enviando una solicitud GET en la que se especifique
la API que se va exportar como parte de las rutas URL. La URL de la solicitud debe tener el siguiente
formato:
https://<host>/restapis/<restapi_id>/stages/<stage_name>/exports/swagger
Puede adjuntar la cadena de consulta extensions para especificar si desea incluir extensiones de API
Gateway (con el valor integration) o extensiones de Postman (con el valor postman).
Además, puede establecer el encabezado Accept en application/json o application/yaml para recibir

la salida de la definición de la API en formato JSON o YAML, respectivamente.
Para obtener información sobre cómo enviar solicitudes GET utilizando la API Export de API Gateway,
consulte la sección Realizar solicitudes HTTP.
Note
Si define modelos en la API, deben ser para el tipo de contenido de "application/json" para que
API Gateway pueda exportar el modelo. De lo contrario, API Gateway produce una excepción con
el mensaje de error "Only found non-JSON body models for ...".
Descargar la definición de Swagger de la API en

JSON
Para exportar y descargar una API en definiciones de Swagger en formato JSON:
GET /restapis/<restapi_id>/stages/<stage_name>/exports/swagger
317
Descargar la definición de Swagger de la API en YAML
Host: apigateway.<region>.amazonaws.com
Aquí, <region> podría ser, por ejemplo, us-east-1. Para todas las regiones donde API Gateway está
disponible, consulte Regiones y puntos de enlace
Descargar la definición de Swagger de la API en

YAML
Para exportar y descargar una API en definiciones de Swagger en formato YAML:
GET /restapis/<restapi_id>/stages/<stage_name>/exports/swagger
Descargar la definición de Swagger de la API con

extensiones Postman en JSON
Para exportar y descargar una API en definiciones de Swagger con Postman en formato JSON:
GET /restapis/<restapi_id>/stages/<stage_name>/exports/swagger?extensions=postman
Descargar la definición de Swagger de la API con

integración de API Gateway en YAML
Para exportar y descargar una API en definiciones de Swagger con integración de API Gateway en formato
YAML:
GET /restapis/<restapi_id>/stages/<stage_name>/exports/swagger?extensions=integrations
Exportar la API mediante la consola de API Gateway

Después de implementar la API en una etapa (p. 295), puede empezar a exportar la API en la etapa a un
archivo de Swagger mediante la consola de API Gateway.
En la página stage configuration de la consola de API Gateway, elija la pestaña Export y, a continuación,
una de las opciones disponibles (Export as Swagger, Export as Swagger + API Gateway Integrations y
Export as Postman) para descargar la definición de Swagger de la API.
318
Generar el SDK de una API
Generar el SDK para una API

Para llamar a la API en función del lenguaje o la plataforma, debe generar el SDK específico de la
plataforma o del lenguaje de la API. Actualmente, API Gateway permite generar un SDK para una API en
Java, JavaScript, Java para Android y Objective-C o Swift para iOS.
En esta sección se explica cómo generar un SDK de una API de API Gateway y se muestra cómo utilizar el
SDK generado en una aplicación Java, una aplicación Java para Android, aplicaciones Objective-C y Swift
para iOS y una aplicación JavaScript.
Para facilitar la explicación, usaremos esta API (p. 322) de API Gateway, que expone la función Lambda
Calculadora sencilla (p. 321).
Antes de continuar, asegúrese de crear o importar la API e implementarla al menos una vez en API
Gateway. Para obtener instrucciones, consulte Implementar una API (p. 294).
Temas
• Generar los SDK para una API mediante la consola de API Gateway (p. 319)
• Función Lambda de calculadora sencilla (p. 321)
• API de calculadora sencilla en API Gateway (p. 322)
• Definición de Swagger de la API de calculadora sencilla (p. 327)
Generar los SDK para una API mediante la consola de

API Gateway
Para generar un SDK específico de la plataforma o del lenguaje para una API en API Gateway, primero
debe crear, probar e implementar la API en una etapa. Con fines ilustrativos, utilizaremos la API
Calculadora sencilla (p. 327) como ejemplo para generar SDK específicos del lenguaje o de la plataforma
en toda esta sección. Para obtener instrucciones sobre cómo crear, probar e implementar esta API,
consulte Crear la API Calculadora sencilla (p. 322).
Para generar los SDK de una API en API Gateway

2. En el cuadro que contiene el nombre de la API para la etapa, elija Stages.
319
Generar los SDK para una API
mediante la consola de API Gateway
4. En la pestaña SDK Generation, para Platform, elija la plataforma.
a. En Java, especifique lo siguiente:
• En Service Name, especifique el nombre de su SDK. Por ejemplo, SimpleCalcSdk. Se

convertirá en el nombre de la clase del cliente de SDK. El nombre se corresponde con la
etiqueta <name> en <project> en el archivo pom.xml, que se encuentra en la carpeta del
proyecto del SDK. No incluya guiones.
• En Java Package Name, especifique un nombre de paquete para el SDK. Por ejemplo,
examples.aws.apig.simpleCalc.sdk. Este nombre de paquete se utiliza como el espacio de
nombres de su biblioteca de SDK. No incluya guiones.
• En Java Build System, escriba maven o gradle para especificar el sistema de compilación.
• En Java Group Id, escriba un identificador de grupo para el proyecto del SDK. Por ejemplo, my-
apig-api-examples. Este identificador se corresponde con la etiqueta <groupId> en <project>
en el archivo pom.xml, que está en la carpeta del proyecto del SDK.
• En Java Artifact Id, escriba un identificador de artefacto para el proyecto del SDK. Por
ejemplo, simple-calc-sdk. Este identificador se corresponde con la etiqueta <artifactId> en
<project> en el archivo pom.xml, que está en la carpeta del proyecto del SDK.
• En Java Artifact Version, escriba una cadena de identificador de la versión. Por ejemplo, 1.0.0.
Este identificador de versión se corresponde con la etiqueta <version> en <project> en el
archivo pom.xml, que está en la carpeta del proyecto del SDK.
• En Source Code License Text, escriba el texto de la licencia del código fuente, si procede.
b. En Android, especifique lo siguiente:
• En Group ID, escriba el identificador único para el proyecto correspondiente. Este identificador
se utiliza en el archivo pom.xml (por ejemplo, com.mycompany).
• En Invoker package, especifique el espacio de nombres para las clases del cliente generadas
(por ejemplo, com.mycompany.clientsdk).
• En Artifact ID, especifique el nombre del archivo .jar compilado sin la versión. Este nombre se
utiliza en el archivo pom.xml (por ejemplo, aws-apigateway-api-sdk).
• En Artifact version, escriba el número de versión del artefacto para el cliente generado. Este
nombre se utiliza en el archivo pom.xml y debe seguir el patrón major.minor.patch (por
ejemplo, 1.0.0).
c. En iOS (Objective-C) o iOS (Swift), escriba un prefijo único en el cuadro Prefix. El efecto del
prefijo es el siguiente: si asigna, por ejemplo, SIMPLE_CALC como el prefijo para el SDK de la
API SimpleCalc (p. 322) con los modelos Input, Output y Result, el SDK generado contendrá
la clase SIMPLE_CALCSimpleCalcClient que encapsula la API, incluidas las solicitudes y
respuestas del método. Además, el SDK generado contendrá las clases SIMPLE_CALCInput,
SIMPLE_CALCOutput y SIMPLE_CALCResult para representar la entrada, la salida y los resultados,
respectivamente, para representar la entrada y la salida de la solicitud. Para obtener más
información, consulte Usar un SDK de iOS generado por API Gateway en Objective-C o
Swift (p. 356).
5. Elija Generate SDK y, a continuación, siga las instrucciones que aparecen en pantalla para descargar
el SDK generado por API Gateway.
• Si ha elegido Java para Platform, siga las instrucciones de Utilice un SDK de Java generado por API
Gateway (p. 350).
• Si ha elegido Android para Platform, siga las instrucciones de Usar un SDK de Android generado
por API Gateway (p. 353).
• Si ha elegido iOS para Platform, siga las instrucciones de Usar un SDK de iOS generado por API
Gateway en Objective-C o Swift (p. 356).
• Si ha elegido JavaScript para Platform, siga las instrucciones de Usar un SDK de JavaScript
generado por API Gateway (p. 355).
320
Función Lambda de calculadora sencilla
Después de actualizar una API, debe volver a implementarla y volver a generar el SDK para que se
incluyan las actualizaciones.
A continuación, le mostramos cómo utilizar el SDK generado para llamar a la API subyacente. Para poner
la explicación en contexto, haremos referencia a la siguiente API de ejemplo y a sus SDK.
Función Lambda de calculadora sencilla

A modo de ilustración, utilizaremos una función Lambda de Node.js que realiza las operaciones binarias de
suma, resta, multiplicación y división.
Temas
• Formato de entrada de la función Lambda de calculadora sencilla (p. 321)
• Formato de salida de la función Lambda de calculadora sencilla (p. 321)
• Implementación de la función Lambda de calculadora sencilla (p. 321)
• Crear la función Lambda de calculadora sencilla (p. 322)
Formato de entrada de la función Lambda de calculadora sencilla

Esta función toma una entrada con el formato siguiente:
{ "a": "Number", "b": "Number", "op": "string"}
donde op puede tener alguno de los valores siguientes: (+, -, *, /, add, sub, mul, div).
Formato de salida de la función Lambda de calculadora sencilla

Cuando una operación se realiza correctamente, devuelve el resultado en el siguiente formato:
{ "a": "Number", "b": "Number", "op": "string", "c": "Number"}
donde c contiene el resultado del cálculo.
Implementación de la función Lambda de calculadora sencilla

La implementación de la función Lambda es la siguiente:
console.log('Loading the Calc function');

if (event.a === undefined || event.b === undefined || event.op === undefined) {
callback("400 Invalid Input");
}
var res = {};

res.a = Number(event.a);
res.b = Number(event.b);
res.op = event.op;
if (isNaN(event.a) || isNaN(event.b)) {
callback("400 Invalid Operand");
}
321
API de calculadora sencilla en API Gateway
switch(event.op)
{
case "+":
case "add":
res.c = res.a + res.b;
break;
case "-":
case "sub":
res.c = res.a - res.b;
break;
case "*":
case "mul":
res.c = res.a * res.b;
break;
case "/":
case "div":
res.c = res.b===0 ? NaN : Number(event.a) / Number(event.b);
break;
default:
callback("400 Invalid Operator");
break;
}
callback(null, res);
};
Crear la función Lambda de calculadora sencilla

Puede utilizar la consola de AWS Lambda en https://console.aws.amazon.com/lambda/ para crear la
función, pegando el código anterior en el editor de código online como se indica a continuación.

Nuestra API de calculadora sencilla expone tres métodos (GET, POST, GET) para invocar Función
Lambda de calculadora sencilla (p. 321) (Calc). A continuación, se muestra una representación gráfica
de esta API:
322
Estos tres métodos muestran diferentes formas de proporcionar la entrada para la función Lambda del
backend con el objetivo de realizar la misma operación:
• El método GET /?a=...&b=...&op=... utiliza los parámetros de consulta para especificar la entrada.
• El método POST /? utiliza una carga JSON {"a":"Number", "b":"Number", "op":"string"} para
especificar la entrada.
• El método GET /{a}/{b}/{op} utiliza los parámetros de ruta para especificar la entrada.
Antes de mostrar cómo llamar a estos métodos con un SDK generado por API Gateway para esta API,
vamos a recordar brevemente cómo se configuran. Para obtener instrucciones detalladas, consulte Crear
una API (p. 73). Si es la primera vez que utiliza API Gateway, consulte primero Introducción (p. 6).
Crear modelos para la entrada y la salida

Para especificar una entrada con establecimiento inflexible de tipos en el SDK, creamos un modelo Input
para la API:
323
Del mismo modo, para describir el tipo de datos del cuerpo de la respuesta, creamos los siguientes
modelos en API Gateway:
{
"type": "object",
"properties": {
"c": {"type":"number"}
},
"title": "Output"
}
{
"type":"object",
"properties":{
"input":{
"$ref":"https://apigateway.amazonaws.com/restapis/t7dve4zn36/models/Input"
},
"output":{
"$ref":"https://apigateway.amazonaws.com/restapis/t7dve4zn36/models/Output"
}
},
"title":"Result"
}
Configurar parámetros de consulta del método GET /

Para el método GET /?a=..&b=..&op=.., los parámetros de consulta se declaran en Method Request:
324
Configuración del modelo de datos de la carga como entrada del

backend
Para el método POST /, creamos el modelo Input y lo añadimos a la solicitud de método para definir la
forma de los datos de entrada.
325
Con este modelo, los clientes de la API pueden analizar la salida leyendo las propiedades de un objeto
Result. Sin este modelo, los clientes tendrán que crear un objeto de diccionario que represente la salida
JSON.
Configuración del modelo de datos de la salida del resultado

desde el backend
Para los tres métodos, creamos el modelo Result y lo añadimos al elemento Method Response del método
para definir la forma de la salida devuelta por la función Lambda.
326
Definición de Swagger de la API de calculadora sencilla
Con este modelo, los clientes de la API pueden llamar al SDK para especificar la entrada creando una
instancia del objeto Input. Sin este modelo, los clientes tendrán que crear un objeto de diccionario que
represente la entrada JSON de la función Lambda.
Asimismo, también puede crear y configurar la API siguiendo las definiciones (p. 327) de API de
Swagger.
Definición de Swagger de la API de calculadora

sencilla
A continuación, se muestra la definición de Swagger de la API de calculadora sencilla. Puede importarla
en su cuenta. Sin embargo, debe restablecer los permisos basados en los recursos en la función
Lambda (p. 321) después de la importación. Para ello, vuelva a seleccionar la función Lambda que ha
creado en su cuenta desde Integration Request en la consola de API Gateway. Esto hará que la consola
de API Gateway restablezca los permisos necesarios. También puede utilizar AWS Command Line
Interface para el comando Lambda add-permission.
{
"swagger": "2.0",
"info": {
"version": "2016-09-29T20:27:30Z",
"title": "SimpleCalc"
},
"host": "t6dve4zn25.execute-api.us-west-2.amazonaws.com",
"basePath": "/demo",
"schemes": [
"https"
],
"paths": {
"/": {
"get": {
"consumes": [
327
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "op",
"in": "query",
"required": false,
"type": "string"
},
{
"name": "a",
"in": "query",
"required": false,
"type": "string"
},
{
"name": "b",
"in": "query",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
"$ref": "#/definitions/Result"
}
}
},
"application/json": "#set($inputRoot = $input.path('$'))\n{\n \"a\" :
$input.params('a'),\n \"b\" : $input.params('b'),\n \"op\" : \"$input.params('op')\"\n}"
},
"uri": "arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/
arn:aws:lambda:us-west-2:123456789012:function:Calc/invocations",
"passthroughBehavior": "when_no_templates",
"responses": {
"default": {
"application/json": "#set($inputRoot = $input.path('$'))\n{\n \"input\" :
{\n \"a\" : $inputRoot.a,\n \"b\" : $inputRoot.b,\n \"op\" : \"$inputRoot.op\"\n
},\n \"output\" : {\n \"c\" : $inputRoot.c\n }\n}"
}
}
},
"type": "aws"
}
},
"post": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "body",
"name": "Input",
328
"required": true,
"schema": {
"$ref": "#/definitions/Input"
}
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
}
}
},
"type": "aws"
}
}
},
"/{a}": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "a",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"404": {
}
},
},
"responses": {
"default": {
"application/json": "{ \"Message\" : \"Can't $context.httpMethod
$context.resourcePath\" }"
}
329
}
},
"type": "mock"
}
}
},
"/{a}/{b}": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "a",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "b",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"404": {
}
},
},
"responses": {
"default": {
"application/json": "{ \"Message\" : \"Can't $context.httpMethod
$context.resourcePath\" }"
}
}
},
"type": "mock"
}
}
},
"/{a}/{b}/{op}": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "a",
"in": "path",
"required": true,
"type": "string"
},
330
{
"name": "b",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "op",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
$input.params('a'),\n \"b\" : $input.params('b'),\n \"op\" : \"$input.params('op')\"\n}"
},
"responses": {
"default": {
}
}
},
"type": "aws"
}
}
}
},
"definitions": {
"Input": {
"type": "object",
"properties": {
"a": {
"type": "number"
},
"b": {
"type": "number"
},
"op": {
"type": "string"
}
},
"title": "Input"
},
"Output": {
"type": "object",
"properties": {
"c": {
"type": "number"
331
Configurar un nombre de dominio personalizado
}
},
"title": "Output"
},
"Result": {
"type": "object",
"properties": {
"input": {
},
"output": {
"$ref": "#/definitions/Output"
}
},
"title": "Result"
}
}
}
Configurar nombres de dominio personalizados

para el nombre de host de la API
Después de implementar la API, usted (y sus clientes) puede invocar la API utilizando la URL raíz
predeterminada con el siguiente formato:
https://api-id.execute-api.region.amazonaws.com/stage
Aquí, el nombre de host de la dirección URL (es decir, api-id.execute-api.region.amazonaws.com)

puede ser difícil de recordar y no es muy descriptivo. Para proporcionar una URL más sencilla e intuitiva
a los usuarios de la API, puede utilizar API Gateway para configurar un nombre de dominio personalizado
(por ejemplo, api.haymuto.com) como el nombre de host de la API y elegir una ruta base (p. ej.,
myservice) para presentar una URL alternativa de la API con el siguiente formato:
https://api.haymuto.com/myservice
La ruta base puede ser una cadena vacía. En este caso, la URL raíz de la API es la misma que el
dominio personalizado (por ejemplo, https://api.haymuto.com). En este caso, el nombre de dominio
personalizado puede admitir una única API.
Por cada API que cree, API Gateway configura una distribución de Amazon CloudFront para la API.
Las solicitudes con la URL de API predeterminada se enrutan a través de la distribución de CloudFront
correspondiente. Del mismo modo, para cada nombre de dominio personalizado, API Gateway configura
una distribución de CloudFront. Una solicitud de API con el nombre de dominio personalizado se enruta a
través de la distribución de CloudFront del nombre de dominio personalizado.
Note
La distribución de CloudFront creada por API Gateway es propiedad de un cuenta específica de
la región afiliada a API Gateway. Cuando realice un seguimiento de las operaciones para crear y
actualizar una distribución de CloudFront como esta en logs de CloudWatch, debe utilizar el ID de
cuenta de API Gateway. Para obtener más información, consulte Registrar la creación del nombre
de dominio personalizado en CloudTrail (p. 339).
Tip
Para configurar un nombre de dominio personalizado o para actualizar su certificado, debe tener
permiso para actualizar las distribuciones de CloudFront. Puede hacerlo asociando la siguiente
instrucción de política de IAM a un usuario de IAM, grupo o rol de su cuenta:
332
Configurar un nombre de dominio personalizado
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontUpdateDistribution",
"Effect": "Allow",
"Action": [
"cloudfront : updateDistribution"
],
"Resource": [
"*"
]
}
]
}
API Gateway admite nombres de dominio personalizados a través de la indicación de nombre de servidor
(SNI) de la distribución de CloudFront. Para obtener más información acerca del uso de nombres de
dominio personalizados en una distribución de CloudFront, incluido el formato de certificado necesario y
el tamaño máximo de una longitud de clave de certificado, consulte Using Alternate Domain Names and
HTTPS en la Guía para desarrolladores de Amazon CloudFront.
Para configurar un nombre de dominio personalizado como el nombre de host de la API, como propietario
de la API, debe proporcionar un certificado SSL/TLS para el nombre de dominio personalizado. Para
proporcionar este certificado, puede solicitar a AWS Certificate Manager (ACM) que genere un certificado
nuevo en ACM o importar en ACM un certificado personalizado emitido por una entidad de certificación
externa. Para importar un certificado SSL/TLS, debe proporcionar el cuerpo del certificado SSL/TLS con
formato PEM, su clave privada y la cadena de certificados para el nombre de dominio personalizado. Cada
certificado almacenado en ACM se identifica mediante su ARN. Para utilizar un certificado administrado por
AWS para un nombre de dominio, solo tiene que hacer referencia a su ARN.
ACM permite configurar y usar fácilmente un nombre de dominio personalizado para una API: cree
o importe en ACM un certificado para el nombre de dominio, configure el nombre de dominio en API
Gateway con el ARN del certificado proporcionado por ACM y asigne una ruta base bajo el nombre de
dominio personalizado a una etapa implementada de la API. Con los certificados emitidos por ACM, no
tiene que preocuparse de si se exponen datos del certificado confidenciales, como la clave privada.
Note
API Gateway no admite certificados SSL/TLS autofirmados, ya que estos certificados no son
compatibles con CloudFront.
Debe disponer de un nombre de dominio de Internet registrado para poder crear nombres de dominio
personalizados para sus API. Si es necesario, puede registrar un dominio de Internet utilizando Amazon
Route 53 o con el registrador de dominios de su elección. Un nombre de dominio personalizado de la API
puede ser el nombre de un subdominio o el dominio raíz (lo que recibe el nombre de "ápex de zona") de un
dominio de Internet registrado.
Una vez creado un nombre de dominio personalizado en API Gateway, debe crear o actualizar el registro
del recurso del proveedor del servicio de nombres de dominio (DNS) para asignar el nombre de dominio
al nombre de dominio de su distribución de CloudFront. La asignación garantiza que las solicitudes API
dirigidas al nombre de dominio se enruten a través de la distribución de CloudFront correcta.
Note
Un nombre de dominio personalizado asociado a una API es específico de la cuenta y la

región. Mover un nombre de dominio personalizado entre regiones o cuentas de AWS implica
la eliminación de la distribución de CloudFront existente y la creación de una nueva. El
proceso puede tardar aproximadamente 30 minutos antes de que el nuevo nombre de dominio
personalizado esté disponible. Para obtener más información, consulte Updating CloudFront
Distributions.
333
Preparar certificados en AWS Certificate Manager
En esta sección se describe cómo utilizar ACM para crear un certificado SSL/TLS para un nombre de
dominio personalizado, configurar el nombre de dominio personalizado para una API, asociar una API
específica a una ruta base bajo el nombre de dominio personalizado y renovar (o rotar) un certificado que
va a caducar importado en ACM para el nombre de dominio personalizado.
Temas
• Preparar certificados en AWS Certificate Manager (p. 334)
• Configurar un nombre de dominio personalizado para una API de API Gateway (p. 336)
• Registrar la creación del nombre de dominio personalizado en CloudTrail (p. 339)
• Configurar la asignación de ruta base de una API con un nombre de dominio personalizado como su
nombre de host (p. 340)
• Rotar un certificado importado en ACM (p. 341)
• Llamar a la API con nombres de dominio personalizados (p. 342)

Antes de configurar un nombre de dominio personalizado para una API, debe disponer de un certificado
SSL/TLS listo en AWS Certificate Manager. Esta operación se describe en los siguientes pasos. Para
obtener más información, consulte la Guía del usuario de AWS Certificate Manager.
Note
Para utilizar un certificado de ACM con API Gateway, debe solicitar o importar el certificado en la
región US East (N. Virginia) (us-east-1).
Para obtener un certificado para un nombre de dominio emitido por o importado en ACM
1. Registre su dominio de Internet (por ejemplo, myDomain.com). Puede utilizar Amazon Route 53 o
un registrador de dominios externo acreditado. Para obtener una lista de registradores, consulte
Accredited Registrar Directory en el sitio web de ICANN.
2. Para crear o importar en ACM un certificado SSL/TLS para un nombre de dominio, realice alguna de
las siguientes operaciones:
Para solicitar un certificado proporcionado por ACM para un nombre de dominio
1. Inicie sesión en la consola de AWS Certificate Manager.

2. Elija Request a certificate.
3. Escriba un nombre de dominio personalizado para la API, por ejemplo, api.example.com, en
Domain name.
4. También puede seleccionar Add another name to this certificate.
5. Elija Review and request.
6. Elija Confirm and request.
7. Para que una solicitud sea válida, un propietario registrado del dominio de Internet debe autorizar
la solicitud antes de que ACM emita el certificado.
Para importar en ACM un certificado para un nombre de dominio
1. Obtenga un certificado SSL/TLS codificado en PEM para su nombre de dominio personalizado de

una entidad de certificación. Para obtener una lista parcial de entidades de certificación, consulte
Mozilla Included CA List
a. Genere una clave privada para el certificado y guarde el resultado en un archivo, utilizando el
kit de herramientas de OpenSSL en el sitio web de OpenSSL:
334
openssl genrsa -out private-key-file 2048
Note
Amazon API Gateway usa Amazon CloudFront para permitir certificados para
nombres de dominio personalizados. Por tanto, los requisitos y las restricciones del
certificado SSL/TLS de un nombre de dominio personalizado los dicta CloudFront.
Por ejemplo, el tamaño máximo de la clave pública es 2048 y la clave privada puede
ser 1024, 2048 y 4096. El tamaño de la clave pública se determina en función de la
entidad de certificación que utilice. Pida a su entidad de certificación que devuelva
claves de un tamaño diferente de la longitud predeterminada. Para obtener más
información, consulte Secure access to your objects y Create signed URLs and
signed cookies.
b. Genere una solicitud de firma de certificado (CSR) con la clave privada generada
anteriormente, utilizando OpenSSL:
openssl req -new -sha256 -key private-key-file -out CSR-file
c. Envíe la CSR a la entidad de certificación y guarde el certificado resultante.

d. Descargue la cadena de certificados de la entidad de certificación.
Note
Si obtiene la clave privada de otra forma y la clave está cifrada, puede utilizar el siguiente
comando para descifrar la clave antes de enviarla a API Gateway para que configure un
nombre de dominio personalizado.
openssl pkcs8 -topk8 -inform pem -in MyEncryptedKey.pem -outform pem -

nocrypt -out MyDecryptedKey.pem
2. Cargue el certificado en AWS Certificate Manager:
a. Inicie sesión en la consola de AWS Certificate Manager.

b. Seleccione Import a certificate.
c. En Certificate body, escriba o pegue el cuerpo del certificado del servidor con formato PEM
de su entidad de certificación. A continuación se muestra un ejemplo abreviado de dicho
certificado.
-----BEGIN CERTIFICATE-----
EXAMPLECA+KgAwIBAgIQJ1XxJ8Pl++gOfQtj0IBoqDANBgkqhkiG9w0BAQUFADBB
...
az8Cg1aicxLBQ7EaWIhhgEXAMPLE
-----END CERTIFICATE-----
d. En Certificate private key, escriba o pegue la clave privada del certificado con formato PEM.
A continuación se muestra un ejemplo abreviado de dicha clave.
-----BEGIN RSA PRIVATE KEY-----

EXAMPLEBAAKCAQEA2Qb3LDHD7StY7Wj6U2/opV6Xu37qUCCkeDWhwpZMYJ9/nETO
...
1qGvJ3u04vdnzaYN5WoyN5LFckrlA71+CszD1CGSqbVDWEXAMPLE
-----END RSA PRIVATE KEY-----
e. En Certificate chain, escriba o pegue los certificados intermedios con formato PEM y,
opcionalmente, el certificado de raíz, uno detrás del otro sin líneas en blanco. Si incluye el
335
Configurar un nombre de dominio
personalizado para una API de API Gateway
certificado raíz, la cadena de certificados debe empezar con los certificados intermedios
y terminar con el certificado raíz. Utilice los certificados intermedios proporcionados por la
entidad de certificación. No incluya certificados intermedios que no estén en la cadena de la
ruta de confianza. A continuación se muestra un ejemplo abreviado.
EXAMPLECA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB
...
8/ifBlIK3se2e4/hEfcEejX/arxbx1BJCHBvlEPNnsdw8EXAMPLE
Este es otro ejemplo.
Intermediate certificate 2
Intermediate certificate 1
Optional: Root certificate
f. Seleccione Review and import.

3. Una vez que el certificado se haya creado o importado correctamente, anote el ARN del certificado. Lo
necesitará cuando configure el nombre de dominio personalizado, a continuación.
Configurar un nombre de dominio personalizado para

una API de API Gateway
El siguiente procedimiento describe cómo configurar un nombre de dominio personalizado para una API
utilizando la consola de API Gateway.
Para configurar un nombre de dominio personalizado mediante la consola de API Gateway

2. Elija Custom Domain Names en el panel de navegación principal.
3. Elija Create Custom Domain Name a continuación.
4. a. En New Custom Domain Name, escriba el nombre de dominio (por ejemplo, api.example.com) en
Domain Name.
Note
No utilice el carácter comodín (es decir, *) para los nombres de dominio personalizados.
API Gateway no lo admite, aunque la consola de API Gateway (o la AWS CLI) lo
acepte y pueda asignarlo a una distribución de CloudFront. Sin embargo, puede utilizar
certificados comodín.
b. Elija un certificado de la lista ACM Certificate.
c. Elija Add mapping en Base Path Mappings para definir una ruta base (Path) para una API
implementada en una etapa determinada (seleccionada de las listas desplegables Destination).
También puede definir la asignación de ruta base después de crear el nombre de dominio
personalizado. Para obtener más información, consulte Configurar la asignación de ruta base de
una API con un nombre de dominio personalizado como su nombre de host (p. 340).
d. Seleccione Save.
336
5. Una vez creado el nombre de dominio personalizado, la consola mostrará el nombre de dominio de
la distribución de CloudFront asociado, en forma de distribution-id.cloudfront.net, junto con
el ARN del certificado. Anote el nombre de dominio de distribución de CloudFront mostrado en el
resultado. Lo necesitará en el siguiente paso para establecer el valor CNAME o un destino de alias de
registro A del dominio personalizado en su DNS.
Note
El nombre de dominio personalizado que acaba de crear tarda unos 40 minutos en estar listo.
Mientras tanto, puede configurar el alias de registro DNS para asignar el nombre de dominio
personalizado al nombre de dominio de distribución de CloudFront asociado y para configurar
la asignación de ruta base para el nombre de dominio personalizado mientras se inicializa el
nombre de dominio personalizado.
6. En este paso, usaremos Amazon Route 53 como proveedor de DNS de ejemplo para mostrar cómo
se configura un alias de registro A para su dominio de Internet para asignar el nombre de dominio
personalizado al nombre de distribución de CloudFront asociado. Las instrucciones pueden adaptarse
a otros proveedores de DNS.
a. Inicie sesión en la consola de Amazon Route 53.

b. Cree un conjunto de recursos A-IPv4 address para su dominio personalizado (por ejemplo,
api.haymuto.com). Un registro A asigna un nombre de dominio personalizado a una dirección IP4.
c. Elija Yes en Alias, escriba el nombre de dominio de CloudFront (por ejemplo,
d3boq9ikothtgw.cloudfront.net) en Alias Target y, a continuación, elija Create. Este alias
de registro A asigna su nombre de dominio personalizado al nombre de dominio de CloudFront
especificado, que a su vez se asigna a una dirección IP4.
337
Tip
Alias Hosted Zone ID identifica la zona alojada del Alias Target especificado. La consola de
Amazon Route 53 rellena automáticamente el valor cuando se escribe un nombre de dominio
válido para Alias Target. Para crear un alias de registro A sin usar la consola de Amazon
338
Registrar la creación del nombre de
dominio personalizado en CloudTrail
Route 53, como, por ejemplo, cuando utiliza la AWS CLI, debe especificar el ID de zona
alojada necesario. Para cualquier nombre de dominio de distribución de CloudFront, el valor
de ID de zona alojada siempre es Z2FDTNDATAQYW2, tal y como se documenta en Regiones y
puntos de enlace de AWS para CloudFront.
Para la mayoría de los proveedores de DNS, se añade un nombre de dominio personalizado a la zona
alojada como un conjunto de registros de recursos CNAME. El nombre de registro CNAME especifica
el nombre de dominio personalizado que especificó anteriormente en Domain Name (por ejemplo,
api.haymuto.com). El valor del registro CNAME especifica el nombre de dominio de la distribución de
CloudFront. Sin embargo, el uso de un registro CNAME no funcionará si su dominio personalizado es
un ápex de zona (es decir, example.com en lugar de api.haymuto.com). Un ápex de zona se conoce
también como el dominio raíz de la organización. Para un ápex de zona necesita utilizar un alias de
registro A, siempre y cuando lo admita su proveedor de DNS.
Con Amazon Route 53 puede crear un alias de registro A para su nombre de dominio personalizado
y especificar el nombre de dominio de distribución de CloudFront como el alias de destino, tal y como
se muestra más arriba. Esto significa que Amazon Route 53 pueden enrutar su nombre de dominio
personalizado aunque se trate de un ápex de zona. Para obtener más información, consulte Choosing
Between Alias and Non-Alias Resource Record Sets en la Guía para desarrolladores de Amazon
Route 53.
El uso de un alias de registro A elimina también la exposición del nombre de dominio de distribución
de CloudFront subyacente, ya que la asignación de nombres de dominio se realiza únicamente en
Amazon Route 53. Por estas razones, recomendamos que utilice el alias de registro A de Amazon
Route 53 siempre que sea posible.
Además de utilizar la consola de API Gateway, puede usar la API REST de API Gateway, la CLI de AWS
o uno de los SDK de AWS para configurar el nombre de dominio personalizado para las API. A modo de
ilustración, en el siguiente procedimiento se describen los pasos para realizar esta operación mediante las
llamadas a la API REST.
Para configurar un nombre de dominio personalizado mediante la API REST de API Gateway
1. Llame a domainname:create, especificando el nombre de dominio personalizado y el ARN de un

certificado almacenado en AWS Certificate Manager.
La llamada a la API, si se realiza correctamente, devuelve una respuesta 201 Created, que contiene
el ARN del certificado, así como el nombre de distribución de CloudFront asociado en su carga.
2. Anote el nombre de dominio de distribución de CloudFront mostrado en el resultado. Lo necesitará
en el siguiente paso para establecer el valor CNAME o un destino de alias de registro A del dominio
personalizado en su DNS.
3. Siga el paso 6 del procedimiento anterior para configurar un alias de registro A para asignar el nombre
de dominio a su nombre de distribución de CloudFront.
Para ver ejemplos de código de esta llamada a la API REST, consulte domainname:create.
Registrar la creación del nombre de dominio

personalizado en CloudTrail
Cuando CloudTrail está habilitado para registrar llamadas de API Gateway realizadas por su cuenta, API
Gateway registra las actualizaciones de la distribución de CloudFront asociadas cuando se crea o se
actualiza un nombre de dominio personalizado para una API. Como estas distribuciones de CloudFront
son propiedad de API Gateway, cada una de estas distribuciones de CloudFront registradas se identifican
mediante uno de los siguientes ID de cuenta de API Gateway específicos de cada región, en lugar de
mediante el ID de la cuenta del propietario de la API.
339
Configurar la asignación de ruta base de una API con un
nombre de dominio personalizado como su nombre de host
ID de cuenta de API Gateway específicos de la región de distribuciones de CloudFront asociadas

con un nombre de dominio personalizado
Región ID de cuenta
us-east-1 392220576650
us-east-2 718770453195
us-west-1 968246515281
us-west-2 109351309407
eu-west-1 631144002099
eu-west-2 544388816663
eu-central-1 474240146802
ap-northeast-1 969236854626
ap-northeast-2 020402002396
ap-southeast-1 195145609632
ap-southeast-2 798376113853
Configurar la asignación de ruta base de una API con

un nombre de dominio personalizado como su nombre
de host
Puede utilizar un único nombre de dominio personalizado como el nombre de host de varias API. Para ello,
debe configurar asignaciones de ruta base en el nombre de dominio personalizado. Con la asignaciones
de ruta base, una API bajo el dominio personalizado estará accesible a través de la combinación del
nombre de dominio personalizado y la ruta base asociada.
Por ejemplo, si creó una API denominada PetStore y otra API con el nombre PetShop, y configuró un
nombre de dominio personalizado de api.haymuto.com en API Gateway, puede establecer la URL
de la API PetStore como https://api.haymuto.com o https://api.haymuto.com/myPetStore. La
API PetStore se asocia con la ruta base de una cadena vacía o myStore bajo el nombre de dominio
personalizado api.haymuto.com. Del mismo modo, puede asignar una ruta base de yourPetStore para la
API PetShop. La dirección URL de https://api.haymuto.com/yourPetStore es entonces la URL raíz de la
API PetShop.
Antes de configurar la ruta base de una API, complete los pasos de Configurar un nombre de dominio
personalizado para una API de API Gateway (p. 336).
Para configurar la ruta base para asignaciones de API mediante la consola de API Gateway
1. Elija un nombre de dominio personalizado de la lista Custom Domain Names disponibles en su cuenta.
2. Elija Show Base Path Mappings o Edit.
3. Elija Add mapping.
4. (Opcional) Escriba un nombre para la ruta base en Path, elija una API en Destination y, a
continuación, elija una etapa.
340
Rotar un certificado importado en ACM
Note
La lista Destination muestra las API implementadas en su cuenta.

5. Elija Save para terminar de configurar el mapeo de ruta base para la API.
Note
Para eliminar una asignación después de crearla, junto a la asignación que desea eliminar, elija el
icono de papelera.
Además, puede llamar a la API REST de API Gateway, a la CLI de AWS o a alguno de los SDK de AWS
para configurar la asignación de ruta base de una API con un nombre de dominio personalizado como su
nombre de host. A modo de ilustración, en el siguiente procedimiento se describen los pasos para realizar
esta operación mediante las llamadas a la API REST.
Para configurar la asignación de ruta base de una API mediante la API REST de API Gateway
• Llame a basepathmapping:create en un nombre de dominio personalizado, especificando el elemento

basePath, restApiId y una propiedad stage de implementación en la solicitud de carga.
La llamada a la API, si se realiza correctamente, devuelve una respuesta 201 Created.
Para ver ejemplos de código de la llamada a la API REST, consulte basepathmapping:create.
Rotar un certificado importado en ACM

ACM se encarga automáticamente de renovar los certificados que emite. No necesita rotar ningún
certificado emitido por ACM para los nombres de dominio personalizados. CloudFront se encarga de ello
por usted.
No obstante, si importa un certificado en ACM y lo usa para un nombre de dominio personalizado, debe
rotar el certificado antes de que venza. Esto implica importar un nuevo certificado de terceros para el
nombre de dominio y reemplazar el certificado existente por el nuevo. Necesita repetir el proceso cuando
el certificado que acaba de importar venza. De forma alternativa, puede solicitar a ACM que emita un
nuevo certificado para el nombre de dominio y reemplazar el existente por el nuevo certificado emitido por
ACM. A partir de entonces, puede dejar que ACM y CloudFront se ocupen de administrar la rotación de
certificados por usted. Para crear o importar un nuevo certificado de ACM, siga los pasos para solicitar o
importar una nuevo certificado de ACM (p. 334) para el nombre de dominio especificado.
Para rotar un certificado para un nombre de dominio, puede utilizar la consola de API Gateway, la API
REST de API Gateway, la CLI o alguno de los SDK de AWS.
Para rotar un certificado que está a punto de vencer importado en ACM mediante la consola de
API Gateway
1. Solicite o importe un certificado en ACM.

2. Vuelva a la consola de API Gateway.
3. Elija Custom Domain Names en el panel de navegación principal de la consola de API Gateway.
4. Seleccione el nombre de dominio personalizado de su elección en el panel Custom Domain Names.
5. Elija Edit.
6. Elija el certificado que desee en la lista desplegable ACM Certificate.
7. Elija Save para empezar a rotar el certificado para el nombre de dominio personalizado.
341
Llamar a la API con nombres de dominio personalizados
Note
Este proceso tarda en completarse unos 40 minutos. Una vez realizada la rotación, puede
elegir el icono de flecha bidireccional junto a ACM Certificate para restaurar el certificado
original.
Para ilustrar cómo rotar mediante programación un certificado importado para importar un nombre de
dominio personalizado, describimos los pasos utilizando la API REST de API Gateway.
Rotar un certificado importado utilizando la API REST de API Gateway
• Llame a la acción domainname:update, especificando el ARN del nuevo certificado de ACM para el
nombre de dominio especificado.
Llamar a la API con nombres de dominio

personalizados
Llamar a una API con un nombre de dominio personalizado es lo mismo que llamar a la API con su nombre
de dominio predeterminado, siempre que se use la URL correcta.
En los siguientes ejemplos se compara y se contrasta un conjunto de direcciones URL predeterminadas y

las URL personalizadas correspondientes de dos API (udxjef y qf3duz) en una región especificada (us-
east-1) y de un nombre de dominio personalizado (apis.example.com) especificado.
Direcciones URL raíz de las API con nombres de dominio predeterminados y personalizados
ID de API Etapa URL Ruta base URL personalizada

predeterminada
udxjef Pro https:// /petstore https://

udxjef.execute- apis.example.com/
api.us- petstore
east-1.amazonaws.com/
pro
udxjef tst https:// /petdepot https://

udxjef.execute- apis.example.com/
api.us- petdepot
tst
qf3duz dev https:// /bookstore https://

qf3duz.execute- apis.example.com/
api.us- bookstore
dev
qf3duz tst https:// /bookstand https://

qf3duz.execute- apis.example.com/
api.us- bookstand
tst
342
Vender su API como SaaS
API Gateway admite nombres de dominio personalizados para una API mediante el uso de la Indicación
de nombre de servidor (SNI). Puede invocar la API con un nombre de dominio personalizado mediante un
navegador o una biblioteca cliente que admita SNI.
API Gateway impone la SNI en la distribución de CloudFront. Para obtener información sobre cómo
CloudFront utiliza nombres de dominio personalizados, consulte Certificados SSL personalizados de
Amazon CloudFront.
Vender su API de API Gateway a través de AWS

Marketplace
Después de crear, probar e implementar la API, puede empaquetarla en un plan de uso de API Gateway
y vender el plan como un producto de software como servicio (SaaS) a través de AWS Marketplace. AWS
Marketplace factura a los compradores de la API que se han suscrito a su oferta de producto en función del
número de solicitudes realizadas en el plan de uso (p. 280).
Para vender su API en AWS Marketplace, debe configurar el canal de ventas para integrar AWS
Marketplace con API Gateway. En términos generales, esto implica publicar el producto en AWS
Marketplace, configurar un rol de IAM, con las políticas adecuadas para permitir a API Gateway enviar
métricas de uso a AWS Marketplace, asociar un producto de AWS Marketplace, con un plan de uso de
API Gateway y asociar un comprador de AWS Marketplace con una clave de API de API Gateway. En las
próximas secciones se ofrece información adicional.
Para permitir que sus clientes compren su producto en AWS Marketplace, debe registrar su portal para
desarrolladores (una aplicación externa) con AWS Marketplace. El portal para desarrolladores debe
administrar las solicitudes de suscripción que se redirigen desde la consola de AWS Marketplace.
Para obtener más información sobre la venta de la API como un producto SaaS en AWS Marketplace,
consulte AWS Marketplace SaaS Subscriptions - Seller Integration Guide.
Temas
• Inicializar la integración de AWS Marketplace con API Gateway (p. 343)
• Administrar la suscripción de clientes a planes de uso (p. 344)
Inicializar la integración de AWS Marketplace con API

Gateway
Las siguientes tareas son para inicializar puntualmente la integración de AWS Marketplace con API
Gateway, lo que le permite vender su API como un producto SaaS.
Publicar un producto en AWS Marketplace

Para publicar su plan de uso como un producto SaaS, envíe un formulario de carga de producto través de
AWS Marketplace. El producto debe contener una dimensión con el nombre apigateway del tipo requests.
Esta dimensión define el precio por solicitud y la utilizará API Gateway para medir las solicitudes a la API.
Crear el rol de medición

Cree un rol de IAM denominado ApiGatewayMarketplaceMeteringRole con las siguientes políticas de
ejecución y confianza. Este rol permite a API Gateway enviar métricas de uso a AWS Marketplace en su
nombre.
343
Administrar la suscripción de clientes a planes de uso
Política de ejecución del rol de medición
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"aws-marketplace:BatchMeterUsage",
"aws-marketplace:ResolveCustomer"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
Política de relación de confianza del rol de medición
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
},
}
]
}
Asociar el plan de uso con el producto de AWS Marketplace

Cuando publica un producto en AWS Marketplace, recibe un código de producto de AWS Marketplace.
Para integrar API Gateway con AWS Marketplace, asocie su plan de uso con el código de producto de
AWS Marketplace. La asociación se habilita estableciendo el campo productCode de UsagePlan de API
Gateway en el código de producto de AWS Marketplace mediante la consola de API Gateway, la API
REST de API Gateway, la AWS CLI de API Gateway o el SDK de AWS para API Gateway. El siguiente
ejemplo de código utiliza la API REST de API Gateway:
PATCH /usageplans/USAGE_PLAN_ID
Authorization: ...
{
"path" : "/productCode",
"value" : "MARKETPLACE_PRODUCT_CODE",
"op" : "replace"
}]
}

La aplicación del portal para desarrolladores se encarga de las siguientes tareas.
Cuando un cliente se suscribe a su producto a través de AWS Marketplace, AWS Marketplace reenvía
una solicitud POST a la URL de suscripciones SaaS que registró cuando publicó su producto en AWS
344
Marketplace. La solicitud POST incluye un parámetro de encabezado x-amzn-marketplace-token que

contiene la información del comprador. Siga las instrucciones de la sección Register Application de la
SaaS Seller Integration Guide para administrar este redireccionamiento en su aplicación de portal para
desarrolladores.
En respuesta a una solicitud de suscripción del cliente, AWS Marketplace envía una notificación
subscribe-success a un tema de Amazon SNS en el que está suscrito (consulte el paso 6.4 de la SaaS
Seller Integration Guide). Para aceptar la solicitud de suscripción del cliente, administra la notificación
subscribe-success creando o recuperando una clave de API de API Gateway para el cliente, asociando
el customerId aprovisionado por AWS Marketplace del cliente a las claves de API y añadiendo después la
clave de API a su plan de uso.
Cuando se completa la solicitud de suscripción del cliente, la aplicación del portal para desarrolladores
debe presentar al cliente la clave de API asociada e informarle de que la clave de API debe incluirse en el
encabezado x-api-key de las solicitudes a la API.
Cuando un cliente cancela una suscripción a un plan de uso, AWS Marketplace envía una notificación
unsubscribe-success al tema de SNS. Para completar el proceso de anular la suscripción del cliente,
administra la notificación unsubscribe-success eliminando las claves de API del cliente del plan de uso.
Autorizar a un cliente para obtener acceso a un plan de uso

Para autorizar el acceso a su plan de uso para un determinado cliente, utilice la API de API Gateway para
recuperar o crear una clave de API para el cliente y añada la clave de API a plan de uso.
El siguiente ejemplo muestra cómo llamar a la API REST de API Gateway para crear una nueva clave de
API con un valor customerId de AWS Marketplace específico (MARKETPLACE_CUSTOMER_ID).
POST apikeys HTTP/1.1

Authorization: ...
{
"name" : "my_api_key",
"description" : "My API key",
"enabled" : "false",
"stageKeys" : [ {
"restApiId" : "uycll6xg9a",
"stageName" : "prod"
} ],
"customerId" : "MARKETPLACE_CUSTOMER_ID"
}
El siguiente ejemplo muestra cómo obtener una clave de API con un valor customerId de AWS
Marketplace específico (MARKETPLACE_CUSTOMER_ID).
GET apikeys?customerId=MARKETPLACE_CUSTOMER_ID HTTP/1.1

Authorization: ...
Para añadir una clave de API a un plan de uso, cree un recurso UsagePlanKey con la clave de API para
el plan de uso pertinente. El siguiente ejemplo muestra cómo realizar esto usando la API REST de API
Gateway, donde n371pt es el ID del plan de uso y q5ugs7qjjh es una keyId de API de ejemplo devuelta
en los ejemplos anteriores.
POST /usageplans/n371pt/keys HTTP/1.1

Authorization: ...
345
{
"keyId": "q5ugs7qjjh",
"keyType": "API_KEY"
}
Asociar un cliente a una clave de API

Debe actualizar el campo customerId de ApiKey con el ID del cliente de AWS Marketplace. De esta forma,
se asociará la clave de API con el cliente de AWS Marketplace, con lo que podrá medir y facturar las
solicitudes del comprador. El siguiente ejemplo de código llama a la API REST de API Gateway para hacer
eso.
PATCH /apikeys/q5ugs7qjjh
Authorization: ...
{
"path" : "/customerId",
"value" : "MARKETPLACE_CUSTOMER_ID",
"op" : "replace"
}]
}
346
Llamar a una API en Amazon API

Gateway
Llamar a una API implementada implica enviar solicitudes al servicio del componente de API Gateway para
la ejecución de API, denominado execute-api. La URL raíz de dicha solicitud tiene el siguiente formato:
https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/
donde {restapi_id} es el identificador de la API, {region} es la región de la API implementada y

{stage_name} es el nombre de etapa de una implementación de API.
Puede encontrar esta URL raíz en el Stage Editor especificado. Se muestra como Invoke URL en la
parte superior. Si el recurso de la raíz de la API expone un método GET sin requerir la autenticación del
usuario, puede llamar al método haciendo clic en el enlace Invoke URL. También puede crear esta URL
raíz combinando los campos host y basePath de un archivo de definición de Swagger exportado de la API.
Si una API permite el acceso anónimo, puede utilizar cualquier navegador web para invocar las llamadas
al método GET copiando y pegando una URL de invocación adecuada en la barra de dirección del
navegador. Para otros métodos o para todas las llamadas que requieran autenticación, tendrá que
especificar una carga o firmar las solicitudes. Puede realizar esto en un script detrás de una página HTML
o en una aplicación cliente mediante uno de los SDK de AWS.
Para las pruebas, puede utilizar la consola de API Gateway para llamar a una API mediante la
característica TestInvoke de API Gateway, que omite la URL Invoke y permite probar la API antes de
que se implemente. También puede utilizar la aplicación Postman para probar una API que se haya
implementado correctamente sin necesidad de escribir un script o un cliente.
Note
Los valores de los parámetros de cadenas de consulta en una URL de invocación no pueden
contener %%.
Temas
347
Obtener la URL Invoke de una
API en la consola de API Gateway
• Obtener la URL Invoke de una API en la consola de API Gateway (p. 348)
• Usar la consola de API Gateway para probar un método (p. 348)
• Usar Postman para llamar a una API (p. 349)
• Utilice un SDK de Java generado por API Gateway (p. 350)
• Usar un SDK de Android generado por API Gateway (p. 353)
• Usar un SDK de JavaScript generado por API Gateway (p. 355)
• Usar un SDK de iOS generado por API Gateway en Objective-C o Swift (p. 356)
• Rastrear las llamadas a la API con logs de CloudWatch (p. 366)
Debe haber implementado ya la API en API Gateway. Siga las instrucciones en Implementar una
API (p. 294).
Obtener la URL Invoke de una API en la consola de

API Gateway
2. En el cuadro que contiene el nombre de la API que desea llamar, elija Stages.
4. La dirección URL que se muestra junto a Invoke URL tendrá un aspecto similar al siguiente, donde my-
api-id es el identificador que API Gateway asigna a su API, region-id es el identificador de región
de AWS (por ejemplo, us-east-1) donde ha implementado la API y stage-name es el nombre de la
etapa de la API que desea llamar:
https://my-api-id.execute-api.region-id.amazonaws.com/stage-name/{resourcePath}
En función del tipo de método que desee llamar y la herramienta que desee utilizar, copie esta URL al
portapapeles y, a continuación, péguela y modifíquela para llamar a la API desde un navegador web, una
herramienta de proxy de depuración web o la herramienta de línea de comandos cURL, o desde su propia
API.
Si no sabe el método que debe llamar o el formato que debe usar para llamarlo, examine la lista de
métodos disponibles siguiendo las instrucciones de Ver una lista de métodos (p. 293).
Para llamar al método directamente desde la consola de API Gateway, consulte Usar la consola para
probar un método (p. 348).
Para obtener más opciones, póngase en contacto con el propietario de la API.
Usar la consola de API Gateway para probar un

método
Use la consola de API Gateway para probar un método.
Temas
348
Requisitos previos
• Probar un método con la consola de API Gateway (p. 349)
Requisitos previos
• Debe especificar la configuración de los métodos que desea probar. Siga las instrucciones en
Configurar un método y una integración (p. 83).
Probar un método con la consola de API Gateway

Important
La comprobación de métodos con la consola de API Gateway puede provocar cambios en los
recursos que no se pueden deshacer. Probar un método con la consola API Gateway es lo
mismo que llamar al método desde fuera de la consola de API Gateway. Por ejemplo, si utiliza la
consola de API Gateway para llamar a un método que elimina recursos de una API, si la llamada
al método se realiza correctamente, se eliminarán los recursos de la API.

2. En el cuadro que contiene el nombre de la API para el método, elija Resources.
3. En el panel Resources, elija el método que desea probar.
4. En el panel Method Execution, en el cuadro Client, elija TEST. Escriba valores en cualquiera de los
cuadros mostrados (como Query Strings, Headers y Request Body).
Si necesita especificar opciones adicionales, póngase en contacto con el propietario de la API.

5. Elija Test. Se mostrará la siguiente información:
• Request es la ruta del recurso llamada para el método.

• Status es el código de estado HTTP de la respuesta.
• Latency es el tiempo entre la recepción de la solicitud del intermediario y la respuesta devuelta.
• Response Body es el cuerpo de la respuesta HTTP.
• Response Headers son los encabezados de respuesta HTTP.
Tip
En función de la asignación, el código de estado HTTP, el cuerpo de la respuesta y

los encabezados de respuesta pueden ser diferentes de los enviados desde la función
Lambda, proxy HTTP o proxy de servicio de AWS.
• Logs son las entradas de Amazon CloudWatch Logs simuladas que se habrían escrito si se hubiera
llamada a este método desde fuera de la consola de API Gateway.
Note
Aunque las entradas de CloudWatch Logs son simuladas, los resultados de la llamada al
método son reales.
Además de utilizar la consola de API Gateway, puede utilizar AWS CLI o un SDK de AWS para API
Gateway para probar la llamada a un método. Para hacerlo a través de AWS CLI, consulte test-invoke-
method.
Usar Postman para llamar a una API

El uso de la aplicación Postman resulta muy útil para probar una API en API Gateway.
349
Utilice un SDK de Java generado por API Gateway
1. Inicie Postman.
2. Introduzca la URL del punto de enlace de una solicitud en la barra de direcciones y elija el método
HTTP correspondiente en la lista desplegable situada a la izquierda de la barra de direcciones.
3. Si es necesario, elija la pestaña Authorization. Elija AWS Signature para la autorización Type. Escriba
el ID de clave de acceso de usuario de AWS IAM en el campo de entrada AccessKey. Escriba la clave
secreta del usuario de IAM en SecretKey. Especifique una región de AWS que coincida con la región
especificada en la URL de invocación. Escriba execute-api en Service Name.
4. Seleccione la pestaña Headers. Si lo desea, elimine los encabezados existentes. Esto puede borrar
la configuración antigua, lo que puede provocar errores. Añada los encabezados personalizados
necesarios. Por ejemplo, si las claves de API están habilitadas, puede establecer el par de nombre/
valor x-api-key:{api_key} aquí.
5. Elija Send para enviar la solicitud y recibir una respuesta.
Para ver un ejemplo de uso de Postman, consulte Llamar a una API con autorizadores
personalizados (p. 249).

En esta sección se describen los pasos para utilizar un SDK de Java generado por API Gateway mediante
la API Calculadora simple (p. 327) como ejemplo. Antes de continuar, debe completar los pasos de
Generar los SDK para una API mediante la consola de API Gateway (p. 319).
Para instalar y utilizar un SDK de Java generado por API Gateway
1. Extraiga el contenido del archivo .zip generado por API Gateway que ha descargado anteriormente.
2. Descargue e instale Apache Maven (versión 3.5 o posterior).
3. Descargue e instale JDK (versión 1.8 o posterior).
4. Establezca la variable de entorno JAVA_HOME.
5. Vaya a la carpeta SDK descomprimida donde se encuentra el archivo pom.xml. Esta carpeta es
generated-code de forma predeterminada. Ejecute el comando mvn install para instalar los archivos
de artefactos compilados en el repositorio de Maven local. Se creará una carpeta target con la
biblioteca del SDK compilada.
6. Escriba el comando siguiente para crear un stub del proyecto cliente para llamar a la API con la
biblioteca de SDK instalada.
mvn -B archetype:generate \
-DarchetypeGroupdId=org.apache.maven.archetypes \
-DgroupId=examples.aws.apig.simpleCalc.sdk.app \
-DartifactId=SimpleCalc-sdkClient
Note
El separador \ en el comando anterior se incluye para facilitar la lectura. El comando

completo debe estar en una sola línea sin el separador.
Este comando crea un stub de aplicación. El stub de aplicación contiene un archivo pom.xml y una
carpeta src en el directorio raíz del proyecto (SimpleCalc-sdkClient en el comando anterior).
Inicialmente, hay dos archivos de código fuente: src/main/java/{package-path}/App.java y src/
test/java/{package-path}/AppTest.java. En este ejemplo, {package-path} es examples/aws/
apig/simpleCalc/sdk/app. Esta ruta del paquete se obtiene del valor de DarchetypeGroupdId. Puede
utilizar el archivo App.java como una plantilla para la aplicación cliente y puede añadir otros archivos
350
en la misma carpeta si es necesario. Puede utilizar el archivo AppTest.java como una plantilla de
pruebas unitarias para su aplicación y puede añadir otros archivos de código de prueba en la misma
carpeta de pruebas si es necesario.
7. Actualice las dependencias del paquete en el archivo pom.xml generado de la forma siguiente,
sustituyendo las propiedades groupId, artifactId, version y name, si es necesario:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/

XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>examples.aws.apig.simpleCalc.sdk.app</groupId>
<artifactId>SimpleCalc-sdkClient</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>SimpleCalc-sdkClient</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
<version>1.11.69</version>
</dependency>
<dependency>
<groupId>my-apig-api-examples</groupId>
<artifactId>simple-calc-sdk</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
8. A continuación, mostramos cómo llamar a la API mediante el SDK llamando a los

métodos getABOp(GetABOpRequest req), getApiRoot(GetApiRootRequest req) y
postApiRoot(PostApiRootRequest req) del SDK. Estos métodos se corresponden con los métodos
GET /{a}/{b}/{op}, GET /?a={x}&b={y}&op={operator} y POST /, con una carga de solicitudes de
API {"a": x, "b": y, "op": "operator"}, respectivamente.
351
Actualice el archivo App.java como se indica a continuación:
package examples.aws.apig.simpleCalc.sdk.app;
import java.io.IOException;
import com.amazonaws.opensdk.config.ConnectionConfiguration;
import com.amazonaws.opensdk.config.TimeoutConfiguration;
import examples.aws.apig.simpleCalc.sdk.*;
import examples.aws.apig.simpleCalc.sdk.model.*;
import examples.aws.apig.simpleCalc.sdk.SimpleCalcSdk.*;
public class App

{
SimpleCalcSdk sdkClient;
public App() {
initSdk();
}
// The configuration settings are for illustration purposes and may not be a
recommended best practice.
private void initSdk() {
sdkClient = SimpleCalcSdk.builder()
.connectionConfiguration(
new ConnectionConfiguration()
.maxConnections(100)
.connectionMaxIdleMillis(1000))
.timeoutConfiguration(
new TimeoutConfiguration()
.httpRequestTimeout(3000)
.totalExecutionTimeout(10000)
.socketTimeout(2000))
.build();
}
// Calling shutdown is not necessary unless you want to exert explicit control of
this resource.
public void shutdown() {
sdkClient.shutdown();
}
// GetABOpResult getABOp(GetABOpRequest getABOpRequest)

public Output getResultWithPathParameters(String x, String y, String operator) {
operator = operator.equals("+") ? "add" : operator;
operator = operator.equals("/") ? "div" : operator;
GetABOpResult abopResult = sdkClient.getABOp(new

GetABOpRequest().a(x).b(y).op(operator));
return abopResult.getResult().getOutput();
}
public Output getResultWithQueryParameters(String a, String b, String op) {

GetApiRootResult rootResult = sdkClient.getApiRoot(new
GetApiRootRequest().a(a).b(b).op(op));
return rootResult.getResult().getOutput();
}
public Output geResultByPostInputBody(Double x, Double y, String o) {

PostApiRootResult postResult = sdkClient.postApiRoot(
new PostApiRootRequest().input(new Input().a(x).b(y).op(o)));
return postResult.getResult().getOutput();
}
352
Usar un SDK de Android generado por API Gateway
public static void main( String[] args )

{
System.out.println( "Simple calc" );
// to begin
App calc = new App();
// call the SimpleCalc API

Output res = calc.getResultWithPathParameters("1", "2", "-");
System.out.printf("GET /1/2/-: %s\n", res.getC());
// Use the type query parameter

res = calc.getResultWithQueryParameters("1", "2", "+");
System.out.printf("GET /?a=1&b=2&op=+: %s\n", res.getC());
// Call POST with an Input body.

res = calc.geResultByPostInputBody(1.0, 2.0, "*");
System.out.printf("PUT /\n\n{\"a\":1, \"b\":2,\"op\":\"*\"}\n %s\n",
res.getC());
}
}
En el ejemplo anterior, los ajustes de configuración que se utilizan para crear instancias del cliente
SDK son para fines ilustrativos y no son necesariamente prácticas recomendadas. Además, la llamada
a sdkClient.shutdown() es opcional, especialmente si necesita un control preciso sobre cuándo se
liberan los recursos.
Hemos mostrado los patrones esenciales para llamar a una API utilizando un SDK de Java. Puede ampliar
las instrucciones para llamar a otros métodos de API.
Usar un SDK de Android generado por API

Gateway
En esta sección, se describen los pasos para utilizar un SDK de Android generado por API Gateway
de una API. Antes de continuar, debe haber completado los pasos de Generar los SDK para una API
mediante la consola de API Gateway (p. 319).
Note
El SDK generado no es compatible con Android 4.4 y versiones anteriores. Para obtener más
información, consulte Problemas conocidos (p. 474).
Para instalar y utilizar un SDK de Android generado por API Gateway
2. Descargue e instale Apache Maven (preferiblemente la versión 3.x).
3. Descargue e instale JDK (preferiblemente la versión 1.7 o posterior).
4. Establezca la variable de entorno JAVA_HOME.
5. Ejecute el comando mvn install para instalar los archivos de artefactos compilados en el repositorio de
Maven local. Se creará una carpeta target con la biblioteca del SDK compilada.
6. Copie el archivo de SDK (cuyo nombre se obtiene de los elementos Artifact Id y Artifact Version que
especificó cuando generó el SDK, por ejemplo, simple-calcsdk-1.0.0.jar) desde la carpeta target,
junto con todas las demás bibliotecas de la carpeta target/lib en la carpeta lib del proyecto.
353
Usar un SDK de Android generado por API Gateway
Si utiliza Android Studio, cree una carpeta libs en el módulo de la aplicación cliente y copie el
archivo .jar necesario en esta carpeta. Compruebe que la sección de dependencias del archivo gradle
del módulo contiene lo siguiente.
compile fileTree(include: ['*.jar'], dir: 'libs')

compile fileTree(include: ['*.jar'], dir: 'app/libs')
Asegúrese de que no haya archivos .jar declarados duplicados.

7. Utilice la clase ApiClientFactory para inicializar el SDK generado por API Gateway. Por ejemplo:
ApiClientFactory factory = new ApiClientFactory();
// Create an instance of your SDK.

final MyApiClient client = factory.build(MyApiClient.class);
// Invoke a method:
// If the API exposes a 'GET /?a=1&b=2&op=+' method, you can call the following SDK
method:
//
Result output = client.rootGet("1", "2", "+");
// where Result is the SDK class of the like-named API model.

//
// If the API exposes a 'GET /{a}/{b}/{op}' method, you can call the following SDK
method to invoke the request,
Result.output = client.aBOpGet(a, b, c);
// where a, b, c can be "1", "2", "add", respectively.
// You can call the following SDK methods invoke this POST API method:
// POST /
// host: ...
// Content-Type: application/json
//
// { "a": 1, "b": 2, "op": "+" }
Input body = new Input();
input.a=1;
input.b=2;
input.op="+";
Result output = client.rootPost(body);
// Parse the result:

// If the 'Result' object is { "a": 1, "b": 2, "op": "add", "c":3"}, you retrieve
the result 'c') as
String result=output.c;
8. Para utilizar un proveedor de credenciales de Amazon Cognito para autorizar las llamadas a la API,
utilice la clase ApiClientFactory para pasar un conjunto de credenciales de AWS mediante el SDK
generado por API Gateway, tal y como se muestra en el siguiente ejemplo.
// Use CognitoCachingCredentialsProvider to provide AWS credentials

// for the ApiClientFactory
AWSCredentialsProvider credentialsProvider = new CognitoCachingCredentialsProvider(
context, // activity context
"identityPoolId", // Cognito identity pool id
Regions.US_EAST_1 // region of Cognito identity pool
354
Usar un SDK de JavaScript generado por API Gateway
};
ApiClientFactory factory = new ApiClientFactory()

.credentialsProvider(credentialsProvider);
9. Para definir una clave de API mediante el SDK generado por API Gateway, utilice un código similar al
siguiente.
ApiClientFactory factory = new ApiClientFactory()

.apiKey("YOUR_API_KEY");
Usar un SDK de JavaScript generado por API

Gateway
Note
En estas instrucciones se presupone que ya ha completado las instrucciones de Generar los SDK
para una API mediante la consola de API Gateway (p. 319).
2. Habilite el uso compartido de recursos de origen cruzado (CORS) para todos los métodos a los que
llamará el SDK generado por API Gateway. Para obtener instrucciones, consulte Habilitar CORS para
un recurso (p. 235).
3. En la página web, incluya referencias a los siguientes scripts.
<script type="text/javascript" src="lib/axios/dist/axios.standalone.js"></script>

<script type="text/javascript" src="lib/CryptoJS/rollups/hmac-sha256.js"></script>
<script type="text/javascript" src="lib/CryptoJS/rollups/sha256.js"></script>
<script type="text/javascript" src="lib/CryptoJS/components/hmac.js"></script>
<script type="text/javascript" src="lib/CryptoJS/components/enc-base64.js"></script>
<script type="text/javascript" src="lib/url-template/url-template.js"></script>
<script type="text/javascript" src="lib/apiGatewayCore/sigV4Client.js"></script>
<script type="text/javascript" src="lib/apiGatewayCore/apiGatewayClient.js"></script>
<script type="text/javascript" src="lib/apiGatewayCore/simpleHttpClient.js"></script>
<script type="text/javascript" src="lib/apiGatewayCore/utils.js"></script>
<script type="text/javascript" src="apigClient.js"></script>
4. En el código, inicialice el SDK generado por API Gateway mediante un código similar al siguiente.
var apigClient = apigClientFactory.newClient();
5. Llame a los métodos de la API en API Gateway con un código similar al siguiente. Cada llamada
devuelve una promesa con devoluciones de llamada de éxito y fracaso.
var params = {
// This is where any modeled request parameters should be added.
// The key is the parameter name, as it is defined in the API in API Gateway.
param0: '',
param1: ''
};
355
Usar un SDK de iOS generado por
API Gateway en Objective-C o Swift
var body = {
// This is where you define the body of the request,
};
var additionalParams = {
// If there are any unmodeled query parameters or headers that must be
// sent with the request, add them here.
headers: {
param0: '',
param1: ''
},
queryParams: {
param0: '',
param1: ''
}
};
apigClient.methodName(params, body, additionalParams)

.then(function(result){
// Add success callback code here.
}).catch( function(result){
// Add error callback code here.
});
Aquí, methodName se crea a partir de la ruta y el código HTTP del recurso de la solicitud de método.
Por ejemplo, en el caso de la solicitud GET /, methodName es rootGet. Para la solicitud GET /a/b/op,
methodName será aBOpGet.
6. Para inicializar el SDK generado por API Gateway con credenciales de AWS, utilice un código similar
al siguiente. Si utiliza las credenciales de AWS, todas las solicitudes a la API se firmarán. Esto
significa que debe configurar los encabezados Accept de CORS adecuados para cada solicitud.
var apigClient = apigClientFactory.newClient({

accessKey: 'ACCESS_KEY',
secretKey: 'SECRET_KEY',
});
7. Para utilizar una clave de API con el SDK generado por API Gateway, puede pasar la clave de API
como parámetro al objeto Factory con un código similar al siguiente. Si utiliza una clave de API, esta
se especifica como parte del encabezado x-api-key y todas las solicitudes a la API se firmarán. Esto
significa que debe configurar los encabezados Accept de CORS adecuados para cada solicitud.
var apigClient = apigClientFactory.newClient({

apiKey: 'API_KEY'
});
Usar un SDK de iOS generado por API Gateway en

Objective-C o Swift
En este tutorial, le mostraremos cómo utilizar un SDK de iOS generado por API Gateway en una aplicación
Objective-C o Swift para llamar a la API subyacente. Usaremos la API SimpleCalc (p. 322) como ejemplo
para ilustrar los siguientes temas:
• Cómo instalar los componentes del SDK para móviles de AWS necesarios en el proyecto Xcode
• Cómo crear el objeto de cliente API antes de llamar a los métodos de la API
• Cómo llamar a los métodos de la API a través de los métodos del SDK correspondientes en el objeto del
cliente API
356
Usar el SDK de iOS generado
(Objective-C) para llamar a una API
• Cómo preparar una entrada de método y analizar el resultado utilizando las clases del modelo
correspondientes del SDK
Temas
• Usar el SDK de iOS generado (Objective-C) para llamar a una API (p. 357)
• Usar un SDK de iOS generado (Swift) para llamar a la API (p. 361)
Usar el SDK de iOS generado (Objective-C) para

llamar a una API
Antes de comenzar el siguiente procedimiento, debe completar los pasos de Generar los SDK para una
API mediante la consola de API Gateway (p. 319) para iOS en Objective-C y descargar el archivo .zip del
SDK generado.
Instalar el SDK para móviles de AWS y un SDK de iOS generado

por API Gateway en un proyecto Objective-C
En el procedimiento siguiente se describe cómo instalar el SDK.
Para instalar y utilizar un SDK de iOS generado por API Gateway en Objective-C
Con la API SimpleCalc (p. 322), puede cambiar el nombre de la carpeta del SDK descomprimido a
algo similar a sdk_objc_simple_calc. En esta carpeta del SDK hay un archivo README.md y un archivo
Podfile. El archivo README.md contiene las instrucciones para instalar y utilizar el SDK. Este tutorial
proporciona información detallada sobre estas instrucciones. La instalación usa CocoaPods para
importar las bibliotecas de API Gateway necesarias y otros componentes del SDK para móviles de
AWS dependientes. Debe actualizar el archivo Podfile para importar los SDK en el proyecto Xcode
de su aplicación. La carpeta del SDK descomprimida contiene también una carpeta generated-src
que incluye el código fuente del SDK generado de la API.
2. Inicie Xcode y cree un nuevo proyecto iOS Objective-C. Anote el destino del proyecto. Lo necesitará
para definirlo en el archivo Podfile.
3. Para importar AWS Mobile SDK for iOS en el proyecto Xcode mediante CocoaPods, haga lo siguiente:
1. Instale CocoaPods ejecutando el siguiente comando en una ventana del terminal:
sudo gem install cocoapods

pod setup
2. Copie el archivo Podfile de la carpeta del SDK extraído en el mismo directorio que contiene el
archivo del proyecto Xcode. Sustituya el siguiente bloque:
357
target '<YourXcodeTarget>' do
pod 'AWSAPIGateway', '~> 2.4.7'
end
por el nombre de destino de su proyecto:
target 'app_objc_simple_calc' do
end
Si su proyecto Xcode ya contiene un archivo denominado Podfile, añada la siguiente línea de

código:
3. Abra una ventana del terminal y ejecute el siguiente comando:
pod install
Se instalará el componente de API Gateway y otros componentes del SDK para móviles de AWS
dependientes.
4. Cierre el proyecto Xcode y, a continuación, abra el archivo .xcworkspace para volver a iniciar
Xcode.
5. Añada todos los archivos .h y .m del directorio generated-src del SDK extraído al proyecto
Xcode.
Para importar el AWS Mobile SDK for iOS Objective-C en su proyecto descargando de forma explícita
el SDK para móviles de AWS o mediante Carthage, siga las instrucciones del archivo README.md.
Asegúrese de utilizar únicamente una de estas opciones para importar el SDK para móviles de AWS.
358
Llamar a métodos de la API mediante el SDK de iOS generado

por API Gateway en un proyecto Objective-C
Cuando genera el SDK con el prefijo SIMPLE_CALC para esta API SimpleCalc (p. 322) con dos
modelos para la entrada (Input) y la salida (Result) de los métodos, en el SDK, el cliente API
resultante se convierte en SIMPLE_CALCSimpleCalcClient y las clases de datos correspondientes son
SIMPLE_CALCInput y SIMPLE_CALCResult, respectivamente. Las solicitudes y respuestas de la API se
asignan a los métodos del SDK de la siguiente manera:
• La solicitud de API
GET /?a=...&b=...&op=...
se convierte en el método del SDK
(AWSTask *)rootGet:(NSString *)op a:(NSString *)a b:(NSString *)b
La propiedad AWSTask.result es del tipo SIMPLE_CALCResult si el modelo Result se añadió a la

respuesta del método. De lo contrario, la propiedad es del tipo NSDictionary.
• Esta solicitud de API
POST /
{
"a": "Number",
"b": "Number",
"op": "String"
}
(AWSTask *)rootPost:(SIMPLE_CALCInput *)body
GET /{a}/{b}/{op}
(AWSTask *)aBOpGet:(NSString *)a b:(NSString *)b op:(NSString *)op
El siguiente procedimiento describe cómo llamar a los métodos de la API en el código fuente
de la aplicación Objective-C, por ejemplo, como parte del delegado viewDidLoad en un archivo
ViewController.m.
Para llamar a la API a través del SDK de iOS generado por API Gateway
1. Importe el archivo de encabezados de clase del cliente API para que la clase del cliente API se pueda
llamar en la aplicación:
#import "SIMPLE_CALCSimpleCalc.h"
359
La instrucción #import también importa SIMPLE_CALCInput.h y SIMPLE_CALCResult.h para las dos

clases de modelo.
2. Cree una instancia de la clase del cliente de API:
SIMPLE_CALCSimpleCalcClient *apiInstance = [SIMPLE_CALCSimpleCalcClient defaultClient];
Para utilizar Amazon Cognito con la API, establezca la propiedad defaultServiceConfiguration en

el objeto AWSServiceManager predeterminado, tal y como se muestra a continuación, antes de llamar
al método defaultClient para crear el objeto del cliente API (mostrado en el ejemplo anterior):
AWSCognitoCredentialsProvider *creds = [[AWSCognitoCredentialsProvider alloc]

initWithRegionType:AWSRegionUSEast1 identityPoolId:your_cognito_pool_id];
AWSServiceConfiguration *configuration = [[AWSServiceConfiguration alloc]
initWithRegion:AWSRegionUSEast1 credentialsProvider:creds];
AWSServiceManager.defaultServiceManager.defaultServiceConfiguration = configuration;
3. Llame al método GET /?a=1&b=2&op=+ para ejecutar 1+2:
[[apiInstance rootGet: @"+" a:@"1" b:@"2"] continueWithBlock:îd _Nullable(AWSTask *

_Nonnull task) {
_textField1.text = [self handleApiResponse:task];
return nil;
}];
donde la función auxiliar handleApiResponse:task formatea el resultado como una cadena que se
muestra en un campo de texto (_textField1).
- (NSString *)handleApiResponse:(AWSTask *)task {

if (task.error != nil) {
return [NSString stringWithFormat: @"Error: %@", task.error.description];
} else if (task.result != nil && [task.result isKindOfClass:[SIMPLE_CALCResult
class]]) {
return [NSString stringWithFormat:@"%@ %@ %@ = %@\n",task.result.input.a,
task.result.input.op, task.result.input.b, task.result.output.c];
}
return nil;
}
El resultado que se muestra es 1 + 2 = 3.

4. Llame al método POST / con una carga para ejecutar 1-2:
SIMPLE_CALCInput *input = [[SIMPLE_CALCInput alloc] init];

input.a = [NSNumber numberWithInt:1];
input.b = [NSNumber numberWithInt:2];
input.op = @"-";
[[apiInstance rootPost:input] continueWithBlock:îd _Nullable(AWSTask * _Nonnull
task) {
return nil;
}];
El resultado que se muestra es 1 - 2 = -1.

5. Llame al método GET /{a}/{b}/{op} para ejecutar 1/2:
[[apiInstance aBOpGet:@"1" b:@"2" op:@"div"] continueWithBlock:îd _Nullable(AWSTask *

_Nonnull task) {
360
Usar un SDK de iOS generado (Swift) para llamar a la API

return nil;
}];
El resultado que se muestra es 1 div 2 = 0.5. Aquí se usa div en lugar de / porque la función
Lambda simple (p. 321) del backend no administra variables de ruta codificadas como URL.
Usar un SDK de iOS generado (Swift) para llamar a la

API
Antes de comenzar el siguiente procedimiento, debe completar los pasos de Generar los SDK para una
API mediante la consola de API Gateway (p. 319) para iOS en Swift y descargar el archivo .zip del SDK
generado.
Temas
• Instalar el SDK para móviles de AWS y el SDK generado por API Gateway en un proyecto
Swift (p. 361)
• Llamar a métodos de API a través del SDK de iOS generado por API Gateway en un proyecto
Swift (p. 364)
Instalar el SDK para móviles de AWS y el SDK generado por API

Gateway en un proyecto Swift
En el procedimiento siguiente se describe cómo instalar el SDK.
Para instalar y utilizar un SDK de iOS generado por API Gateway en Swift
Con la API SimpleCalc (p. 322), puede cambiar el nombre de la carpeta del SDK descomprimido
a algo similar a sdk_swift_simple_calc. En esta carpeta del SDK hay un archivo README.md y un
archivo Podfile. El archivo README.md contiene las instrucciones para instalar y utilizar el SDK. Este
tutorial proporciona información detallada sobre estas instrucciones. La instalación utiliza CocoaPods
para importar los componentes del SDK para móviles de AWS necesarios. Debe actualizar el archivo
Podfile para importar los SDK en el proyecto Xcode de su aplicación Swift. La carpeta del SDK
descomprimida contiene también una carpeta generated-src que incluye el código fuente del SDK
generado de la API.
2. Inicie Xcode y cree un nuevo proyecto de iOS Swift. Anote el destino del proyecto. Lo necesitará para
definirlo en el archivo Podfile.
361
3. Para importar los componentes del SDK para móviles de AWS necesarios en el proyecto Xcode
mediante CocoaPods, haga lo siguiente:
1. Si no está instalado, instale CocoaPods ejecutando el siguiente comando en una ventana del
terminal:
sudo gem install cocoapods

pod setup
2. Copie el archivo Podfile de la carpeta del SDK extraído en el mismo directorio que contiene el
archivo del proyecto Xcode. Sustituya el siguiente bloque:
target '<YourXcodeTarget>' do
end
por el nombre de destino de su proyecto, tal y como se muestra a continuación:
target 'app_swift_simple_calc' do
end
Si su proyecto Xcode ya contiene un archivo Podfile con el destino correcto, solo tiene que
añadir la siguiente línea de código al bucle do ... end:
3. Abra una ventana del terminal y ejecute el siguiente comando en el directorio de la aplicación:
pod install
Se instalará el componente de API Gateway y todos los componentes del SDK para móviles de
AWS dependientes en el proyecto de la aplicación.
4. Cierre el proyecto Xcode y, a continuación, abra el archivo *.xcworkspace para volver a iniciar
Xcode.
5. Añada todos los archivos de encabezado del SDK (.h) y los archivos de código fuente de Swift
(.swift) del directorio generated-src extraído a su proyecto Xcode.
362
6. Para habilitar las llamadas a las bibliotecas de Objective-C del SDK para móviles de AWS de su
proyecto de código Swift, defina la ruta del archivo Bridging_Header.h en la propiedad Objective-
C Bridging Header en la opción Swift Compiler - General de la configuración de su proyecto
Xcode:
Tip
Puede escribir bridging en el cuadro de búsqueda de Xcode para encontrar la

propiedad Objective-C Bridging Header.
7. Compile el proyecto Xcode para verificar que está configurado correctamente antes de continuar.
Si su Xcode utiliza una versión más reciente de Swift que la admitida por el SDK para móviles de
AWS, recibirá errores del compilador de Swift. En este caso, establezca la propiedad Use Legacy
Swift Language Version en Yes en la opción Swift Compiler - Version:
363
Para importar el SDK para móviles de AWS para iOS en Swift en su proyecto descargando
explícitamente el SDK para móviles de AWS o utilizando Cartago, siga las instrucciones del archivo
README.md incluido con el paquete del SDK. Asegúrese de utilizar únicamente una de estas opciones
para importar el SDK para móviles de AWS.
Llamar a métodos de API a través del SDK de iOS generado por

API Gateway en un proyecto Swift
Cuando genera el SDK con el prefijo de SIMPLE_CALC para esta API SimpleCalc (p. 322) con dos modelos
para describir la entrada (Input) y la salida (Result) de las solicitudes y respuestas de la API, en el
SDK, el cliente API resultante se convierte en SIMPLE_CALCSimpleCalcClient y las clases de datos
correspondientes son SIMPLE_CALCInput y SIMPLE_CALCResult, respectivamente. Las solicitudes y
respuestas de la API se asignan a los métodos del SDK de la siguiente manera:
GET /?a=...&b=...&op=...
public func rootGet(op: String?, a: String?, b: String?) -> AWSTask
La propiedad AWSTask.result es del tipo SIMPLE_CALCResult si el modelo Result se añadió a la

respuesta del método. De lo contrario, es del tipo NSDictionary.
• Esta solicitud de API
POST /
{
"a": "Number",
"b": "Number",
"op": "String"
}
public func rootPost(body: SIMPLE_CALCInput) -> AWSTask
GET /{a}/{b}/{op}
public func aBOpGet(a: String, b: String, op: String) -> AWSTask
El siguiente procedimiento describe cómo llamar a los métodos de la API en el código fuente de la
aplicación Swift, por ejemplo, como parte del delegado viewDidLoad() en un archivo ViewController.m.
364
Para llamar a la API a través del SDK de iOS generado por API Gateway
1. Cree una instancia de la clase del cliente de API:
let client = SIMPLE_CALCSimpleCalcClient.defaultClient()
Para utilizar Amazon Cognito con la API, establezca la configuración del servicio de AWS
predeterminada (que se muestra a continuación) antes de obtener el método defaultClient
(mostrado anteriormente):
let credentialsProvider =
AWSCognitoCredentialsProvider(regionType: AWSRegionType.USEast1, identityPoolId:
"my_pool_id")
let configuration = AWSServiceConfiguration(region: AWSRegionType.USEast1,
credentialsProvider: credentialsProvider)
AWSServiceManager.defaultServiceManager().defaultServiceConfiguration = configuration
2. Llame al método GET /?a=1&b=2&op=+ para ejecutar 1+2:
client.rootGet("+", a: "1", b:"2").continueWithBlock {(task: AWSTask) -> AnyObject? in

self.showResult(task)
return nil
}
donde la función auxiliar self.showResult(task) imprime el resultado o el error en la consola; por

ejemplo:
func showResult(task: AWSTask) {

if let error = task.error {
print("Error: \(error)")
} else if let result = task.result {
if result is SIMPLE_CALCResult {
let res = result as! SIMPLE_CALCResult
print(String(format:"%@ %@ %@ = %@", res.input!.a!, res.input!.op!,
res.input!.b!, res.output!.c!))
} else if result is NSDictionary {
let res = result as! NSDictionary
print("NSDictionary: \(res)")
}
}
}
En una aplicación de producción, puede mostrar el resultado o el error en un campo de texto. El

resultado que se muestra es 1 + 2 = 3.
3. Llame al método POST / con una carga para ejecutar 1-2:
let body = SIMPLE_CALCInput()

body.a=1
body.b=2
body.op="-"
client.rootPost(body).continueWithBlock {(task: AWSTask) -> AnyObject? in
return nil
}
El resultado que se muestra es 1 - 2 = -1.

4. Llame al método GET /{a}/{b}/{op} para ejecutar 1/2:
365
Rastrear las llamadas a la API con CloudWatch
client.aBOpGet("1", b:"2", op:"div").continueWithBlock {(task: AWSTask) -> AnyObject?

in
return nil
}
El resultado que se muestra es 1 div 2 = 0.5. Aquí se usa div en lugar de / porque la función
Lambda simple (p. 321) del backend no administra variables de ruta codificadas como URL.
Rastrear las llamadas a la API con logs de

CloudWatch
Temas
• Registro de llamadas de administración de la API en Amazon API Gateway mediante AWS
CloudTrail (p. 366)
• Monitorizar API execution con Amazon CloudWatch (p. 368)
Para la ejecución de la API, API Gateway registra en Amazon CloudWatch las métricas de ejecución de
la API en los niveles de API y de etapa. Las métricas incluyen estadísticas de almacenamiento en caché,
latencia y errores detectados. También puede elegir que API Gateway envíe a CloudWatch métricas
de nivel de método, utilizando la consola de API Gateway (p. 297) o llamando a la API REST de API
Gateway o alguno de sus SDK. En función de estas métricas, puede configurar alarmas personalizadas
de CloudWatch para la resolución de problemas de desempeño de las API. Para obtener más información
sobre CloudWatch, consulte la Guía del usuario de Amazon CloudWatch.
Para la administración de la API mediante la API REST de API Gateway, puede crear registros de
seguimiento de AWS CloudTrail para registrar los eventos implicados en las llamadas a la API REST
de API Gateway. Puede utilizar los logs para solucionar problemas de creación, implementación y
actualizaciones de la API. También puede utilizar Amazon CloudWatch para monitorizar los logs de
CloudTrail. Para obtener más información sobre CloudTrail consulte la Guía del usuario de AWS
CloudTrail.
Note
CloudTrail registra las llamadas a la API REST de API Gateway que el desarrollador o propietario
de una API realiza al componente apigateway, mientras que CloudWatch registra las llamada a la
API que un cliente API realiza al componente execute-api de API Gateway.
Registro de llamadas de administración de la API en

Amazon API Gateway mediante AWS CloudTrail
Puede utilizar AWS CloudTrail para capturar las llamadas a la API REST de AWS en su cuenta de API
Gateway y enviar los archivos log a un bucket de Amazon S3 que especifique. Algunos ejemplos de
estas llamadas API incluyen la creación de una nueva API, recurso o método de API Gateway. CloudTrail
captura estas llamadas a la API desde la consola de API Gateway o desde las API de API Gateway
directamente. Con la información recopilada por CloudTrail, puede identificar la solicitud que se realizó
a API Gateway, la dirección IP de origen desde la que se realizó la solicitud, quién realizó la solicitud,
cuándo se realizó, etcétera. Para obtener más información sobre CloudTrail, incluido cómo configurarlo y
habilitarlo, consulte la AWS CloudTrail User Guide.
366
Registrar llamadas de administración
de la API con CloudTrail
Información de API Gateway en CloudTrail

Cuando el registro de CloudTrail está habilitado en su cuenta de AWS, las llamadas API realizadas en
acciones de API Gateway se registran en archivos log. Los registros de API Gateway se crean junto con
los registros de otros servicios de AWS en un archivo log. CloudTrail determina cuándo crear y escribir en
un nuevo archivo en función del período de tiempo y del tamaño del archivo.
Todas las acciones de API Gateway se registran y documentan en la API REST de API
Gateway (p. 470). Por ejemplo, las llamadas para crear una nueva API, recurso o método en API
Gateway generan entradas en archivos log de CloudTrail.
Cada entrada de log contiene información sobre quién generó la solicitud. La información de identidad del
usuario que figura en el log le ayudará a determinar si la solicitud se hizo con credenciales de usuario de
IAM o raíz, con credenciales de seguridad temporales para un rol o un usuario federado, o bien mediante
otro servicio de AWS. Para obtener más información, consulte el campo userIdentity en Referencia de
eventos de CloudTrail.
Puede almacenar los archivos de log en su bucket todo el tiempo que desee, y también puede definir
reglas de ciclo de vida de Amazon S3 para archivar o eliminar archivos de log automáticamente. De forma
predeterminada, los archivos de log se cifran mediante cifrado en el lado de servidor de Amazon S3 (SSE).
Puede elegir que CloudTrail publique notificaciones de Amazon SNS cuando se entreguen nuevos
archivos log para que pueda actuar con rapidez. Para obtener más información, consulte Configuring
Amazon SNS Notifications.
También puede añadir archivos log de API Gateway de varias regiones de AWS y de varias cuentas de
AWS en un solo bucket de Amazon S3. Para obtener más información, consulte Cómo añadir archivos de
log de CloudTrail a un solo bucket de Amazon S3.
Descripción de las entradas de archivos log de API Gateway

Los archivos de log de CloudTrail contienen una o varias entradas de log, cada una de las cuales está
compuesta por varios eventos con formato JSON. Una entrada de log representa una única solicitud de
cualquier origen e incluye información sobre la acción solicitada, los parámetros, la fecha y la hora de la
acción, etcétera. No se garantiza que las entradas de registro sigan un orden específico; es decir, no son
un rastro de la stack ordenada de las llamadas públicas al API.
En el ejemplo siguiente se muestra una entrada de registro de CloudTrail que ilustra la acción de obtención
de un recurso de API Gateway:
{
Records: [
{
eventVersion: "1.03",
userIdentity: {
type: "Root",
principalId: "AKIAI44QH8DHBEXAMPLE",
arn: "arn:aws:iam::123456789012:root",
accountId: "123456789012",
accessKeyId: "AKIAIOSFODNN7EXAMPLE",
sessionContext: {
attributes: {
mfaAuthenticated: "false",
creationDate: "2015-06-16T23:37:58Z"
}
}
},
eventTime: "2015-06-17T00:47:28Z",
eventSource: "apigateway.amazonaws.com",
eventName: "GetResource",
367
Monitorizar API execution con Amazon CloudWatch
awsRegion: "us-east-1",
sourceIPAddress: "203.0.113.11",
userAgent: "example-user-agent-string",
requestParameters: {
restApiId: "3rbEXAMPLE",
resourceId: "5tfEXAMPLE",
template: false
},
responseElements: null,
requestID: "6d9c4bfc-148a-11e5-81b6-7577cEXAMPLE",
eventID: "4d293154-a15b-4c33-9e0a-ff5eeEXAMPLE",
readOnly: true,
eventType: "AwsApiCall",
recipientAccountId: "123456789012"
},
... additional entries ...
]
}

Puede monitorizar API execution mediante CloudWatch, que recopila y procesa los datos sin formato de
API Gateway en métricas legibles y casi en tiempo real. Estas estadísticas se registran durante un periodo
de dos semanas, de forma que pueda acceder a información histórica y obtener una mejor perspectiva
sobre el rendimiento de su aplicación web o servicio. De forma predeterminada, los datos de las métricas
de API Gateway se envían automáticamente a CloudWatch en períodos de un minuto. Para obtener
más información, consulte What Are Amazon CloudWatch, Amazon CloudWatch Events, and Amazon
CloudWatch Logs? en la Guía del usuario de Amazon CloudWatch.
Las métricas mostradas por API Gateway proporcionan información que puede analizar de diferentes
maneras. En la siguiente lista se indican algunos usos frecuentes de las métricas. Se trata de sugerencias
que puede usar como punto de partida y no de una lista completa.
• Monitorice las métricas de IntegrationLatency para medir la capacidad de respuesta del backend.
• Monitorice las métricas de Latency para medir la capacidad de respuesta general de las llamadas a la
API.
• Monitorice las métricas de CacheHitCount y CacheMissCount para optimizar las capacidades de caché
para conseguir el desempeño deseado.
Temas
• Dimensiones y métricas de Amazon API Gateway (p. 368)
• Ver métricas de CloudWatch con el Panel de API de API Gateway (p. 370)
• Ver métricas de API Gateway en la consola de CloudWatch (p. 371)
• Herramientas de monitorización en AWS (p. 371)
Dimensiones y métricas de Amazon API Gateway

Las métricas y dimensiones que API Gateway envía a Amazon CloudWatch se indican a continuación.
Para obtener más información, consulte Monitorizar API execution con Amazon CloudWatch (p. 368).
Métricas de API Gateway

Amazon API Gateway envía datos de métricas a CloudWatch cada minuto.
El espacio de nombres de AWS/ApiGateway incluye las siguientes métricas.
368
Métrica Descripción
4XXError El número de errores del cliente capturados.
Unidad: recuento
5XXError El número de errores del servidor capturados.
Unidad: recuento
CacheHitCount El número de solicitudes servidas desde la caché de la

API.
Unidad: recuento
CacheMissCount El número de solicitudes servidas desde el back-end

cuando el almacenamiento en caché de la API está
habilitado.
Unidad: recuento
Recuento El número de llamadas a métodos de la API.
Unidad: recuento
IntegrationLatency El tiempo entre que API Gateway transmite una solicitud

al back-end y se recibe una respuesta del back-end.
Unidad: milisegundos
Latencia El tiempo entre que API Gateway recibe una solicitud

de un cliente y devuelve una respuesta al cliente. La
latencia incluye la latencia de la integración y otra carga
de API Gateway.
Unidad: milisegundos
Dimensiones de métricas
Puede usar las dimensiones de la tabla siguiente para filtrar las métricas de API Gateway.
Dimensión Descripción
ApiName Filtra las métricas de API Gateway para una API con el
nombre de API especificado.
ApiName, Method, Resource, Stage Filtra las métricas de API Gateway para un método
de API con la etapa, el recurso y el método de API
especificados.
API Gateway no enviará estas métricas a menos que

haya habilitado explícitamente las métricas detalladas
de CloudWatch. Para ello, puede usar la consola y
seleccionar Enable CloudWatch Metrics en la pestaña
Settings de una etapa. Otra opción consiste en llamar a
la acción stage:update de la API REST de API Gateway
para actualizar la propiedad metricsEnabled a true.
369
Dimensión Descripción
Si activa estas métricas, se le cobrarán cargos
adicionales en su cuenta. Para obtener información
sobre precios, consulte Precios de Amazon CloudWatch.
ApiName, Stage Filtra las métricas de API Gateway para una etapa de
API con la API y la etapa especificadas.
Ver métricas de CloudWatch con el Panel de API de API

Gateway
Puede utilizar el Panel de API de la consola de API Gateway para mostrar las métricas de CloudWatch de
la API implementada en API Gateway. Estas se muestran como un resumen de la actividad de la API a lo
largo del tiempo.
Temas
• Examinar actividades de la API en el panel (p. 370)
Requisitos previos
1. Debe tener una API creada en API Gateway. Siga las instrucciones en Crear una API (p. 73).
2. Debe haber implementado la API al menos una vez. Siga las instrucciones en Implementar una
API (p. 294).
3. Para obtener métricas de CloudWatch para métodos individuales, debe haber habilitado CloudWatch
Logs para esos métodos en una determinada etapa. El proceso se describe en Actualizar la
configuración de etapas (p. 297). Se realizará un cargo en su cuenta por el acceso a los logs de nivel
de método, pero no por el acceso a los logs de nivel de API o de etapa.
Examinar actividades de la API en el panel

2. Elija el nombre de la API.
3. En la API seleccionada, elija Dashboard.
4. Para mostrar un resumen de la actividad de la API a lo largo del tiempo, en Stage, elija la etapa que
desee.
5. Utilice From y To para escribir el intervalo de fechas.
6. Actualice, si es necesario, y consulte las métricas individuales que se muestran en gráficos
independientes denominados API Calls, Integration Latency, Latency, 4xx Error y 5xx Error. Los
gráficos CacheHitCount y CacheMissCount solo se mostrarán si se ha habilitado el almacenamiento
en caché de la API.
Tip
Para examinar las métricas de CloudWatch de nivel de método, asegúrese de que ha

habilitado CloudWatch Logs en el nivel de método. Para obtener más información sobre cómo
configurar el registro en el nivel de método, consulte Actualizar la configuración de etapas
mediante la consola de API Gateway (p. 297).
370
Ver métricas de API Gateway en la consola de CloudWatch

Para consultar las métricas mediante la consola de CloudWatch
Las métricas se agrupan en primer lugar por el espacio de nombres de servicio y, a continuación, por las
diversas combinaciones de dimensiones dentro de cada espacio de nombres.
1. Abra la consola de CloudWatch en https://console.aws.amazon.com/cloudwatch/.

2. Si es necesario, cambie la región. En la barra de navegación, seleccione la región donde residen sus
recursos de AWS. Para obtener más información, consulte Regiones y puntos de enlace.
3. En el panel de navegación, elija Metrics.
4. En el panel CloudWatch Metrics by Category, en la categoría de métricas de API Gateway, seleccione
una categoría de métricas y, a continuación, en el panel superior, desplácese hasta ver la lista
completa de métricas.
Para ver métricas mediante la CLI de AWS
• En el símbolo del sistema, ejecute el siguiente comando:
aws cloudwatch list-metrics --namespace "AWS/ApiGateway"
Herramientas de monitorización en AWS

AWS proporciona varias herramientas que puede utilizar para monitorizar API Gateway. Puede configurar
algunas de estas herramientas para que monitoricen automáticamente, pero otras herramientas requieren
intervención manual. Le recomendamos que automatice las tareas de monitorización en la medida de lo
posible.
Herramientas de monitorización automatizadas en AWS

Puede utilizar las siguientes herramientas de monitorización automatizada para monitorizar API Gateway e
informar cuando haya algún problema:
• Amazon CloudWatch Alarms: puede ver una única métrica durante el periodo que especifique y realizar
una o varias acciones según el valor de la métrica en relación con un determinado umbral durante una
serie de periodos de tiempo. La acción es una notificación que se envía a un tema de Amazon Simple
Notification Service (Amazon SNS) o a una política de Auto Scaling. Las alarmas de CloudWatch no
invocan acciones simplemente por tener un estado determinado. Es necesario que el estado haya
cambiado y se mantenga durante un número especificado de periodos. Para obtener más información,
consulte Monitorizar API execution con Amazon CloudWatch (p. 368).
• Amazon CloudWatch Logs: para monitorizar, almacenar y tener acceso a los archivos de registro de
AWS CloudTrail u otras fuentes. Para obtener más información, consulte Monitorizar los archivos de
registro en la Guía del usuario de Amazon CloudWatch.
• Amazon CloudWatch Events: seleccione los eventos y diríjalos a uno o varios flujos o funciones de
destino para realizar cambios, capturar información de estado y aplicar medidas correctivas. Para
obtener más información, consulte Uso de eventos en la Guía del usuario de Amazon CloudWatch.
• Monitorización de registros de AWS CloudTrail: compartir archivos de registro entre cuentas, monitorizar
archivos de registro de CloudTrail en tiempo real mediante su envío a CloudWatch Logs, escribir
aplicaciones de procesamiento de registros en Java y validar que sus archivos de registro no hayan
cambiado después de que CloudTrail los entregue. Para obtener más información, consulte Trabajar con
archivos de registro de CloudTrail en la AWS CloudTrail User Guide.
371
Herramientas de monitorización manual

Otra parte importante de la monitorización de API Gateway implica la monitorización manual de los
elementos que no cubren las alarmas de CloudWatch. API Gateway, CloudWatch y otros paneles de la
consola de AWS proporcionan una vista rápida del entorno de AWS. Le recomendamos que también
compruebe los archivos log de API execution.
• Los paneles de API Gateway muestran las siguientes estadísticas para una etapa de API determinada
durante un periodo de tiempo especificado:
• API Calls
• Cache Hit, solo cuando está habilitado el almacenamiento en caché de la API.
• Cache Miss, solo cuando está habilitado el almacenamiento en caché de la API.
• Latencia
• Integration Latency
• 4XX Error
• 5XX Error
• La página de inicio de CloudWatch muestra:
• Alarmas y estado actual
• Gráficos de alarmas y recursos
• Estado de los servicios
Además, puede utilizar CloudWatch para hacer lo siguiente:

• Crear paneles personalizados para monitorizar los servicios que le interesan.
• Realizar un gráfico con los datos de las métricas para resolver problemas y descubrir tendencias
• Buscar y examinar todas sus métricas de recursos de AWS.
• Crear y editar las alarmas de notificación de problemas
Crear alarmas de CloudWatch para monitorizar API Gateway

Puede crear una alarma de CloudWatch que envíe un mensaje de Amazon SNS cuando la alarma cambie
de estado. Una alarma vigila una única métrica durante el periodo especificado y realiza una o varias
acciones en función del valor de la métrica relativo a un determinado umbral durante una serie de periodos
de tiempo. La acción es una notificación que se envía a un tema de Amazon SNS o a una política de Auto
Scaling. Las alarmas invocan acciones únicamente para los cambios de estado prolongados. Las alarmas
de CloudWatch no invocan acciones simplemente por tener un estado determinado. Es necesario que el
estado haya cambiado y se mantenga durante un número especificado de periodos.
372
Extensiones de API Gateway para

Swagger
Las extensiones de API Gateway admiten las integraciones de API de autorización específica de AWS
y específica de API Gateway. En esta sección, describiremos las extensiones de API Gateway para la
especificación de Swagger.
Tip
Para comprender cómo se usan las extensiones de API Gateway en una aplicación, puede utilizar
la consola de API Gateway para crear la API y exportarla a un archivo de definición de Swagger.
Para obtener más información sobre cómo exportar una API, consulte Exportar una API (p. 317).
Temas
• Objeto x-amazon-apigateway-any-method (p. 374)
• Objeto x-amazon-apigateway-authorizer (p. 374)
• Propiedad x-amazon-apigateway-authtype (p. 378)
• Propiedad x-amazon-apigateway-binary-media-types (p. 378)
• Objeto x-amazon-apigateway-documentation (p. 378)
• Objeto x-amazon-apigateway-gateway-responses (p. 379)
• Objeto x-amazon-apigateway-gateway-responses.gatewayResponse (p. 380)
• Objeto x-amazon-apigateway-gateway-responses.responseParameters (p. 381)
• Objeto x-amazon-apigateway-gateway-responses.responseTemplates (p. 382)
• Objeto x-amazon-apigateway-integration (p. 382)
• Objeto x-amazon-apigateway-integration.requestTemplates (p. 385)
• Objeto x-amazon-apigateway-integration.requestParameters (p. 386)
• Objeto x-amazon-apigateway-integration.responses (p. 387)
• Objeto x-amazon-apigateway-integration.response (p. 388)
• Objeto x-amazon-apigateway-integration.responseTemplates (p. 389)
• Objeto x-amazon-apigateway-integration.responseParameters (p. 390)
• Propiedad x-amazon-apigateway-request-validator (p. 391)
• Objeto x-amazon-apigateway-request-validators (p. 391)
373
x-amazon-apigateway-any-method
• Objeto x-amazon-apigateway-request-validators.requestValidator (p. 392)
Objeto x-amazon-apigateway-any-method
Especifica el objeto Operation de Swagger para el método catch-all ANY de API Gateway en un objeto Path
Item de Swagger. Este objeto puede existir junto con otros objetos Operation y capturar cualquier método
HTTP que no se haya declarado de forma explícita.
En la siguiente tabla se muestran las propiedades ampliadas por API Gateway. Para el resto de las
propiedades del objeto Operation de Swagger, consulte la especificación de Swagger.
Properties
Nombre de propiedad Tipo Descripción
x-amazon-apigateway- Objeto x-amazon-apigateway- Especifica la integración del

integration integration (p. 382) método con el backend. Se trata
de una propiedad extendida del
objeto Operation de Swagger.
La integración puede ser del
tipo AWS, AWS_PROXY, HTTP,
HTTP_PROXY o MOCK.
Ejemplo de x-amazon-apigateway-any-method
En el siguiente ejemplo se integra el método ANY en un recurso de proxy, {proxy+}, con una función
Lambda, TestSimpleProxy.
"/{proxy+}": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "proxy",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {},
arn:aws:lambda:us-east-1:123456789012:function:TestSimpleProxy/invocations",
"type": "aws_proxy"
}
Objeto x-amazon-apigateway-authorizer
Define un autorizador personalizado que debe aplicarse a la autorización de invocaciones de método en
API Gateway. Este objeto es una propiedad extendida del objeto Swagger Security Definitions Operation.
374
Ejemplos de x-amazon-apigateway-authorizer
Properties
type string El tipo del autorizador. Se trata

de una propiedad necesaria.
El valor debe ser "token" para
un autorizador con la identidad
del intermediario incrustada
en un token de autorización o
"request" para un autorizador
con la identidad del intermediario
incluida en los parámetros de
solicitud.
authorizerUri string El identificador uniforme de

recursos (URI) de la función
Lambda del autorizador. La
sintaxis es la siguiente:
"arn:aws:apigateway:us-
east-1:lambda:path/2015-03-31/
functions/arn:aws:lambda:us-
east-1:account-
id:function:auth_function_name/
invocations"
authorizerCredentials string Las credenciales necesarias

para invocar el autorizador, si
existen, en forma de ARN de
un rol de ejecución de IAM.
Por ejemplo, "arn:aws:iam::id-
cuenta:rol_IAM".
identitySource string Lista separada por comas de las

expresiones de mapeo de los
parámetros de solicitud como en
la fuente de identidad. Aplicable
solo para el autorizador del tipo
"request".
identityValidationExpression string Una expresión regular para

validar el token y la identidad de
entrada. Por ejemplo, "^ x- [a-
z]+".
authorizerResultTtlInSeconds string El número de segundos durante

los que se almacena en caché la
política de IAM resultante.
El siguiente ejemplo de definiciones de seguridad de Swagger especifica un autorizador personalizado del
tipo "token" denominado test-authorizer.
"securityDefinitions" : {
375
"test-authorizer" : {
"type" : "apiKey", // Required and the value must be "apiKey"
for an API Gateway API.
"name" : "Authorization", // The name of the header containing the
authorization token.
"in" : "header", // Required and the value must be "header"
for an API Gateway API.
"x-amazon-apigateway-authtype" : "oauth2", // Specifies the authorization mechanism
for the client.
"x-amazon-apigateway-authorizer" : { // An API Gateway custom authorizer
definition
"type" : "token", // Required property and the value must
"token"
"authorizerUri" : "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/
arn:aws:lambda:us-east-1:account-id:function:function-name/invocations",
"authorizerCredentials" : "arn:aws:iam::account-id:role",
"identityValidationExpression" : "^x-[a-z]+",
"authorizerResultTtlInSeconds" : 60
}
}
}
El siguiente fragmento del objeto de funcionamiento de Swagger establece el método GET /http para
utilizar el autorizador personalizado especificado anteriormente.
"/http" : {
"get" : {
"responses" : { },
"security" : [ {
"test-authorizer" : [ ]
} ],
"type" : "http",
"responses" : {
"default" : {
}
},
"uri" : "http://api.example.com"
}
}
}
El siguiente ejemplo de definiciones de seguridad de Swagger especifica un autorizador personalizado

del tipo "request" con un único parámetro de encabezado (auth) como fuente de identidad. El elemento
securityDefinitions se denomina request_authorizer_single_header.
"request_authorizer_single_header" : {
"type" : "apiKey",
"name" : "auth", // The name of a single header or query parameter as
the identity source.
"in" : "header", // The location of the single identity source request
parameter. The valid value is "header" or "query"
"x-amazon-apigateway-authtype" : "custom",
"x-amazon-apigateway-authorizer" : {
"type" : "request",
"identitySource" : "method.request.header.auth", // Reqeust parameter mapping
expression of the identity source. In this example, it is the 'auth' header.
"authorizerCredentials" : "arn:aws:iam::123456789012:role/AWSepIntegTest-CS-
LambdaRole",
376
arn:aws:lambda:us-east-1:123456789012:function:APIGateway-Request-Authorizer:vtwo/
invocations",
}
}
}
El siguiente ejemplo de definiciones de seguridad de Swagger especifica un autorizador personalizado del

tipo "request" con un encabezado (HeaderAuth1) y un parámetro de cadena de consulta QueryString1
como fuentes de identidad.
"request_authorizer_header_query" : {
"type" : "apiKey",
"name" : "Unused", // Must be "Unused" for multiple identity sources or
non header or query type of request parameters.
"in" : "header", // Must be "header" for multiple identity sources or
"type" : "request",
"identitySource" : "method.request.header.HeaderAuth1,
method.request.querystring.QueryString1", // Request parameter mapping expressions of
the identity sources.
LambdaRole",
invocations",
}
}
}
El siguiente ejemplo de definiciones de seguridad de Swagger especifica un autorizador personalizado de

API Gateway del tipo "request" con una única variable de etapa (stage) como fuente de identidad.
"request_authorizer_single_stagevar" : {
"type" : "apiKey",
"name" : "Unused", // Must be "Unused", for multiple identity sources or
"in" : "header", // Must be "header", for multiple identity sources or
"type" : "request",
"identitySource" : "stageVariables.stage", // Request parameter mapping
expression of the identity source. In this example, it is the stage variable.
LambdaRole",
invocations",
}
}
}
377
x-amazon-apigateway-authtype
Propiedad x-amazon-apigateway-authtype
Especifica el tipo de un autorizador personalizado. Se analiza mediante las características de importación y
exportación de API de API Gateway.
Esta propiedad es una propiedad extendida del objeto Swagger Security Definitions Operation.
Ejemplo de x-amazon-apigateway-authtype
El siguiente ejemplo establece el tipo de un autorizador personalizado mediante OAuth 2.
"cust-authorizer" : {
"type" : "...", // required
"name" : "...", // name of the identity source header
"in" : "header", // must be header
"x-amazon-apigateway-authtype" : "oauth2", // Specifies the authorization mechanism
for the client.
...
}
}
El siguiente ejemplo de definición de seguridad especifica la autorización mediante AWS Signature Version
4:
"sigv4" : {
"type" : "apiKey",
"name" : "Authorization",
"in" : "header",
"x-amazon-apigateway-authtype" : "awsSigv4"
}
Propiedad x-amazon-apigateway-binary-media-
types
Especifica la lista de tipos de medios binarios que se admiten en API Gateway, como application/octet-
stream, image/jpeg, etc. Esta extensión es una matriz JSON.
Ejemplo de x-amazon-apigateway-binary-media-types
El siguiente ejemplo muestra el orden de búsqueda de codificación de una API.
"x-amazon-apigateway-binary-media-types: [ "application/octet", "image/jpeg" ]
Objeto x-amazon-apigateway-documentation
Define las piezas de documentación que se van a importar a API Gateway. Este objeto es un objeto JSON
que contiene una matriz de instancias DocumentationPart.
378
Ejemplo de x-amazon-apigateway-documentation
Properties
documentationParts Array Una matriz de instancias

DocumentationPart exportadas o
importadas.
version String El identificador de versión de

la snapshot de las piezas de
documentación exportadas.
Ejemplo de x-amazon-apigateway-documentation
El siguiente ejemplo de la extensión de API Gateway para Swagger define instancias DocumentationParts
para que se importen o exporten desde una API en API Gateway.
{ ...
"x-amazon-apigateway-documentation": {
"version": "1.0.3",
"documentationParts": [
{
"location": {
"type": "API"
},
"properties": {
"description": "API description",
"info": {
"description": "API info description 4",
"version": "API info version 3"
}
}
},
{
… // Another DocumentationPart instance
}
]
}
}
Objeto x-amazon-apigateway-gateway-responses
Define las respuestas de gateway de una API como un mapa de pares de clave-valor de cadena a
GatewayResponse.
Properties
responseType x-amazon-apigateway-gateway- Un atributo GatewayResponse

responses.gatewayResponse (p. 380)
para el elemento responseType
especificado.
379
Ejemplo de x-amazon-apigateway-gateway-responses
Ejemplo de x-amazon-apigateway-gateway-responses
El siguiente ejemplo de extensión de API Gateway para Swagger define un mapa de GatewayResponses
que contiene dos instancias de GatewayResponse, una para el tipo DEFAULT_4XX y otra para el tipo
INVALID_API_KEY.
"{
x-amazon-apigateway-gateway-responses": {
"DEFAULT_4XX": {
"gatewayresponse.header.Access-Control-Allow-Origin": "'domain.com'"
},
"application/json": "{\"message\": test 4xx b }"
}
},
"INVALID_API_KEY": {
"application/json": "{\"message\": test forbidden }"
}
}
}
}
Objeto x-amazon-apigateway-gateway-
responses.gatewayResponse
Define una respuesta de gateway de un tipo de respuesta determinado, incluido el código de estado, todos
los parámetros de respuesta aplicables o las plantillas de respuesta.
Properties
responseParameters x-amazon-apigateway-gateway- Especifica los parámetros de

responses.responseParameters (p. GatewayResponse,
381) es decir,
los parámetros de encabezado.
Los valores de los parámetros
pueden tomar cualquier valor de
parámetro de solicitud (p. 147)
entrante o un valor personalizado
estático.
responseTemplates x-amazon-apigateway-gateway- Especifica las plantillas de

responses.responseTemplates (p. 382)
asignación de la respuesta de
gateway. El motor de VTL no
procesa las plantillas.
statusCode string Un código de estado HTTP para

la respuesta de gateway.
380
Ejemplo de x-amazon-apigateway-
gateway-responses.gatewayResponse
Ejemplo de x-amazon-apigateway-gateway-
responses.gatewayResponse
El siguiente ejemplo de la extensión de API Gateway para Swagger define un objeto GatewayResponse
para personalizar la respuesta INVALID_API_KEY y devolver el código de estado 456, el valor del
encabezado api-key de la solicitud entrante y el mensaje "Bad api-key".
"INVALID_API_KEY": {
"gatewayresponse.header.api-key": "method.request.header.api-key"
},
"application/json": "{\"message\": \"Bad api-key\" }"
}
}
responses.responseParameters
Define un mapa de cadena a cadena de pares de clave-valor para generar parámetros de respuesta de
gateway a partir de los parámetros de la solicitud entrante o mediante cadenas literales.
Properties
gatewayresponse.param- string param-position puede ser

position.param-name header, path o querystring.
Para obtener más información,
consulte Asignar datos
de solicitud de método a
parámetros de solicitud de
integración (p. 147).
responses.repsonseParameters
El siguiente ejemplo de extensión de Swagger muestra una expresión de asignación de parámetros de
respuesta GatewayResponse para habilitar la compatibilidad de CORS con recursos en los dominios
*.example.domain.
"gatewayresponse.header.Access-Control-Allow-Origin": '*.example.domain',
"gatewayresponse.header.from-request-header" : method.request.header.Accept,
"gatewayresponse.header.from-request-path" : method.request.path.petId,
"gatewayresponse.header.from-request-query" : method.request.querystring.qname
}
381
x-amazon-apigateway-gateway-
responses.responseTemplates
Define las plantillas de asignación de GatewayResponse, como un mapa de cadena a cadena de pares de
clave-valor, para una respuesta de gateway especificada. Para cada par de clave-valor, la clave es el tipo
de contenido (por ejemplo, "application/json") y el valor es una plantilla de asignación en forma de cadena
para sustituciones de variables simples. El motor de Velocity Template Language (VTL) no procesa una
plantilla de asignación de GatewayResponse.
Properties
content-type string Una plantilla de asignación de

cuerpo de GatewayResponse que
admite únicamente sustituciones
de variables sencillas para
personalizar un cuerpo de
respuesta de gateway.
El siguiente ejemplo de extensión de Swagger muestra una plantilla de asignación de GatewayResponse
para personalizar una respuesta de error generada por API Gateway en un formato específico de la
aplicación.
"application/json": "{ \"message\": $context.error.messageString, \"type\":
$context.error.responseType, \"statusCode\": '488' }
}
El siguiente ejemplo de extensión de Swagger muestra una plantilla de asignación de GatewayResponse

para invalidar una respuesta de error generada por API Gateway con un mensaje de error estático.
"application/json": "{ \"message\": 'API-specific errors' }" }
}
Objeto x-amazon-apigateway-integration
Especifica los detalles de la integración del backend utilizada para este método. Esta extensión es una
propiedad extendida del objeto Operation de Swagger. El resultado es un objeto de integración de API
Gateway.
382
x-amazon-apigateway-integration
Properties
cacheKeyParameters Una matriz de string Una lista de parámetros de la

solicitud cuyos valores se van a
almacenar en caché.
cacheNamespace string Un grupo de etiquetas

específicas de la API de
parámetros almacenados en
caché relacionados.
credentials string Para las credenciales basadas

en roles de AWS IAM,
especifique el ARN de un rol
de IAM. Si no se especifica,
las credenciales adoptarán
de manera predeterminada
los permisos basados en
recursos que se deben añadir
manualmente para permitir a
la API tener acceso al recurso.
Para obtener más información,
consulte Granting Permissions
Using a Resource Policy. Nota:
cuando utilice credenciales de
IAM, asegúrese de que los punto
de enlace regionales STS de
AWS están habilitados para la
región en la que se implementa
esta API para obtener un
desempeño óptimo.
contentHandling string Tipos de conversión de

codificación de la carga de
solicitud. Los valores válidos
son 1) CONVERT_TO_TEXT, para
convertir una carga binaria
en una cadena codificada en
Base64 o para convertir una
carga de texto en una cadena
codificada en utf-8 o para
transferir la carga de texto de
forma nativa sin modificaciones,
y 2) CONVERT_TO_BINARY, para
convertir una carga de texto
en un blob descodificado en
Base64 o para transferir una
carga binaria de forma nativa sin
modificaciones.
httpMethod string El método HTTP utilizado en la

solicitud de integración. Para
las invocaciones de funciones
Lambda, el valor debe ser POST.
383
Ejemplo de x-amazon-apigateway-integration
passthroughBehavior string Especifica cómo se pasa

una carga de solicitud de
tipo de contenido sin asignar
a través de la solicitud de
integración sin modificación.
Los valores admitidos
son when_no_templates,
when_no_match y never.
Para obtener más
información, consulte
Integration.passthroughBehavior.
requestParameters Objeto x-amazon-apigateway- Especifica las asignaciones de

integration.requestParameters (p. 386)
los parámetros de solicitud de
método a los parámetros de
solicitud de integración. Los
parámetros de solicitud admitidos
son querystring, path, header y
body.
requestTemplates Objeto x-amazon-apigateway- Plantillas de asignación para una

integration.requestTemplates (p. 385)
carga de solicitud de tipos MIME
especificados.
responses Objeto x-amazon-apigateway- Define las respuestas del método

integration.responses (p. 387) y especifica las asignaciones de
parámetros o de carga deseadas
desde respuestas de integración
a respuestas de método.
type string El tipo de integración con

el backend especificado. El
valor válido es http (para la
integración con un backend
HTTP) o aws (para la integración
con funciones AWS Lambda u
otros servicios de AWS, como
Amazon DynamoDB, Amazon
Simple Notification Service o
Amazon Simple Queue Service).
uri string El URI del punto de enlace del

backend. Para integraciones
del tipo aws, este es un valor de
ARN. Para la integración HTTP,
esta es la dirección URL del
punto de enlace HTTP incluido el
esquema https o http.
Ejemplo de x-amazon-apigateway-integration
En el siguiente ejemplo se integra un método POST de una API con una función Lambda en el backend.
Para fines de demostración, en las plantillas de asignación de ejemplo en requestTemplates y
responseTemplates de los ejemplos que aparecen a continuación se asume que se aplica la siguiente
384
x-amazon-apigateway-integration.requestTemplates
carga con formato JSON: { "name":"value_1", "key":"value_2", "redirect": {"url" :"..."} }

para generar una salida JSON { "stage":"value_1", "user-id":"value_2" } o una salida XML
<stage>value_1</stage>.
"type" : "aws",
"uri" : "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/
arn:aws:lambda:us-east-1:012345678901:function:HelloWorld/invocations",
"httpMethod" : "POST",
"credentials" : "arn:aws:iam::012345678901:role/apigateway-invoke-lambda-exec-role",
"requestTemplates" : {
"application/json" : "#set ($root=$input.path('$')) { \"stage\":
\"$root.name\", \"user-id\": \"$root.key\" }",
"application/xml" : "#set ($root=$input.path('$')) <stage>$root.name</
stage> "
},
"integration.request.path.stage" : "method.request.querystring.version",
"integration.request.querystring.provider" : "method.request.querystring.vendor"
},
"cacheNamespace" : "cache namespace",
"cacheKeyParameters" : [],
"responses" : {
"2\\d{2}" : {
"method.response.header.requestId" : "integration.response.header.cid"
},
"application/json" : "#set ($root=$input.path('$')) { \"stage\":
\"$root.name\", \"user-id\": \"$root.key\" }",
"application/xml" : "#set ($root=$input.path('$')) <stage>$root.name</
stage> "
}
},
"302" : {
"method.response.header.Location" :
"integration.response.body.redirect.url"
}
},
"default" : {
}
}
}
}
Tenga en cuenta que las comillas dobles (") de la cadena JSON en las plantillas de asignación deben
incluirse en una secuencia de escape (\").
Objeto x-amazon-apigateway-
integration.requestTemplates
Especifica las plantillas de asignación de una carga de solicitud de los tipos MIME especificados.
385
Properties
MIME type string Un ejemplo de tipo MIME

es application/json. Para
obtener información acerca de
la creación de una plantilla de
asignación, consulte Plantillas de
asignación (p. 127).
El siguiente ejemplo especifica las plantillas de asignación de una carga de solicitud de los tipos MIME
application/json y application/xml.
"requestTemplates" : {
"application/json" : "#set ($root=$input.path('$')) { \"stage\": \"$root.name\",
\"user-id\": \"$root.key\" }",
"application/xml" : "#set ($root=$input.path('$')) <stage>$root.name</stage> "
}
integration.requestParameters
Especifica las asignaciones de los parámetros de solicitud de método designados a los parámetros de
solicitud de integración. Los parámetros de solicitud de método deben estar definidos para poder hacer
referencia a ellos.
Properties
integration.request.<param- string El valor debe ser un parámetro

type>.<param-name> de solicitud de método
predefinido con el formato
method.request.<param-
type>.<param-name>, donde
<param-type> puede ser
querystring, path, header o
body. Para el parámetro body,
<param-name> es una expresión
de ruta JSON sin el prefijo $.
x-amazon-apigateway-integration.requestParameters Ejemplo
El siguiente ejemplo de asignaciones de parámetros de solicitud traduce la consulta (version),
el encabezado, (x-user-id) y los parámetros de ruta (service) de la solicitud de método en la
386
x-amazon-apigateway-integration.responses
consulta (stage), encabezado (x-userid) y los parámetros de ruta (op) de la solicitud de integración,
respectivamente.
"integration.request.querystring.stage" : "method.request.querystring.version",
"integration.request.header.x-userid" : "method.request.header.x-user-id",
"integration.request.path.op" : "method.request.path.service"
},
Objeto x-amazon-apigateway-integration.responses
Define las respuestas del método y especifica las asignaciones de parámetros o de carga desde
respuestas de integración a respuestas de método.
Properties
Patrón de estado de Objeto x-amazon-apigateway- Expresión regular de selección

respuesta integration.response (p. 388) utilizada para cotejar la
respuesta de integración con
la respuesta de método. Para
las integraciones HTTP, esta
expresión regular se aplica
al código de estado de la
respuesta de integración. Para
las invocaciones de Lambda,
la expresión regular se aplica
al campo errorMessage del
objeto de información del error
devuelto por AWS Lambda como
un cuerpo de respuesta de error
cuando la ejecución de la función
Lambda produce una excepción.
Note
El nombre de propiedad
Patrón de estado
de respuesta hace
referencia a un código
de estado de respuesta
o a una expresión
regular que describe
un grupo de códigos de
estado de respuesta.
No se corresponde con
ningún identificador
de un recurso
IntegrationResponse
en la API REST de API
Gateway.
387
x-amazon-apigateway-integration.responses Ejemplo
x-amazon-apigateway-integration.responses Ejemplo
El siguiente ejemplo muestra una lista de respuestas 2xx y 302. Para la respuesta 2xx, la respuesta del
método se asigna desde la carga de la respuesta de integración del tipo MIME application/json o
application/xml. Esta respuesta utiliza las plantillas de asignación proporcionadas. Para la respuesta
302, la respuesta del método devuelve un encabezado Location cuyo valor se obtiene de la propiedad
redirect.url de la carga de la respuesta de integración.
"responses" : {
"2\\d{2}" : {
"application/json" : "#set ($root=$input.path('$')) { \"stage\": \"$root.name
\", \"user-id\": \"$root.key\" }",
}
},
"302" : {
"method.response.header.Location": "integration.response.body.redirect.url"
}
}
}
Objeto x-amazon-apigateway-integration.response
Define una respuesta y especifica asignaciones de parámetros o asignaciones de carga desde la
respuesta de integración a la respuesta del método.
Properties
statusCode string Código de estado HTTP para

la respuesta de método (por
ejemplo, "200"). Se debe
corresponder con una respuesta
coincidente en el campo
Swagger Operation responses.
responseTemplates Objeto x-amazon-apigateway- Especifica las plantillas de

integration.responseTemplates (p. 389)
asignación específicas del
tipo MIME para la carga de la
respuesta.
responseParameters Objeto x-amazon-apigateway- Especifica las asignaciones de

integration.responseParameters (p. parámetros
390) para la respuesta.
Solo los parámetros header
y body de la respuesta de
integración se pueden asignar
a los parámetros header del
método.
388
x-amazon-apigateway-integration.response Ejemplo
contentHandling string Tipos de conversión de

codificación de la carga de la
respuesta. Los valores válidos
son 1) CONVERT_TO_TEXT, para
convertir una carga binaria
en una cadena codificada en
Base64 o para convertir una
carga de texto en una cadena
codificada en utf-8 o para
transferir la carga de texto de
forma nativa sin modificaciones,
y 2) CONVERT_TO_BINARY, para
convertir una carga de texto
en un blob descodificado en
Base64 o para transferir una
carga binaria de forma nativa sin
modificaciones.
x-amazon-apigateway-integration.response Ejemplo
El siguiente ejemplo define una respuesta 302 para el método que obtiene una carga del tipo MIME
application/json o application/xml del backend. La respuesta utiliza las plantillas de asignación
proporcionadas y devuelve la URL de redireccionamiento de la respuesta de integración en el encabezado
Location del método.
{
},
"method.response.header.Location": "integration.response.body.redirect.url"
}
}
integration.responseTemplates
Especifica las plantillas de asignación de una carga de respuesta de los tipos MIME especificados.
Properties
MIME type string Especifica una plantilla de

asignación para transformar
389
integration.responseTemplate

el cuerpo de la respuesta de
integración en el cuerpo de la
respuesta del método para un
tipo MIME especificado. Para
obtener información acerca de
la creación de una plantilla de
asignación, consulte Plantillas de
asignación (p. 127). Un ejemplo
de tipo MIME es application/
json.
integration.responseTemplate
El siguiente ejemplo especifica las plantillas de asignación de una carga de solicitud de los tipos MIME
application/json y application/xml.
}
integration.responseParameters
Especifica las asignaciones de parámetros del método de integración a parámetros de la respuesta del
método. Solo los tipos header y body de los parámetros de respuesta de integración se pueden asignar al
tipo header de la respuesta de método.
Properties
method.response.header.<param- string El valor del parámetro designado

name> se puede obtener únicamente
de los tipos header y body de los
parámetros de la respuesta de
integración.
x-amazon-apigateway-integration.responseParameters Ejemplo
El siguiente ejemplo asigna los parámetros body y header de la respuesta de integración a dos parámetros
header de la respuesta del método.
390
x-amazon-apigateway-request-validator
"method.response.header.Location" : "integration.response.body.redirect.url",
"method.response.header.x-user-id" : "integration.response.header.x-userid"
}
Propiedad x-amazon-apigateway-request-validator
Especifica un validador de solicitudes, haciendo referencia a un request_validator_name del mapa Objeto
x-amazon-apigateway-request-validators (p. 391) , para habilitar la validación de solicitudes en la API
contenedora o en un método. El valor de esta extensión es una cadena JSON.
Esta extensión puede especificarse en el nivel de API o en el nivel de método. El validador de nivel de API
se aplica a todos los métodos, a menos que lo invalide el validador de nivel de método.
x-amazon-apigateway-request-validator Ejemplo
El siguiente ejemplo aplica el validador de solicitudes basic en el nivel de API aplicando al mismo tiempo
el validador de solicitudes parameter-only a la solicitud POST /validation.
{
"swagger": "2.0",
"basic" : {
},
"params-only" : {
}
},
"x-amazon-apigateway-request-validator" : "basic",
"paths": {
"/validation": {
"post": {
...
}
}
Objeto x-amazon-apigateway-request-validators
Define los validadores de solicitudes admitidos para la API contenedora como un mapa entre un nombre
de validador y las reglas de validación de solicitudes asociadas. Esta extensión se aplica a una API.
Properties
request_validator_name Objeto x-amazon- Especifica las reglas de

apigateway-request- validación del validador
validators.requestValidator (p. 392) designado. Por ejemplo:
"basic" : {
"validateRequestBody" :
true,
391
x-amazon-apigateway-request-validators Ejemplo
"validateRequestParameters" :
true
},
Para aplicar este validador a

un método específico, haga
referencia al nombre del
validador (basic) como el valor
de la propiedad Propiedad x-
amazon-apigateway-request-
validator (p. 391).
x-amazon-apigateway-request-validators Ejemplo
El siguiente ejemplo muestra un conjunto de validadores de solicitudes para una API como un mapa entre
un nombre de validador y las reglas de validación de solicitudes asociadas.
{
"swagger": "2.0",
...
"basic" : {
},
"params-only" : {
}
},
...
}
Objeto x-amazon-apigateway-request-
validators.requestValidator
Especifica las reglas de validación de un validador de solicitudes como parte de la definición del mapa
Objeto x-amazon-apigateway-request-validators (p. 391).
Properties
validateRequestBody Boolean Especifica si se debe validar el

cuerpo de la solicitud (true) o no
(false).
validateRequestParameters Boolean Especifica si se deben validar

los parámetros de solicitud
obligatorios (true) o no (false).
392
x-amazon-apigateway-request-
validators.requestValidator Ejemplo
x-amazon-apigateway-request-validators.requestValidator Ejemplo
El siguiente ejemplo muestra un validador de solicitudes de solo parámetros:
"params-only": {
}
393
Crear una API para funciones Lambda
Ejemplos y tutoriales
Los siguientes tutoriales proporcionan ejercicios prácticos para ayudarle a obtener información sobre API
Gateway.
Temas
• Crear una API de API Gateway para funciones AWS Lambda (p. 394)
• Crear una API como un proxy de Amazon S3 (p. 413)
• Crear una API de API Gateway como un proxy de Amazon Kinesis (p. 439)
Crear una API de API Gateway para funciones

AWS Lambda
Note
Para integrar su API de API Gateway con Lambda, debe elegir una región en la que los servicios
API Gateway y Lambda estén disponibles. Para conocer la disponibilidad de las regiones,
consulte Regiones y puntos de enlace.
En la sección Introducción (p. 45), ha aprendido a utilizar la consola de API Gateway para crear una API
para exponer una función Lambda. Ahí, la consola le permite elegir Lambda Function para Integration type,
entre otras opciones de HTTP, Mock y AWS Service. La opción Lambda Function es un caso especial de tipo
de integración de AWS Service y simplifica la preparación de la integración con valores de configuración
predeterminados. Por ejemplo, con la primera, la consola añade automáticamente los permisos basados
en recursos necesarios para invocar la función Lambda. Con la última, tiene más control, pero también
más responsabilidades a la hora de configurar la integración, incluida la creación y especificación de un
rol de IAM que contenga los permisos adecuados. Para ambas opciones, el elemento Integration.type
subyacente es AWS en la API REST de API Gateway y su archivo de definición de Swagger.
En esta sección, le guiaremos por los pasos para integrar una API con una función Lambda utilizando
los tipos de integración AWS Service y Lambda Function. Para admitir la invocación asíncrona de la
394
Crear una API para funciones Lambda
función Lambda, debe añadir de forma explícita el encabezado X-Amz-Invocation-Type:Event a la

solicitud de integración. Para la invocación sincrónica, puede añadir el encabezado X-Amz-Invocation-
Type:RequestResponse a la solicitud de integración o dejarlo sin especificar. El siguiente ejemplo muestra
la solicitud de integración de una invocación de función Lambda asíncrona:
POST /2015-03-31/functions/FunctionArn/invocations?Qualifier=Qualifier HTTP/1.1

X-Amz-Invocation-Type: Event
...
Authorization: ...
Content-Length: PayloadSize
Payload
En este ejemplo, FunctionArn es el ARN de la función Lambda que se invoca. El encabezado

Authorization es necesario para la invocación segura de funciones Lambda a través de HTTPS. Para
obtener más información, consulte la acción Invoke en la AWS Lambda Developer Guide.
Para ilustrar cómo crear y configurar una API como un servicio de proxy de AWS para Lambda, crearemos
una función Lambda (Calc) que realiza las operaciones de suma (+), resta (-), multiplicación (*) y
división (/). Cuando un cliente envíe una solicitud de método para realizar alguna de estas operaciones,
API Gateway publicará la solicitud de integración correspondiente para llamar a la función Lambda
especificada, pasando la entrada necesaria (dos operandos y un operador) como una carga JSON. Una
llamada sincrónica devolverá el resultado, si hay alguno, como una carga JSON. Una llamada asíncrona
no devolverá ningún dato.
Puede exponer un método GET o POST en el recurso /calc para invocar la función Lambda. Con
el método GET, un cliente proporciona la entrada a la función Lambda del backend a través de tres
parámetros de cadena de consulta (operand1, operand2 y operator). Configurará una plantilla de
asignación para asignar estos parámetros a la carga JSON de la solicitud de integración. Con el método
POST, un cliente proporciona la entrada a la función Lambda como una carga JSON de la solicitud del
método. Puede pasar la carga de la solicitud del método a la solicitud de integración si la entrada del
cliente es compatible con el modelo de entrada. También puede exponer un método GET en el recurso /
calc/{operand1}/{operand2}/{operator}. Con este método, el cliente especifica la entrada de la función
Lambda como los valores de los parámetros de ruta. Necesitará proporcionar una plantilla de asignación
para convertir los parámetros de ruta de la solicitud del método en una carga de la solicitud de integración
como la entrada de la función Lambda y para traducir la salida de las respuestas de integración en la
respuesta del método.
En este tutorial, se explicarán los siguientes temas:
• Crear la función Lambda Calc para implementar las operaciones aritméticas, aceptando y devolviendo
entradas y salidas con formato JSON.
• Exponer GET en el recurso /calc para invocar la función Lambda proporcionando la entrada como
cadenas de consulta. Activaremos un validador de solicitudes para garantizar que el cliente envía
todos los parámetros de cadenas de consulta necesarios antes de que API Gateway llame a la función
Lambda.
• Exponer POST en el recurso /calc para invocar la función Lambda proporcionando la entrada en la
carga. Activaremos un validador de solicitudes para garantizar que el cliente envía la carga de solicitud
válida antes de que API Gateway llame a la función Lambda.
• Exponer GET en el recurso /calc/{operand1}/{operand2}/{operator} para invocar la función Lambda
especificando la entrada en los parámetros de ruta. Explicaremos también cómo definir un esquema
Result para crear un modelo del cuerpo de respuesta del método, de forma que cualquier SDK con
establecimiento inflexible de tipos de la API pueda tener acceso a los datos de la respuesta del método a
través de las propiedades definidas en el esquema Result.
395
Configurar un rol y una política de IAM para
que una API invoque funciones Lambda
Puede examinar la API de ejemplo en su archivo de definición de Swagger (p. 409). También puede
importar las definiciones de Swagger de la API a API Gateway, siguiendo las instrucciones de Importar una
API (p. 217).
Para utilizar la consola de API Gateway para crear la API, primero debe inscribirse para obtener una
cuenta de AWS.

Para permitir que la API invoque funciones Lambda, debe tener un rol de IAM que tenga las políticas
adecuadas de IAM asociadas. En la siguiente sección se describe cómo verificar y crear, si es necesario,
el rol y las políticas de IAM necesarios.
Temas
• Configurar un rol y una política de IAM para que una API invoque funciones Lambda (p. 396)
• Crear una función Lambda en el backend (p. 397)
• Crear recursos de API para la función Lambda (p. 398)
• Crear un método GET con parámetros de consulta para llamar a la función Lambda (p. 399)
• Crear un método POST con una carga JSON para llamar a la función Lambda (p. 402)
• Crear un método GET con parámetros de ruta para llamar a la función Lambda (p. 405)
• Definiciones de Swagger de una API de ejemplo integrada con una función Lambda (p. 409)
Configurar un rol y una política de IAM para que una

API invoque funciones Lambda
Para que API Gateway invoque una función Lambda, la API debe tener un permiso para llamar a la acción
InvokeFunction de Lambda. Esto significa que, como mínimo, debe asociar la siguiente política de IAM a
un rol de IAM para que API Gateway asuma la política.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "*"
}
]
}
Si no promulga esta política, el intermediario de la API recibirá una respuesta 500 Internal Server Error. La
respuesta contiene el mensaje de error "Invalid permissions on Lambda function". Para obtener una lista
completa de los mensajes de error devueltos por Lambda, consulte el tema Invocar.
Un rol asumible por API Gateway es un rol de IAM con la siguiente relación de confianza:
396
Crear una función Lambda en el backend
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
Crear una función Lambda en el backend

El siguiente procedimiento describe los pasos para crear una función Lambda mediante la consola de
Lambda.
1. Vaya a la consola de Lambda.

2. Seleccione Create a Lambda function.
3. Elija el proyecto Blank Function para el motor de tiempo de ejecución de Node.js 4.3 o una versión
posterior.
4. Sigue las instrucciones que aparecen en pantalla para el editor Lambda function code.
5. Copie la siguiente función Lambda y péguela en el editor de código en la consola de Lambda.
console.log('Loading the Calc function');

if (event.a === undefined || event.b === undefined || event.op === undefined) {
callback("400 Invalid Input");
}
var res = {};

res.a = Number(event.a);
res.b = Number(event.b);
res.op = event.op;
if (isNaN(event.a) || isNaN(event.b)) {
callback("400 Invalid Operand");
}
switch(event.op)
{
case "+":
case "add":
res.c = res.a + res.b;
break;
case "-":
case "sub":
res.c = res.a - res.b;
break;
case "*":
case "mul":
res.c = res.a * res.b;
break;
case "/":
397
Crear recursos de API para la función Lambda
case "div":
res.c = res.b===0 ? NaN : Number(event.a) / Number(event.b);
break;
default:
callback("400 Invalid Operator");
break;
}
callback(null, res);
};
6. Elija un rol de IAM existente o cree uno nuevo.

7. Siga las instrucciones que aparecen en pantalla para terminar de crear la función.
Esta función requiere dos operandos (a y b) y un operador (op) del parámetro de entrada event. La entrada
es un objeto JSON con el siguiente formato:
{
"a": "Number" | "String",
"b": "Number" | "String",
"op": "String"
}
Esta función devuelve el resultado calculado (c) y la entrada. Si se trata de una entrada no válida, la
función devuelve el valor null o la cadena "Invalid op" como resultado. La salida tiene el siguiente formato
JSON:
{
"a": "Number",
"b": "Number",
"op": "String",
"c": "Number" | "String"
}
Debe probar la función en la consola de Lambda antes de integrarla con la API en el siguiente paso.
Crear recursos de API para la función Lambda

El procedimiento siguiente describe cómo crear recursos de API para la función Lambda. A modo de
ilustración, usaremos varios recursos y métodos de API para habilitar diferentes comportamientos de la
API para la llamada a la misma función.
Para crear recursos de API para funciones Lambda
1. En la consola de API Gateway, cree una API denominada LambdaGate.

2. Cree el recurso /calc fuera de la raíz de la API. Vamos a exponer los métodos GET y POST en este
recurso para que el cliente invoque la función Lambda del backend. El intermediario tendrá que
proporcionar la entrada necesaria como parámetros de cadena de consulta (que se declaran como
?operand1=...&operand2=...&operator=...) en la solicitud GET y como una carga JSON en la
solicitud POST, respectivamente.
También vamos a crear el subárbol de recursos /calc/{operand1}/{operand2}/{operator} para exponer

el método GET que invoca la función Lambda. El intermediario tendrá que proporcionar la entrada
necesaria especificando los tres parámetros de ruta (operand1, operand2 y operator).
398
Crear un método GET con parámetros de
consulta para llamar a la función Lambda
Crear un método GET con parámetros de consulta

para llamar a la función Lambda
Mediante la creación de un método de GET con los parámetros de consulta para llamar a la función
Lambda, podemos dejar que el usuario de la API realice los cálculos a través de cualquier navegador. Esto
puede resultar especialmente útil si la API permite el acceso abierto.
Para configurar el método GET con cadenas de consulta para invocar la función Lambda
1. En la consola de API Gateway, elija el recurso /calc de la API en Resources.

2. Elija Create Method en el menú desplegable Actions para crear el método GET.
3. En el panel Set up que aparece,
a. Elija AWS Service en Integration type.

b. Elija la región (p. ej., us-west-2) donde creó la función Lambda para AWS Region.
c. Elija Lambda en AWS Service.
d. Deje AWS Subdomain en blanco, porque nuestra función Lambda no está alojada en ningún
subdominio de AWS.
e. Elija POST en HTTP method. Lambda requiere que se use la solicitud POST para invocar cualquier
función Lambda. Este ejemplo muestra que el método HTTP en una solicitud de método del
frontend puede diferir de la solicitud de integración en el backend.
f. Elija Use path override en Action Type. Esta opción nos permite especificar el ARN de la acción
Invoke para ejecutar nuestra función Calc.
g. Escriba /2015-03-31/functions/arn:aws:lambda:region:account-id:function:Calc/
invocations en Path override.
h. Especifique el ARN de un rol de IAM para Execution role. Puede encontrar el ARN del rol en la
consola de IAM. El rol debe contener los permisos necesarios para que el intermediario llame a la
función Calc y para que API Gateway asuma el rol del intermediario.
i. Deje Passthrough con el valor predeterminado de Content Handling, ya que no trataremos con
datos binarios.
j. Elija Save para terminar de configurar el método GET /calc.
Si la configuración se ha realizado correctamente, debería tener el siguiente aspecto:
399
También puede añadir, en Integration Request, el encabezado X-Amz-Invocation-Type: Event |

RequestReponse | DryRun para que la acción se invoque de manera asíncrona, como solicitud y
respuesta, o como una ejecución de prueba, respectivamente. Si no se especifica el encabezado, la
acción se invocará como solicitud y respuesta.
4. Vaya a Method Request para configurar los parámetros de consulta del método GET en /calc para
recibir la entrada a la función Lambda del backend.
a. Elija el icono del lápiz que aparece junto a Request Validator para seleccionar Validate query
string parameters and headers. Esta configuración provocará un mensaje de error para volver
a establecer los parámetros que faltan si el cliente no los especifica. No se le cobrará por la
llamada al backend.
b. Amplíe la sección URL Query String Parameters. Elija Add query string para añadir los
parámetros de consulta operand1, operand2 y operator. Active la opción Required de cada
parámetro para asegurarse de que se validan.
La configuración ahora tiene el siguiente aspecto:
400
5. Vuelva a Integration Request para configurar la plantilla de mapeo para traducir las cadenas de
consulta proporcionadas por el cliente en la carga de la solicitud de integración, de conformidad con la
función Calc.
a. Amplíe la sección Body Mapping Templates.

b. Elija When no template matches the request Content-Type header en Request body
passthrough.
c. Si no se muestra application/json en Content-Type, elija Add mapping template para añadirlo.
d. Y, a continuación, especifique y guarde el siguiente script de asignación en el editor de plantillas
de asignación:
{
"a": "$input.params('operand1')",
"b": "$input.params('operand2')",
"op": "$input.params('operator')"
}
Esta plantilla asigna los tres parámetros de cadena de consulta declarados en Method Request
en los valores de propiedad designados del objeto JSON como entrada a la función Lambda del
backend. El objeto JSON transformado se incluirá como la carga de la solicitud de integración.
La configuración final de este paso tiene el siguiente aspecto:
401
Crear un método POST con una carga
JSON para llamar a la función Lambda
6. Ahora puede elegir Test para verificar que el método GET en el recurso /calc se ha configurado
correctamente para invocar la función Lambda.
Crear un método POST con una carga JSON para

llamar a la función Lambda
Al crear un método POST con una carga JSON para llamar a la función LAM, esperamos que el cliente
envíe la entrada necesaria a la función del backend en el cuerpo de la solicitud. Para garantizar que el
cliente carga los datos de entrada correctos, habilitaremos la validación de solicitudes en la carga.
Para configurar el método POST con una carga JSON para invocar una función Lambda
1. Vaya a la consola de API Gateway y elija la API que creó anteriormente.

2. Resalte el recurso /calc en el panel Resources.
3. Elija Create Method en el menú Actions para crear el método POST /calc.
402
4. En el panel Set Up del método, configure este método POST con la siguiente configuración de
integración. Para obtener más información, siga las explicaciones de Crear un método GET con
parámetros de consulta para llamar a la función Lambda (p. 399).
5. Elija Models en la API desde el panel de navegación principal de la consola de API Gateway para
crear modelos de datos para la entrada y la salida del método:
a. Elija Create en el panel Models. Escriba Input en Model name, escriba application/json en
Content type y escriba la siguiente definición de esquema en Model schema:
{
"type":"object",
"properties":{
"a":{"type":"number"},
"b":{"type":"number"},
"op":{"type":"string"}
},
"title":"Input"
}
Este modelo describe la estructura de datos de entrada y se utilizará para validar el cuerpo de la
solicitud entrante.
b. Elija Create en el panel Models. Escriba Output en Model name, escriba application/json en
{
"type":"object",
"properties":{
"c":{"type":"number"}
},
"title":"Output"
}
403
Este modelo describe la estructura de datos de la salida calculada desde el backend. Se puede
utilizar para asignar los datos de la respuesta de integración a un modelo diferente. Este tutorial
se basa en el comportamiento de paso a través y no utiliza este modelo.
c. Elija Create en el panel Models. Escriba Result en Model name, escriba application/json en
{
"type":"object",
"properties":{
"input":{
"$ref":"https://apigateway.amazonaws.com/restapis/restapi-id/models/
Input"
},
"output":{
"$ref":"https://apigateway.amazonaws.com/restapis/restapi-id/models/
Output"
}
},
"title":"Output"
}
Este modelo describe la estructura de datos de los datos de respuesta devueltos. Hace referencia
a los esquemas Input y Output definidos en la API especificada (restapi-id). Una vez más, este
modelo no se utiliza en este tutorial, ya que se utiliza el comportamiento de paso a través.
6. En la opción de configuración Method Request, realice las siguientes operaciones para habilitar la
validación de solicitudes en el cuerpo de la solicitud entrante:
a. Elija el icono del lápiz que aparece junto a Request Validator para elegir Validate body.
b. Amplíe la sección Request Body y elija Add model.
c. Escriba application/json en el campo de entrada Content-Type y elija Input en la lista
desplegable en la columna Model name.
7. Ahora puede elegir Test para verificar que el método POST funciona según lo previsto. La siguiente
entrada:
{
"a": 1,
"b": 2,
"op": "+"
}
debería producir la siguiente salida:
{
"a": 1,
"b": 2,
"op": "+",
"c": 3
}
Si desea implementar este método como una llamada asíncrona, puede añadir un encabezado
InvocationType en la solicitud del método y asignarlo al encabezado X-Amz-Invocation-Type en la
solicitud de integración con un valor estático de 'Event' o con la expresión de asignación del encabezado
404
Crear un método GET con parámetros
de ruta para llamar a la función Lambda
method.request.header.InvocationType. En el último caso, el cliente debe incluir el encabezado

InvocationType:Event en la solicitud del método. La llamada asíncrona devolverá una respuesta vacía,
en su lugar.
Crear un método GET con parámetros de ruta para

llamar a la función Lambda
En esta sección, crearemos un método GET en un recurso especificado por una secuencia de parámetros
de ruta para llamar a la función Lambda del backend. Los valores de los parámetros de ruta especifican los
datos de entrada a la función Lambda. Definiremos una plantilla de asignación para asignar los valores de
los parámetros de ruta entrantes a la carga de la solicitud de integración necesaria.
Además, usaremos la característica de integración sencilla de LAM proporcionada por ABP para configurar
el método. Como puede ver, esta característica proporcionada por la consola ofrece experiencias de
usuario mucho más optimizadas.
Para configurar el método GET con los parámetros de ruta URL para llamar a la función Lambda
1. Vaya a la consola de API Gateway.

2. Resalte el recurso /calc/{operand1}/{operand2}/{operator} en el árbol Resources de la API creada
anteriormente.
3. Elija Create Method en el menú desplegable Actions, elija GET.
4. En el panel Setup, elija Lambda Function en Integration type, para utilizar el proceso de configuración
optimizado habilitado por la consola.
5. Elija una región (por ejemplo, us-west-2) para Lambda Region. Esta es la región en la que se aloja la
función Lambda.
6. Elija una función Lambda existente (por ejemplo, Calc) para Lambda Function.
7. Elija Save y, a continuación, elija OK para aceptar Add Permissions to Lambda Function.
8. Elija Integration Request para configurar la plantilla de mapeo de cuerpo.
a. Amplíe la sección Body Mapping Templates.

b. Elija Add mapping template.
c. Escriba application/json para Content-Type y, a continuación, elija el icono de marca de
verificación para abrir el editor de la plantilla.
d. Elija Yes, secure this integration para continuar.
e. Escriba el siguiente script de asignación en el editor de la plantilla:
{
"a": "$input.params('operand1')",
"b": "$input.params('operand2')",
"op":
#if($input.params('operator')=='%2F')"/"#{else}"$input.params('operator')"#end
Esta plantilla asigna los tres parámetros de ruta URL, declarados cuando se creó el recurso /
calc/{operand1}/{operand2}/{operator}, a los valores de propiedad designados del objeto JSON.
Como las rutas URL deben estar codificadas como direcciones URL, el operador de división debe
especificarse como %2F en lugar de /. Esta plantilla traduce %2F en / antes de pasarlo a la función
Lambda.
f. Guarde la plantilla de asignación.
Cuando el método está configurado correctamente, la configuración debe ser similar a la siguiente:
405
9. Ahora, vamos a probar la API mediante la característica TestInvoke de la consola.
a. Elija Test en Method Execution.

b. Escriba 1, 2 y + en los campos {operand1}, {operand2} y {operator}, respectivamente.
c. Elija Test.
d. El resultado será similar al siguiente:
406
Este resultado de prueba muestra la salida original de la función Lambda del backend, tal como se ha
pasado a través de la respuesta de integración sin asignación, ya que no hemos configurado ninguna
plantilla de asignación. A continuación, crearemos el modelo de la estructura de datos de la carga de
la respuesta del método detrás del esquema Result.
10. De forma predeterminada, el cuerpo de la respuesta del método se asigna a un modelo vacío. Esto
hará que el cuerpo de la respuesta de integración se transfiera sin asignación. Sin embargo, cuando
genere un SDK para alguno de los lenguajes con establecimiento inflexible de tipos, como Java u
Objective-C, los usuarios del SDK recibirán un objeto vacío como resultado. Para garantizar que el
cliente REST y los clientes del SDK reciban el resultado deseado, debe crear los datos de la respuesta
mediante un esquema predefinido. A continuación, le mostraremos cómo definir un modelo para el
cuerpo de la respuesta del método y cómo crear una plantilla de asignación para transformar el cuerpo
de la respuesta de integración en el cuerpo de la respuesta del método.
a. En /calc/{operand1}/{operand2}/{operator} - GET - Method Execution, elija Method Response.

b. Expanda la respuesta 200,
c. En la sección Response Body for 200. Si no se ha asignado ningún modelo para la respuesta del
método,
d. Elija el icono de lápiz situado junto al modelo para el tipo de contenido application/json.
407
e. Elija un modelo predefinido en la lista desplegable Models. En este tutorial, este modelo es
Result.
f. Guarde el modelo elegido.
Note
Si no se ha definido ningún modelo para el tipo de contenido application/json, elija Add

Response Model y siga las instrucciones que aparecen en pantalla para añadir el modelo.
Al configurar el modelo para el cuerpo de la respuesta del método, nos aseguramos que los datos de
la respuesta se emitan en el objeto Result de un determinado SDK. Para ello, también tenemos que
asegurarnos de que la respuesta de integración se asigne según corresponda, tema que abordaremos
a continuación.
11. Para devolver los resultados del backend de acuerdo con el esquema especificado,
a. Elija Integration Response y expanda la entrada de la respuesta del método 200.

b. Amplíe la sección Body Mapping Templates.
c. Elija o añada application/json a la lista Content-Type.
d. Elija Result en la lista desplegable Generate template para abrir el proyecto de plantilla Result.
e. Cambie el proyecto de plantilla de la siguiente manera:
{
"input" : {
"a" : $inputRoot.a,
"b" : $inputRoot.b,
"op" : "$inputRoot.op"
},
"output" : {
"c" : $inputRoot.c
}
}
f. Seleccione Save.
g. Para probar la plantilla de mapeo, elija Test en Method Execution y escriba 1 2 y + en los campos
de entrada operand1, operand2 y operator, respectivamente. La respuesta de integración de la
función Lambda ahora se asigna a un objeto Result:
{
"input": {
"a": 1,
"b": 2,
"op": "+"
},
"output": {
"c": 3
}
}
12. Para que la API esté accesible fuera de la característica Test Invoke de la consola de API Gateway,
elija Deploy API en el menú desplegable Actions. Asegúrese de repetir la implementación de la API
siempre que termine de añadir, modificar o eliminar un recurso o un método, actualizando todas
las asignaciones de datos y todas las configuraciones de las etapas. De lo contrario, las nuevas
características o actualizaciones no estarán disponibles.
408
Definiciones de Swagger de una API
de ejemplo para una función Lambda
Definiciones de Swagger de una API de ejemplo

integrada con una función Lambda
{
"swagger": "2.0",
"info": {
"version": "2017-04-20T04:08:08Z",
"title": "LambdaGate"
},
"host": "uojnr9hd57.execute-api.us-east-1.amazonaws.com",
"schemes": [
"https"
],
"paths": {
"/calc": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "operand2",
"in": "query",
"required": true,
"type": "string"
},
{
"name": "operator",
"in": "query",
"required": true,
"type": "string"
},
{
"name": "operand1",
"in": "query",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"operand_1": {
"type": "string"
},
"operand_2": {
"type": "string"
},
"operator": {
"type": "string"
}
}
}
},
409
"x-amazon-apigateway-request-validator": "Validate query string parameters and

headers",
"credentials": "arn:aws:iam::123456789012:role/apigAwsProxyRole",
"responses": {
"default": {
"method.response.header.operator": "integration.response.body.op",
"method.response.header.operand_2": "integration.response.body.b",
"method.response.header.operand_1": "integration.response.body.a"
},
"application/json": "#set($res = $input.path('$'))\n{\n \"result\":
\"$res.a, $res.b, $res.op => $res.c\",\n \"a\" : \"$res.a\",\n \"b\" : \"$res.b\",\n
\"op\" : \"$res.op\",\n \"c\" : \"$res.c\"\n}"
}
}
},
"uri": "arn:aws:apigateway:us-west-2:lambda:path//2015-03-31/functions/
"application/json": "{\n \"a\": \"$input.params('operand1')\",\n \"b\":
\"$input.params('operand2')\", \n \"op\": \"$input.params('operator')\" \n}"
},
"type": "aws"
}
},
"post": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "InvocationType",
"in": "header",
"required": false,
"type": "string"
},
{
"in": "body",
"name": "Input",
"required": true,
"schema": {
}
}
],
"responses": {
"200": {
"schema": {
}
}
},
"x-amazon-apigateway-request-validator": "Validate body",
"responses": {
"default": {
410
$inputRoot.a,\n \"b\" : $inputRoot.b,\n \"op\" : $inputRoot.op,\n \"c\" : $inputRoot.c
\n}"
}
}
},
"uri": "arn:aws:apigateway:us-west-2:lambda:path//2015-03-31/functions/
"type": "aws"
}
}
},
"/calc/{operand1}/{operand2}/{operator}": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"name": "operand2",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "operator",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "operand1",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
}
}
},
411
"application/json": "{\n \"a\": \"$input.params('operand1')\",\n \"b\":
\"$input.params('operand2')\",\n \"op\": #if($input.params('operator')=='%2F')\"/
\"#{else}\"$input.params('operator')\"#end\n \n}"
},
"contentHandling": "CONVERT_TO_TEXT",
"type": "aws"
}
}
}
},
"definitions": {
"Input": {
"type": "object",
"required": [
"a",
"b",
"op"
],
"properties": {
"a": {
"type": "number"
},
"b": {
"type": "number"
},
"op": {
"type": "string",
"description": "binary op of ['+', 'add', '-', 'sub', '*', 'mul', '%2F', 'div']"
}
},
"title": "Input"
},
"Output": {
"type": "object",
"properties": {
"c": {
"type": "number"
}
},
"title": "Output"
},
"Result": {
"type": "object",
"properties": {
"input": {
},
"output": {
"$ref": "#/definitions/Output"
}
},
"title": "Result"
}
},
"x-amazon-apigateway-request-validators": {
"Validate body": {
"validateRequestParameters": false,
"validateRequestBody": true
},
"Validate query string parameters and headers": {
"validateRequestParameters": true,
"validateRequestBody": false
}
}
412
Crear una API como un proxy de Amazon S3
Crear una API como un proxy de Amazon S3

Para ilustrar cómo usar una API en API Gateway como un proxy de Amazon S3, en esta sección se
describe cómo crear y configurar una API para exponer las siguientes operaciones de Amazon S3:
• Exponer GET en el recurso raíz de la API para mostrar todos los buckets de Amazon S3 de un
intermediario
• Exponer GET en un recurso de carpeta para ver una lista de todos los objetos de un bucket de Amazon
S3
• Exponer PUT en un recurso de carpeta para añadir un bucket a Amazon S3
• Exponer DELETE en un recurso de carpeta para eliminar un bucket de Amazon S3
• Exponer GET en un recurso de carpeta o elemento para ver o descargar un objeto del bucket de
Amazon S3
• Exponer PUT en un recurso de carpeta o elemento para cargar un objeto en un bucket de Amazon S3
• Exponer HEAD en un recurso de carpeta o elemento para obtener los metadatos de objeto en un bucket
de Amazon S3
• Exponer DELETE en un recurso de carpeta o elemento para eliminar un objeto de un bucket de Amazon
S3
Note
Para integrar su API de API Gateway con Amazon S3, debe elegir una región en la que los
servicios API Gateway y Amazon S3 estén disponibles. Para conocer la disponibilidad de las
regiones, consulte Regiones y puntos de enlace.
Es posible que desee importar la API de ejemplo como un proxy de Amazon S3, tal y como se muestra
en Definiciones de Swagger de la API de ejemplo como un proxy de Amazon S3 (p. 430). Para obtener
instrucciones sobre cómo importar una API mediante la definición de Swagger, consulte Importar una
API (p. 217).
Para utilizar la consola de API Gateway para crear la API, primero debe inscribirse para obtener una
cuenta de AWS.

Temas
• Configurar permisos de IAM para que la API invoque acciones de Amazon S3 (p. 414)
• Crear recursos de API para representar recursos de Amazon S3 (p. 415)
• Exponer un método de API para mostrar los buckets de Amazon S3 del intermediario (p. 416)
• Exponer métodos de API para tener acceso a un bucket de Amazon S3 (p. 422)
413
Configurar permisos de IAM para que
la API invoque acciones de Amazon S3
• Exponer métodos de API para tener acceso a un objeto de Amazon S3 en un bucket (p. 425)
• Llamar a la API mediante un cliente API REST (p. 428)
• Definiciones de Swagger de la API de ejemplo como un proxy de Amazon S3 (p. 430)
Configurar permisos de IAM para que la API invoque

acciones de Amazon S3
Para permitir que la API invoque las acciones de Amazon S3 necesarias, debe tener las políticas de IAM
adecuadas asociadas a un rol de IAM. En la siguiente sección se describe cómo verificar y crear, si es
necesario, el rol y las políticas de IAM necesarios.
Para que la API vea o muestre buckets y objetos de Amazon S3, puede utilizar la política
AmazonS3ReadOnlyAccess proporcionada por IAM en el rol de IAM. El ARN de esta política es
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess, tal y como se muestra a continuación:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
Este documento de política establece que cualquiera de las acciones Get* y List* de Amazon S3 se
puede invocar en cualquiera de los recursos de Amazon S3.
Para que la API actualice los buckets y los objetos de Amazon S3, puede utilizar una política personalizada
para cualquiera de las acciones Put* de Amazon S3, tal y como se muestra a continuación:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:Put*",
"Resource": "*"
}
]
}
Para que la API funcione con las acciones Get*, List* y Put* de Amazon S3, puede añadir las políticas de
solo lectura y solo inserción anteriores al rol de IAM.
Para que la API invoque las acciones Post* de Amazon S3, debe utilizar una política Allow para las
acciones s3:Post* en el rol de IAM. Para obtener una lista completa de las acciones de Amazon S3,
consulte Specifying Amazon S3 Permissions in a Policy.
Para que la API cree, vea, actualice y elimine buckets y objetos en Amazon S3, puede utilizar la política
AmazonS3FullAccess proporcionada por IAM en el rol de IAM. El ARN es arn:aws:iam::aws:policy/
AmazonS3FullAccess.
414
Crear recursos de API para
representar recursos de Amazon S3
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
Después de haber elegido las políticas de IAM que desea utilizar, cree un rol de IAM y asócielo a las
políticas. El rol de IAM resultante debe contener la siguiente política de confianza para que API Gateway
asuma este rol en tiempo de ejecución.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
Cuando utilice la consola de IAM para crear el rol, elija el tipo de rol de Amazon API Gateway para
garantizar que esta política de confianza se incluya automáticamente.
Crear recursos de API para representar recursos de

Amazon S3
Utilizaremos el recurso raíz de la API (/) como el contenedor de buckets de Amazon S3 de un
intermediario autenticado. También crearemos los recursos Folder e Item para representar un bucket
de Amazon S3 determinado y un objeto de Amazon S3 determinado, respectivamente. El intermediario
especificará el nombre de carpeta y la clave de objeto en forma de parámetros de ruta como parte de la
URL de una solicitud.
Para crear un recurso de API que exponga las características del servicio Amazon S3
1. En la consola de API Gateway, cree una API denominada MyS3. Este recurso raíz de la API (/)
representa el servicio Amazon S3.
2. En el recurso raíz de la API, cree un recurso secundario denominado Folder y establezca el elemento
Resource Path necesario en /{folder}.
3. Para el recurso Folder de la API, cree un recurso secundario Item. Establezca el elemento Resource
Path necesario en /{item}.
415
Exponer un método de API para mostrar los
buckets de Amazon S3 del intermediario
Exponer un método de API para mostrar los buckets

de Amazon S3 del intermediario
Obtener la lista de buckets de Amazon S3 del intermediario implica invocar la acción GET Service en
Amazon S3. En el recurso raíz de la API, (/), cree el método GET. Configure el método GET para realizar
la integración con Amazon S3, tal y como se indica a continuación.
Para crear e inicializar el método GET / de la API
1. Elija Create method en el nodo raíz (/) desde el menú desplegable Actions en la esquina superior
derecha del panel Resources.
2. Elija GET en la lista desplegable de verbos HTTP y elija el icono de marca de verificación para empezar
a crear el método.
3. En el panel / - GET - Setup, elija AWS Service en Integration type.

4. Elija una región de la lista (por ejemplo, us-west-2) en AWS Region.
5. En AWS Service, elija S3.
6. Deje en blanco AWS Subdomain.
7. En HTTP method, elija GET.
416
8. En Action Type, elija Use path override. Con la anulación de la ruta, API Gateway reenvía la
solicitud del cliente a Amazon S3 como la solicitud del tipo de ruta de la API REST de Amazon S3
correspondiente, en la cual un recurso de Amazon S3 se expresa por la ruta de recursos del patrón
s3-host-name/bucket/key. API Gateway establece s3-host-name y transmite los elementos bucket y
key especificados por el cliente desde el mismo a Amazon S3.
9. (Opcional) En Path override escriba /.
10. Copie el ARN del rol de IAM creado anteriormente (desde la consola de IAM) y péguelo en Execution
role.
11. Deje el resto de la configuración de forma predeterminada.
12. Elija Save para terminar de configurar este método.
Esta configuración integra la solicitud GET https://your-api-host/stage/ del frontend con la solicitud
GET https://your-s3-host/ del backend.
Note
Tras la configuración inicial, puede modificar estos ajustes en la página Integration Request del
método.
Para controlar quién puede llamar a este método de nuestra API, activamos la marca de autorización del
método y la establecemos en AWS_IAM.
Para permitir que IAM controle el acceso al método GET /
1. En Method Execution, elija Method Request.

2. Elija el icono del lápiz que aparece junto a Authorization
3. Elija AWS_IAM en la lista desplegable.
4. Elija el icono de marca de verificación para guardar la configuración.
Para que nuestra API devuelva respuestas correctas y excepciones al intermediario, vamos a declarar las
respuestas 200, 400 y 500 en Method Response. Utilizamos el mapeo predeterminado para las respuestas
200, de forma que las respuestas del backend del código de estado no declarado aquí se devuelvan al
intermediario como respuestas 200.
417
Para declarar tipos de respuestas para el método GET /
1. En el panel Method Execution, elija el cuadro Method Response. API Gateway declara las respuestas
200 de forma predeterminada.
2. Elija Add response, escriba 400 en el cuadro de texto de entrada y elija la marca de verificación para
completar la declaración.
3. Repita el paso anterior para declarar el tipo de respuesta 500. Esta será la configuración final:
Como la respuesta de integración correcta de Amazon S3 devuelve la lista de buckets como una carga
XML y la respuesta de método predeterminada de API Gateway devuelve una carga JSON, debemos
mapear el valor del parámetro del encabezado Content-Type del backend a su homólogo en el frontend.
De lo contrario, el cliente recibirá application/json para el tipo de contenido cuando el cuerpo de la
respuesta sea en realidad una cadena XML. El siguiente procedimiento muestra cómo realizar esta
configuración. Además, también queremos mostrar al cliente otros parámetros de encabezado, como Date
y Content-Length.
Para configurar asignaciones de encabezado de respuesta para el método GET /
1. En la consola de API Gateway, elija Method Response. Añada el encabezado Content-Type para el
tipo de respuesta 200.
418
2. En Integration Response, para Content-Type, escriba integration.response.header.Content-Type

para la respuesta del método.
419
Con los mapeos de encabezado anteriores, API Gateway traducirá el encabezado Date del backend
en el encabezado Timestamp para el cliente.
3. En Integration Response, elija Add integration response, escriba una expresión regular adecuada
en el cuadro de texto HTTP status regex para otro estado de respuesta de método. Repita este
procedimiento hasta que se cubran todos los estados de respuesta de método.
420
Como práctica recomendada, vamos a probar nuestra API tal y como está configurada de momento.
Probar el método GET en el recurso raíz de la API
1. Vuelva a Method Execution, elija Test en el cuadro Client.

2. Elija Test en el panel GET / - Method Test. A continuación se muestra un resultado de ejemplo.
421
Exponer métodos de API para tener
acceso a un bucket de Amazon S3
Note
Para utilizar la consola de API Gateway para probar la API como un proxy de Amazon S3,
asegúrese de que el bucket de S3 de destino procede de una región diferente de la región de
la API. De lo contrario, es posible que obtenga una respuesta 500 Internal Server Error. Esta
limitación no se aplica a las API implementadas.
Exponer métodos de API para tener acceso a un

bucket de Amazon S3
Para trabajar con un bucket de Amazon S3, exponemos los métodos GET, PUT y DELETE en el recurso /
{folder} para mostrar los objetos de un bucket, crear un nuevo bucket y eliminar un bucket existente. Las
instrucciones son similares a las que se indican en Exponer un método de API para mostrar los buckets de
Amazon S3 del intermediario (p. 416). En las siguientes explicaciones, describimos las tareas generales
y resaltamos las diferencias pertinentes.
Para exponer métodos GET, PUT y DELETE en un recurso de carpeta
1. En el nodo /{folder} del árbol Resources, cree los métodos DELETE, GET y PUT, uno cada vez.
422
2. Configure la integración inicial de cada método creado con sus puntos de enlace de Amazon S3
correspondientes. En la siguiente captura de pantalla se ilustra esta configuración para el método
PUT /{folder}. Para los métodos DELETE /{folder} y GET /{folder}, reemplace el valor de PUT de
HTTP method por DELETE y GET, respectivamente.
Observe que hemos usado el parámetro de ruta {bucket} en las direcciones URL del punto de enlace
de Amazon S3 para especificar el bucket. Necesitaremos asignar el parámetro de ruta {folder} de las
solicitudes de método al parámetro de ruta {bucket} de las solicitudes de integración.
3. Para asignar {folder} a {bucket}:
a. Elija Method Execution y, a continuación, Integration Request.

b. Amplíe URL Path Parameters y elija Add path
c. Escribe bucket en la columna Name y method.request.path.folder en la columna Mapped
from. Elija el icono de marca de verificación para guardar la asignación.
4. En Method Request, añada Content-Type a la sección HTTP Request Headers.
423
Esto es necesario sobre todo para las pruebas, cuando se utiliza la consola de API Gateway y debe
especificar application/xml para una carga XML.
5. En Integration Request, configure los siguientes mapeos de encabezado, de acuerdo con las
instrucciones descritas en Exponer un método de API para mostrar los buckets de Amazon S3 del
intermediario (p. 416).
El encabezado x-amz-acl es para especificar el control de acceso en la carpeta (o el bucket de

Amazon S3 correspondiente). Para obtener más información, consulte Amazon S3 PUT Bucket
Request.
6. Para probar el método PUT, elija Test en el cuadro Client en Method Execution y escriba lo siguiente
como entrada para las pruebas:
a. En folder, escriba el nombre de un bucket.

b. Para el encabezado Content-Type, escriba application/xml.
c. En Request Body, proporcione la región del bucket como la restricción de ubicación, declarada en
un fragmento XML como la solicitud de carga. Por ejemplo,
<CreateBucketConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<LocationConstraint>{region}</LocationConstraint>
</CreateBucketConfiguration>
424
Exponer métodos de API para tener acceso
a un objeto de Amazon S3 en un bucket
7. Repita los pasos anteriores para crear y configurar el método GET Y DELETE en el recurso /{folder}
de la API.
Los ejemplos anteriores ilustran cómo crear un nuevo bucket en la región especificada para ver la lista
de objetos del bucket y para eliminar el bucket. Otras operaciones de bucket de Amazon S3 le permiten
trabajar con los metadatos o las propiedades del bucket. Por ejemplo, puede configurar la API para que
llame a la acción PUT /?notification de Amazon S3 para configurar notificaciones en el bucket, para que
llame a PUT /?acl para definir una lista de control de acceso en el bucket, etc. La configuración de la API
es similar, con la excepción de que debe añadir los parámetros de consulta adecuados a las direcciones
URL del punto de enlace de Amazon S3. En tiempo de ejecución, debemos proporcionar la carga XML
correspondiente a la solicitud del método. Lo mismo ocurre con las otras operaciones GET y DELETE en
un bucket de Amazon S3. Para obtener información sobre las posibles acciones de &S3; en un bucket,
consulte Amazon S3 Operations on Buckets.
Exponer métodos de API para tener acceso a un

objeto de Amazon S3 en un bucket
Amazon S3 admite las acciones GET, DELETE, HEAD, OPTIONS, POST y PUT para tener acceso a
objetos de un bucket determinado y administrarlos. Para ver la lista completa de acciones admitidas,
consulte Amazon S3 Operations on Objects.
En este tutorial, exponemos la operación PUT Object, la operación GET Object, la operación HEAD
Object y la operación DELETE Object a través de los métodos de API de PUT /{folder}/{item}, GET /
{folder}/{item}, HEAD /{folder}/{item} y DELETE /{folder}/{item}, respectivamente.
Las configuraciones de API para los métodos PUT, GET y DELETE en /{folder}/{item} son similares
a las de /{folder}, como se indica en Exponer métodos de API para tener acceso a un bucket de
Amazon S3 (p. 422). Una gran diferencia es que la ruta de la solicitud relacionada con un objeto tiene un
parámetro de ruta adicional de {item} y este parámetro de ruta debe estar asignado al parámetro de ruta
de solicitud de integración de {object}.
425
Lo mismo sucede con los métodos GET y DELETE.
A modo de ilustración, la siguiente captura de pantalla muestra el resultado cuando se prueba el método
GET en un recurso de {folder}/{item} mediante la consola de API Gateway. La solicitud devuelve
correctamente el texto sin formato ("Welcome to README.txt") como el contenido del archivo especificado
(README.txt) en el bucket de Amazon S3 indicado (apig-demo).
426
Para descargar o cargar archivos binarios, que en API Gateway se considera cualquier cosa que no sea
contenido JSON codificado en UTF-8, es necesaria una configuración adicional de la API. Esto se detalla
de la siguiente manera:
Descargar o cargar archivos binarios de S3
1. Registrar los tipos de archivo del archivo afectado en los tipos "binaryMediaTypes" de la API. Puede
hacer lo siguiente en la consola:
a. Elija Binary Support para la API (en el panel de navegación principal de API Gateway),
b. Elija Edit.
c. Escriba el tipo de medios necesario (por ejemplo, image/png en Binary media types).
d. Elija Add binary media type para guardar la configuración.
2. Añada las cabeceras Content-Type (para cargar) y/o Accept (para descargar) a la solicitud del método
para exigir que el cliente especifique el tipo de medios binarios necesarios y asignarlos a la solicitud
de integración.
3. Establezca el elemento Content Handling a Passthrough en la solicitud de integración (para cargar)
y en una respuesta de integración (para descargar). Asegúrese de que no se define ninguna plantilla
de mapeo para el tipo de contenido afectado. Para obtener más información, consulte Integration
Passthrough Behaviors (p. 150) y Select VTL Mapping Templates (p. 149).
427
Llamar a la API mediante un cliente API REST
Asegúrese de que los archivos en Amazon S3 incluyen los tipos de contenido correctos en los metadatos.
Para contenido multimedia que se puede transmitir, es posible que los metadatos deban incluir Content-
Disposition:inline.
Para obtener más información sobre la compatibilidad con datos binarios en API Gateway, consulte
Conversiones de tipo de contenido en API Gateway (p. 95).

Para proporcionar un tutorial completo, ahora mostraremos cómo llamar a la API mediante Postman, que
admite la autorización de AWS IAM.
Para llamar a nuestra API de proxy de Amazon S3 utilizando Postman
1. Implemente o vuelva a implementar la API. Anote la URL base de la API que se muestra junto a
Invoke URL en la parte superior de Stage Editor.
2. Inicie Postman.
3. Elija Authorization y, a continuación, elija AWS Signature. Escriba el ID de clave de acceso y la
clave de acceso secreta del usuario de IAM en los campos de entrada AccessKey y SecretKey,
respectivamente. Especifique la región de AWS en la que va a implementar la API en el cuadro de
texto AWS Region. Escriba execute-api en el campo de entrada Service Name.
Puede crear un par de claves desde la pestaña Security Credentials de su cuenta de usuario de IAM
en la consola de administración de IAM.
4. Para añadir un bucket denominado apig-demo-5 a su cuenta de Amazon S3 en la región {region}:
Note
Asegúrese de que el nombre de bucket sea único de forma global.
a. Seleccione PUT en la lista desplegable de métodos y escriba la URL del método (https://api-
id.execute-api.aws-region.amazonaws.com/stage/folder-name)
b. Establezca el valor del encabezado Content-Type en application/xml. Es posible que necesite
eliminar todos los encabezados existentes antes de configurar el tipo de contenido.
c. Elija el elemento de menú Body y escriba el siguiente fragmento XML como cuerpo de la solicitud:
<CreateBucketConfiguration>
<LocationConstraint>{region}</LocationConstraint>
</CreateBucketConfiguration>
d. Elija Send para enviar la solicitud. Si todo va bien, debería recibir una respuesta 200 OK con una
carga vacía.
5. Para añadir un archivo de texto a un bucket, siga las instrucciones anteriores. Si especifica el nombre
de bucket apig-demo-5 para {folder} y el nombre de archivo Readme.txt para {item} en la dirección
URL y proporciona la cadena de texto Hello, World! como la carga de solicitud, la solicitud será
PUT /S3/apig-demo-5/Readme.txt HTTP/1.1

Host: 9gn28ca086.execute-api.{region}.amazonaws.com
Content-Type: application/xml
X-Amz-Date: 20161015T062647Z
Authorization: AWS4-HMAC-SHA256 Credential=access-key-id/20161015/{region}/execute-
api/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-date,
Signature=ccadb877bdb0d395ca38cc47e18a0d76bb5eaf17007d11e40bf6fb63d28c705b
Postman-Token: 6135d315-9cc4-8af8-1757-90871d00847e
Hello, World!
428
Si todo sale bien, debe recibir una respuesta 200 OK con una carga vacía.
6. Para obtener el contenido del archivo Readme.txt que acaba de añadir al bucket apig-demo-5, envíe
una solicitud GET como la siguiente:
GET /S3/apig-demo-5/Readme.txt HTTP/1.1

X-Amz-Date: 20161015T063759Z
Authorization: AWS4-HMAC-SHA256 Credential=access-key-id/20161015/{region}/
execute-api/aws4_request, SignedHeaders=content-type;host;x-amz-date,
Signature=ba09b72b585acf0e578e6ad02555c00e24b420b59025bc7bb8d3f7aed1471339
Postman-Token: d60fcb59-d335-52f7-0025-5bd96928098a
Si todo sale bien, debe recibir una respuesta 200 OK con la cadena de texto Hello, World! como la
carga.
7. Para mostrar los elementos del bucket apig-demo-5, envíe la siguiente solicitud:
GET /S3/apig-demo-5 HTTP/1.1

X-Amz-Date: 20161015T064324Z
Authorization: AWS4-HMAC-SHA256 Credential=access-key-id/20161015/{region}/
execute-api/aws4_request, SignedHeaders=content-type;host;x-amz-date,
Signature=4ac9bd4574a14e01568134fd16814534d9951649d3a22b3b0db9f1f5cd4dd0ac
Postman-Token: 9c43020a-966f-61e1-81af-4c49ad8d1392
Si todo sale bien, debe recibir una respuesta 200 OK con una carga XML que muestre un único
elemento en el bucket especificado, a menos que haya añadido más archivos al bucket antes de
enviar esta solicitud.
<?xml version="1.0" encoding="UTF-8"?>

<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Name>apig-demo-5</Name>
<Prefix></Prefix>
<Marker></Marker>
<MaxKeys>1000</MaxKeys>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>Readme.txt</Key>
<LastModified>2016-10-15T06:26:48.000Z</LastModified>
<ETag>"65a8e27d8879283831b664bd8b7f0ad4"</ETag>
<Size>13</Size>
<Owner>
<ID>06e4b09e9d...603addd12ee</ID>
<DisplayName>user-name</DisplayName>
</Owner>
<StorageClass>STANDARD</StorageClass>
</Contents>
</ListBucketResult>
Note
Para cargar o descargar una imagen, debe configurar el tratamiento de contenido como
CONVERT_TO_BINARY.
429
ejemplo como un proxy de Amazon S3
Definiciones de Swagger de la API de ejemplo como

un proxy de Amazon S3
Las siguientes definiciones de Swagger describen la API de ejemplo, utilizada en este tutorial, como un
proxy de Amazon S3.
{
"swagger": "2.0",
"info": {
"version": "2016-10-13T23:04:43Z",
"title": "MyS3"
},
"host": "9gn28ca086.execute-api.{region}.amazonaws.com",
"basePath": "/S3",
"schemes": [
"https"
],
"paths": {
"/": {
"get": {
"produces": [
"application/json"
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Timestamp": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
"credentials": "arn:aws:iam::<replaceable>123456789012</replaceable>:role/
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
430
"method.response.header.Content-Type":
"integration.response.header.Content-Type",
"method.response.header.Content-Length":
"integration.response.header.Content-Length",
"method.response.header.Timestamp": "integration.response.header.Date"
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
"uri": "arn:aws:apigateway:us-west-2:s3:path//",
"type": "aws"
}
}
},
"/{folder}": {
"get": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Date": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
431
"statusCode": "400"
},
"default": {
"method.response.header.Date": "integration.response.header.Date",
"integration.response.header.content-length"
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
"integration.request.path.bucket": "method.request.path.folder"
},
"uri": "arn:aws:apigateway:us-west-2:s3:path/{bucket}",
"type": "aws"
}
},
"put": {
"produces": [
"application/json"
],
"parameters": [
{
"in": "header",
"required": false,
"type": "string"
},
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
432
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
"integration.response.header.Content-Length"
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
"integration.request.header.x-amz-acl": "'authenticated-read'",
"integration.request.path.bucket": "method.request.path.folder",
"integration.request.header.Content-Type": "method.request.header.Content-Type"
},
"type": "aws"
}
},
"delete": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Date": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
433

}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
"method.response.header.Date": "integration.response.header.Date"
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
},
"httpMethod": "DELETE",
"type": "aws"
}
}
},
"/{folder}/{item}": {
"get": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "item",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"content-type": {
"type": "string"
},
434
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
"method.response.header.content-type":
"integration.response.header.content-type",
"integration.response.header.Content-Type"
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
"integration.request.path.object": "method.request.path.item",
},
"uri": "arn:aws:apigateway:us-west-2:s3:path/{bucket}/{object}",
"type": "aws"
}
},
"head": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "item",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
435
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
},
"httpMethod": "HEAD",
"type": "aws"
}
},
"put": {
"produces": [
"application/json"
],
"parameters": [
{
"in": "header",
"required": false,
"type": "string"
436
},
{
"name": "item",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
}
},
"5\\d{2}": {
"statusCode": "500"
}
},
"integration.request.header.x-amz-acl": "'authenticated-read'",
"integration.request.path.bucket": "method.request.path.folder",
"integration.request.header.Content-Type": "method.request.header.Content-Type"
437
},
"type": "aws"
}
},
"delete": {
"produces": [
"application/json"
],
"parameters": [
{
"name": "item",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "folder",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Length": {
"type": "string"
},
"Content-Type": {
"type": "string"
}
}
},
"400": {
},
"500": {
}
},
"security": [
{
"sigv4": []
}
],
apigAwsProxyRole",
"responses": {
"4\\d{2}": {
"statusCode": "400"
},
"default": {
"statusCode": "200"
},
"5\\d{2}": {
"statusCode": "500"
}
},
438
Crear una API como un proxy de Amazon Kinesis
},
"httpMethod": "DELETE",
"type": "aws"
}
}
}
},
"sigv4": {
"type": "apiKey",
"name": "Authorization",
"in": "header",
"x-amazon-apigateway-authtype": "awsSigv4"
}
},
"definitions": {
"Empty": {
"type": "object",
}
}
}
Crear una API de API Gateway como un proxy de

Amazon Kinesis
Esta sección describe cómo crear y configurar una API de API Gateway con una integración del tipo AWS
para acceder a Kinesis.
Note
Para integrar su API de API Gateway con Kinesis, debe elegir una región en la que los servicios
API Gateway y Kinesis estén disponibles. Para conocer la disponibilidad de las regiones, consulte
Regiones y puntos de enlace.
A modo de ejemplo, crearemos una API de ejemplo para permitir que un cliente haga lo siguiente:
1. Mostrar los flujos disponibles para el usuario en Kinesis

2. Crear, describir, o eliminar un flujo especificado
3. Leer registros de datos o escribir registros de datos en un flujo especificado
Para realizar las tareas anteriores, la API expone métodos en diferentes recursos para invocar lo siguiente,
respectivamente:
1. La acción ListStreams en Kinesis

2. La acción CreateStream, DescribeStream o DeleteStream
3. La acción GetRecords o PutRecords (incluida la acción PutRecord) en Kinesis
En concreto, crearemos la API de la siguiente manera:
439
Crear un rol y una política de IAM para
que la API tenga acceso a Kinesis
• Exponer un método GET HTTP en el recurso /streams de la API e integrar el método con la acción
ListStreams de Kinesis para mostrar los flujos en la cuenta del intermediario.
• Exponer un método POST HTTP en el recurso /streams/{stream-name} de la API e integrar el método
con la acción CreateStream de Kinesis para crear un flujo con nombre en la cuenta del intermediario.
• Exponer un método GET HTTP en el recurso /streams/{stream-name} de la API e integrar el
método con la acción DescribeStream de Kinesis para describir un flujo con nombre en la cuenta del
intermediario.
• Exponer un método DELETE HTTP en el recurso /streams/{stream-name} de la API e integrar el
método con la acción DeleteStream de Kinesis para eliminar un flujo en la cuenta del intermediario.
• Exponer un método PUT HTTP en el recurso /streams/{stream-name}/record de la API e integrar el
método con la acción PutRecord de Kinesis. Esto permite que el cliente añada un solo registro de datos
al flujo con nombre.
• Exponer un método PUT HTTP en el recurso /streams/{stream-name}/records de la API e integrar el
método con la acción PutRecords de Kinesis. Esto permite que el cliente añada una lista de registros de
datos al flujo con nombre.
• Exponer un método GET HTTP en el recurso /streams/{stream-name}/records de la API e integrar el
método con la acción GetRecords de Kinesis. Esto permite que el cliente muestre registros de datos en
el flujo con nombre, con un iterador de fragmento especificado. Un iterador de fragmento especifica la
posición del fragmento desde la que se empiezan a leer los registros de datos de forma secuencial.
• Exponer un método GET HTTP en el recurso /streams/{stream-name}/sharditerator de la API e
integrar el método con la acción GetShardIterator de Kinesis. Este método auxiliar debe proporcionarse
en la acción ListStreams de Kinesis.
Puede aplicar las instrucciones que se presentan aquí a otras acciones de Kinesis. Para ver la lista
completa de acciones de Kinesis, consulte Amazon Kinesis API Reference.
En lugar de utilizar la consola de API Gateway para crear la API de ejemplo, puede importar la API de
ejemplo en API Gateway, utilizando la característica Import API de API Gateway o la herramienta de
importación de Swagger de API Gateway. Para obtener información acerca de cómo utilizar Import API,
consulte Importar una API (p. 217). Para obtener más información sobre cómo utilizar la herramienta
de importación de Swagger de API Gateway, consulte Getting Started with the API Gateway Swagger
Importer.

Crear un rol y una política de IAM para que la API

tenga acceso a Kinesis
Para permitir que la API invoque las acciones de Kinesis necesarias, debe tener las políticas de IAM
adecuadas asociadas a un rol de IAM. En esta sección se explica cómo verificar y crear, si es necesario, el
rol y las políticas de IAM necesarios.
Para habilitar el acceso de solo lectura a Kinesis, puede utilizar la política AmazonKinesisReadOnlyAccess
que permite invocar las acciones Get*, List* y Describe* de Kinesis.
{
"Version": "2012-10-17",
440
Crear un rol y una política de IAM para
que la API tenga acceso a Kinesis
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:Get*",
"kinesis:List*",
"kinesis:Describe*"
],
"Resource": "*"
}
]
}
Esta política está disponible como una política administrada aprovisionada por IAM y su ARN es
arn:aws:iam::aws:policy/AmazonKinesisReadOnlyAccess.
Para permitir acciones de lectura y escritura en Kinesis, puede utilizar la política

AmazonKinesisFullAccess.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:*",
"Resource": "*"
}
]
}
Esta política también está disponible como una política administrada aprovisionada por IAM. Su ARN es
arn:aws:iam::aws:policy/AmazonKinesisFullAccess.
Después de decidir qué política IAM va a utilizar, asóciela a un rol de IAM nuevo o existente. Asegúrese de
que el servicio de control de API Gateway (apigateway.amazonaws.com) es una entidad de confianza del
rol y tiene permiso para asumir el rol de ejecución (sts:AssumeRole).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
Si crea el rol de ejecución en la consola de IAM y elige el tipo de rol Amazon API Gateway, esta política de
confianza se adjunta automáticamente.
Anote el ARN del rol de ejecución. Lo necesitará cuando cree un método de API y configure su solicitud de
integración.
441
Empezar a crear una API como un proxy de Kinesis
Empezar a crear una API como un proxy de Kinesis

Utilice los siguientes pasos para crear la API en la consola de API Gateway.
Para crear una API como un proxy de servicio de AWS para Kinesis
1. En la consola de API Gateway, elija Create API.

2. Elija New API.
3. En API name, escriba KinesisProxy. Deje los valores predeterminados en el resto de los campos.
4. Escriba una descripción Description si lo desea.
5. Seleccione Create API.
Una vez creada la API, la consola de API Gateway mostrará la página Resources, que contiene
únicamente el recurso raíz de la API (/).
Mostrar flujos en Kinesis

Kinesis es compatible con la acción ListStreams con la siguiente llamada al API REST:
POST /?Action=ListStreams HTTP/1.1

Host: kinesis.<region>.<domain>
Content-Length: <PayloadSizeBytes>
User-Agent: <UserAgentString>
Authorization: <AuthParams>
X-Amz-Date: <Date>
{
...
}
En la anterior solicitud de API REST, la acción se especifica en el parámetro de consulta Action. También
puede, en su lugar, especificar la acción en un encabezado X-Amz-Target:
POST / HTTP/1.1
Host: kinesis.<region>.<domain>
Content-Length: <PayloadSizeBytes>
User-Agent: <UserAgentString>
Authorization: <AuthParams>
X-Amz-Date: <Date>
X-Amz-Target: Kinesis_20131202.ListStreams
{
...
}
En este tutorial usamos el parámetro de consulta para especificar la acción.
Para exponer una acción de Kinesis en la API, añada un recurso /streams a raíz de la API. A continuación,
defina un método GET en el recurso e integre el método en la acción ListStreams de Kinesis.
El siguiente procedimiento describe cómo mostrar flujos de Kinesis utilizando la consola de API Gateway.
Para mostrar flujos de Kinesis mediante la consola de API Gateway
1. Seleccione el recurso raíz de la API. En Actions, elija Create Resource.
442
En Resource Name, escriba Streams, no modifique los valores predeterminados del campo Resource
Path o del resto y, a continuación, elija Create Resource.
2. Elija el recurso /Streams. En Actions, elija Create Method, elija GET en la lista y, a continuación, elija
el icono de marca de verificación para terminar de crear el método.
Note
El verbo HTTP de un método invocado por un cliente puede ser diferente del verbo HTTP
de una integración requerida por el backend. Aquí elegimos GET porque mostrar los flujos es
intuitivamente una operación READ.
3. En el panel Setup del método, elija AWS Service.
a. En AWS Region, elija una región (por ejemplo, us-east-1).

b. En AWS Service, elija Kinesis.
c. Deje AWS Subdomain en blanco.
d. En HTTP method, elija POST.
Note
Aquí elegimos POST porque Kinesis requiere que la acción ListStreams también se
invoque.
e. En Action Type, elija Use action name.
f. En Action, escriba ListStreams.
g. En Execution role, escriba el ARN del rol de ejecución.
h. No modifique el valor predeterminado Passthrough del campo Content Handling.
i. Elija Save para finalizar la configuración inicial del método.
443
4. En el panel Integration Request, expanda la sección HTTP Headers:
a. Elija Add header.

b. En la columna Name, escriba Content-Type.
c. En la columna Mapped from, escriba 'application/x-amz-json-1.1'.
d. Elija el icono de marca de verificación para guardar la configuración.
Hemos utilizado un mapeo de parámetro de solicitud para definir el encabezado Content-Type en

el valor estático 'application/x-amz-json-1.1' para informar a Kinesis de que la entrada es una
versión específica de JSON.
5. Amplíe la sección Body Mapping Templates:
a. Elija Add mapping template.

b. En Content-Type, escriba application/json.
c. Elija el icono de marca de verificación para guardar la configuración Content-Type. Elija Yes,
secure this integration en Change passthrough behavior.
444
d. Escriba {} en el editor de la plantilla.

e. Elija el botón Save para guardar la plantilla de mapeo.
La solicitud ListStreams toma una carga con el siguiente formato JSON:
{
"ExclusiveStartStreamName": "string",
"Limit": number
}
Sin embargo, las propiedades son opcionales. Para utilizar los valores predeterminados, usamos aquí
una carga JSON vacía.
445
6. Pruebe el método GET en el recurso Streams para invocar la acción ListStreams en Kinesis:
En la consola de API Gateway, seleccione la entrada /streams/GET en el panel Resources, elija la

opción de invocación Test y, a continuación, elija Test.
446
Crear, describir y eliminar un flujo en Kinesis
Si ya ha creado dos flujos denominados "myStream" y "yourStream" en Kinesis, la prueba, si se

realiza correctamente, devolverá una respuesta 200 OK con la siguiente carga:
{
"HasMoreStreams": false,
"StreamNames": [
"myStream",
"yourStream"
]
}

Crear, describir y eliminar un flujo en Kinesis implica realizar las siguientes solicitudes a la API REST de
Kinesis, respectivamente:
POST /?Action=CreateStream HTTP/1.1

Host: kinesis.region.domain
...
Content-Length: PayloadSizeBytes
{
"ShardCount": number,
"StreamName": "string"
}
POST /?Action=DescribeStream HTTP/1.1

...
{
"ExclusiveStartShardId": "string",
"Limit": number,
}
POST /?Action=DeleteStream HTTP/1.1

...
{
"StreamName":"string"
}
447
Podemos crear la API para que acepte la entrada necesaria como una carga JSON de una solicitud de
método y transmita la carga a la solicitud de integración. Sin embargo, para proporcionar más ejemplos
de mapeo de datos entre solicitudes de método e integración y respuestas de método e integración,
crearemos nuestra API de una forma ligeramente distinta.
Exponemos los métodos HTTP GET, POST y Delete HTTP en un recurso Stream al que se asignará un
nombre. Utilizamos la variable de ruta {stream-name} como marcador de posición del recurso de flujo e
integramos estos métodos de la API con las acciones DescribeStream, CreateStream y DeleteStream de
Kinesis, respectivamente. Requerimos que el cliente transmita otros datos de entrada como encabezados,
parámetros de consulta o la carga de una solicitud de método y ofrecemos plantillas de mapeo para
transformar los datos necesarios en la carga de la solicitud de integración necesaria.
Para configurar y probar el método GET en un recurso de flujo
1. Cree un recurso secundario con la variable de ruta {stream-name} bajo el recurso /streams creado
con anterioridad.
2. Agregue los verbos HTTP POST, GET y DELETE a este recurso.
Después de crear los métodos en el recurso, la estructura de la API debe ser similar a la siguiente:
448
3. Configure el método GET /streams/{stream-name} para que llame a la acción POST /?

Action=DescribeStream en Kinesis, tal y como se muestra a continuación.
4. Añada el mapeo de encabezado Content-Type a la solicitud de integración:
449
Content-Type: 'x-amz-json-1.1'
La tarea sigue el mismo procedimiento para configurar el mapeo del parámetro de solicitud que el
método GET /streams.
5. Añada la siguiente plantilla de mapeo de cuerpo para mapear los datos de la solicitud del método
GET /streams/{stream-name} a la solicitud de integración POST /?Action=DescribeStream:
{
"StreamName": "$input.params('stream-name')"
}
Esta plantilla de mapeo genera la carga de la solicitud de integración necesaria para la acción
DescribeStream de Kinesis a partir del valor del parámetro de ruta stream-name de la solicitud de
método.
6. Pruebe el método GET /stream/{stream-name} para invocar la acción DescribeStream en Kinesis:
En la consola de API Gateway, seleccione /streams/{stream-name}/GET en el panel Resources, elija

Test para comenzar la prueba, escriba el nombre de un flujo de Kinesis existente en el campo Path
para stream-name y elija Test. Si la prueba tiene éxito, se devuelve la respuesta 200 OK con una
carga similar a la siguiente:
{
"StreamDescription": {
"HasMoreShards": false,
"RetentionPeriodHours": 24,
"Shards": [
{
"HashKeyRange": {
"EndingHashKey": "68056473384187692692674921486353642290",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"49559266461454070523309915164834022007924120923395850242"
},
"ShardId": "shardId-000000000000"
},
...
{
"HashKeyRange": {
"EndingHashKey": "340282366920938463463374607431768211455",
"StartingHashKey": "272225893536750770770699685945414569164"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"49559266461543273504104037657400164881014714369419771970"
},
}
],
"StreamARN": "arn:aws:kinesis:us-east-1:12345678901:stream/myStream",
"StreamName": "myStream",
"StreamStatus": "ACTIVE"
}
}
Después de implementar la API, puede realizar una solicitud REST a este método de la API:
450
GET https://your-api-id.execute-api.region.amazonaws.com/stage/streams/myStream
HTTP/1.1
Host: your-api-id.execute-api.region.amazonaws.com
Authorization: ...
X-Amz-Date: 20160323T194451Z
Para configurar y probar el método POST en un recurso de flujo
1. Configure el método POST /streams/{stream-name} para llamar a la acción POST /?

Action=CreateStream en Kinesis. La tarea sigue el mismo procedimiento para configurar el
método GET /streams/{stream-name} siempre y cuando reemplace la acción DescribeStream por
CreateStream.
3. Añada la siguiente plantilla de mapeo de cuerpo para mapear los datos de la solicitud del método
POST /streams/{stream-name} a la solicitud de integración POST /?Action=CreateStream:
{
"ShardCount": #if($input.path('$.ShardCount') == '') 5 #else
$input.path('$.ShardCount')",
}
En la plantilla de mapeo anterior, definimos ShardCount en un valor fijo de 5 si el cliente no especifica

un valor en la carga de la solicitud de método.
4. Pruebe el método POST /streams/{stream-name} para crear un flujo con nombre en Kinesis:
En la consola de API Gateway, seleccione /streams/{stream-name}/POST en el panel Resources,

elija Test para comenzar la prueba, escriba el nombre de un flujo de Kinesis existente en Path para
stream-name y elija Test. Si la prueba tiene éxito, se devuelve una respuesta 200 OK sin datos.
Después de implementar la API, también puede realizar una solicitud de API REST al método POST
en un recurso Stream para invocar la acción CreateStream en Kinesis:
POST https://your-api-id.execute-api.region.amazonaws.com/stage/streams/yourStream
HTTP/1.1
Authorization: ...
X-Amz-Date: 20160323T194451Z
{
"ShardCount": 5
}
451
Obtener registros y añadir registros a un flujo de Kinesis
Configurar y probar el método DELETE en un recurso de flujo
1. Configure el método DELETE /streams/{stream-name} para integrar la acción POST /?

Action=DeleteStream en Kinesis. La tarea sigue el mismo procedimiento para configurar el
método GET /streams/{stream-name} siempre y cuando reemplace la acción DescribeStream por
DeleteStream.
3. Añada la siguiente plantilla de mapeo de cuerpo para mapear los datos de la solicitud de método
DELETE /streams/{stream-name} a la solicitud de integración de POST /?Action=DeleteStream
correspondiente:
{
}
Esta plantilla de mapeo genera la entrada necesaria de la DELETE /streams/{stream-name} acción

desde el nombre de ruta URL proporcionada por el cliente: stream-name.
4. Pruebe el método DELETE para eliminar un flujo con nombre en Kinesis:
En la consola de API Gateway, seleccione el nodo de método /streams/{stream-name}/DELETE en

el panel Resources, elija Test para comenzar la prueba, escriba el nombre de un flujo de Kinesis
existente en Path para stream-name y elija Test. Si la prueba tiene éxito, se devuelve una respuesta
200 OK sin datos.
Después de implementar la API, también puede realizar la siguiente solicitud API REST al método
DELETE en el recurso Stream para llamar a la acción DeleteStream en Kinesis:
DELETE https://your-api-id.execute-api.region.amazonaws.com/stage/streams/yourStream
HTTP/1.1
Authorization: ...
X-Amz-Date: 20160323T194451Z
{}
Obtener registros y añadir registros a un flujo de

Kinesis
Después de crear un flujo en Kinesis, puede agregar registros de datos al flujo y leer los datos del flujo.
Agregar registros de datos implica llamar a la acción PutRecords o PutRecord de Kinesis. La primera
acción añade varios registros, mientras que la última añade un solo registro al flujo.
POST /?Action=PutRecords HTTP/1.1

Authorization: AWS4-HMAC-SHA256 Credential=..., ...
452
...
{
"Records": [
{
"Data": blob,
"ExplicitHashKey": "string",
"PartitionKey": "string"
}
],
}
o bien
POST /?Action=PutRecord HTTP/1.1

...
{
"Data": blob,
"ExplicitHashKey": "string",
"PartitionKey": "string",
"SequenceNumberForOrdering": "string",
}
Aquí, StreamName identifica el flujo de destino para añadir registros. StreamName, Data y PartitionKey
son datos de entrada necesarios. En nuestro ejemplo, usamos los valores predeterminados para todos los
datos de entrada opcionales y no especificaremos de forma explícita los valores para ellos en la entrada de
la solicitud del método.
Leer datos en Kinesis equivale a llamar a la acción GetRecords:
POST /?Action=GetRecords HTTP/1.1

...
{
"ShardIterator": "string",
"Limit": number
}
Aquí, el flujo de origen del que se obtienen los registros se especifica en el valor de ShardIterator
necesario, tal y como se muestra en la siguiente acción de Kinesis para obtener un iterador de fragmento:
POST /?Action=GetShardIterator HTTP/1.1

453
...
{
"ShardId": "string",
"ShardIteratorType": "string",
"StartingSequenceNumber": "string",
}
Para las acciones GetRecords y PutRecords, exponemos los métodos GET y PUT, respectivamente, en un
recurso /records que se añade a un recurso de flujo con nombre (/{stream-name}). Del mismo modo,
exponemos la acción PutRecord como un método PUT en un recurso /record.
Como la acción GetRecords toma como entrada un valor de ShardIterator, que se obtiene llamando a
la acción auxiliar GetShardIterator, exponemos un método auxiliar GET en un recurso ShardIterator (/
sharditerator).
En la siguiente ilustración se muestra la estructura de API de los recursos después de crear los métodos:
Los siguientes cuatro procedimientos describen cómo configurar cada uno de los métodos, cómo asignar
datos desde las solicitudes de método a las solicitudes de integración y cómo probar los métodos.
Para configurar y probar el método PUT /streams/{stream-name}/record para invocar a PutRecord

en Kinesis:
1. Configure el método PUT, como se muestra a continuación:
454
2. Añada el siguiente mapeo de parámetro de solicitud para configurar el encabezado Content-Type de

una versión de JSON compatible con AWS en la solicitud de integración:
PUT /streams/{stream-name}/record a la solicitud de integración de POST /?Action=PutRecord
correspondiente:
{
"StreamName": "$input.params('stream-name')",
"Data": "$util.base64Encode($input.json('$.Data'))",
"PartitionKey": "$input.path('$.PartitionKey')"
}
En esta plantilla de asignación se asume que la carga del método de solicitud tiene el siguiente
formato:
{
"Data": "some data",
"PartitionKey": "some key"
455
Estos datos se pueden modelar mediante el siguiente esquema JSON:
{
"title": "PutRecord proxy single-record payload",
"type": "object",
"properties": {
"Data": { "type": "string" },
"PartitionKey": { "type": "string" }
}
}
Puede crear un modelo para incluir este esquema y utilizar el modelo para facilitar la generación de
la plantilla de asignación. Sin embargo, puede generar una plantilla de asignación sin usar ningún
modelo.
4. Para probar el método PUT /streams/{stream-name}/record, establezca la variable de ruta stream-
name en el nombre de un flujo existente, introduzca la carga del formato necesario y, a continuación,
envíe la solicitud de método. El resultado correcto es una respuesta 200 OK con una carga con el
formato siguiente:
{
"SequenceNumber": "49559409944537880850133345460169886593573102115167928386",
}
Para configurar y probar el método PUT /streams/{stream-name}/records para invocar a PutRecords

en Kinesis
1. Configure el método PUT /streams/{stream-name}/records tal y como se muestra a continuación:
456
2. Añada el siguiente mapeo de parámetro de solicitud para configurar el encabezado Content-Type de

una versión de JSON compatible con AWS en la solicitud de integración:
PUT /streams/{stream-name}/records a la solicitud de integración de POST /?Action=PutRecords
correspondiente:
{
"StreamName": "$input.params('stream-name')",
"Records": [
#foreach($elem in $input.path('$.records'))
{
"Data": "$util.base64Encode($elem.data)",
"PartitionKey": "$elem.partition-key"
#end
]
}
457
Esta plantilla de mapeo asume que el siguiente esquema JSON puede modelar la carga de la solicitud
de método:
{
"title": "PutRecords proxy payload data",
"type": "object",
"properties": {
"records": {
"type": "array",
"items": {
"type": "object",
"properties": {
"data": { "type": "string" },
"partition-key": { "type": "string" }
}
}
}
}
}
Puede crear un modelo para incluir este esquema y utilizar el modelo para facilitar la generación de
la plantilla de asignación. Sin embargo, puede generar una plantilla de asignación sin usar ningún
modelo.
En este tutorial, hemos usado dos formatos de carga ligeramente diferentes para ilustrar que un
desarrollador de API puede optar por exponer el formato de datos de backend al cliente u ocultárselo.
Un formato es para el método PUT /streams/{stream-name}/records (anterior). Otro formato se
utiliza en el método PUT /streams/{stream-name}/record (en el procedimiento anterior). En un
entorno de producción, debe mantener la coherencia de ambos formatos.
4. Para probar el método PUT /streams/{stream-name}/records, establezca la variable de ruta stream-
name en un flujo existente, introduzca la siguiente carga y envíe la solicitud del método.
{
"records": [
{
"data": "some data",
"partition-key": "some key"
},
{
"data": "some other data",
"partition-key": "some key"
}
]
}
El resultado correcto es una respuesta 200 OK con una carga similar a la siguiente:
{
"FailedRecordCount": 0,
"Records": [
{
"SequenceNumber": "49559409944537880850133345460167468741933742152373764162",
},
{
"SequenceNumber": "49559409944537880850133345460168677667753356781548470338",
458
}
]
}
Para configurar y probar el método GET /streams/{stream-name}/sharditerator para invocar a

GetShardIterator en Kinesis
GET /streams/{stream-name}/sharditerator es un método auxiliar para adquirir un iterador de

fragmento necesario antes de llamar al método GET /streams/{stream-name}/records .
1. Configure la integración del método GET /streams/{stream-name}/sharditerator tal y como se

2. La acción GetShardIterator requiere una entrada de un valor de ShardId. Para pasar un valor de
ShardId proporcionado por el cliente, añadimos un parámetro de consulta shard-id a la solicitud del
método, tal y como se muestra a continuación:
459
En la siguiente plantilla de mapeo de cuerpo, definimos el valor del parámetro de consulta shard-id
en el valor de la propiedad ShardId de la carga JSON como entrada de la acción GetShardIterator
en Kinesis.
3. Configure la plantilla de mapeo de cuerpo para generar la entrada adecuada (ShardId y StreamName)
de la GetShardIterator acción a partir de los parámetros shard-id y stream-name de la solicitud de
método. Además, la plantilla de mapeo también establece ShardIteratorType en TRIM_HORIZON como
valor predeterminada.
{
"ShardId": "$input.params('shard-id')",
"ShardIteratorType": "TRIM_HORIZON",
}
4. Mediante la opción Test de la consola de API Gateway, escriba un nombre de flujo existente como el
valor de la variable stream-name Path, establezca la Query string shard-id en un valor de ShardId
existente (por ejemplo, shard-000000000004) y elija Test.
La carga de la respuesta correcta es similar al siguiente resultado:
460
{
"ShardIterator": "AAAAAAAAAAFYVN3VlFy..."
}
Anote el valor de ShardIterator. Lo necesita para obtener los registros de un flujo.
Para configurar y probar el método GET /streams/{stream-name}/records para invocar la acción

GetRecords en Kinesis
1. Configure el método GET /streams/{stream-name}/records tal y como se muestra a continuación:
2. La acción GetRecords requiere una entrada de un valor de ShardIterator. Para pasar un valor de
ShardIterator proporcionado por el cliente, añadimos un parámetro de encabezado Shard-Iterator
a la solicitud del método, tal y como se muestra a continuación:
461
3. Configure la siguiente plantilla de mapeo para mapear el valor del parámetro de encabezado Shard-
Iterator al valor de la propiedad ShardIterator de la carga JSON de la GetRecords acción en
Kinesis.
{
"ShardIterator": "$input.params('Shard-Iterator')"
}
4. Con la opción Test de la consola de API Gateway, escriba un nombre de flujo existente como el valor
de la variable stream-name Path, establezca el Header Shard-Iterator en el valor ShardIterator
obtenido de la serie de pruebas del método GET /streams/{stream-name}/sharditerator (arriba) y
elija Test.
La carga de la respuesta correcta es similar al siguiente resultado:
{
"MillisBehindLatest": 0,
"NextShardIterator": "AAAAAAAAAAF...",
"Records": [ ... ]
}
462
de ejemplo como un proxy de Kinesis
Definiciones de Swagger de una API de ejemplo como

un proxy de Kinesis
A continuación se muestran las definiciones de Swagger de la API de ejemplo como un proxy de Kinesis
utilizado en este tutorial.
{
"swagger": "2.0",
"info": {
"version": "2016-03-31T18:25:32Z",
"title": "KinesisProxy"
},
"host": "wd4zclrobb.execute-api.us-east-1.amazonaws.com",
"schemes": [
"https"
],
"paths": {
"/streams": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/ListStreams",
"integration.request.header.Content-Type": "'application/x-amz-json-1.1'"
},
"type": "aws"
}
}
},
"/streams/{stream-name}": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
463
"name": "stream-name",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"StreamName\": \"$input.params('stream-
name')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/DescribeStream",
"type": "aws"
}
},
"post": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"ShardCount\": 5,\n \"StreamName\":
\"$input.params('stream-name')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/CreateStream",
464
},
"type": "aws"
}
},
"delete": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
},
"headers": {
"Content-Type": {
"type": "string"
}
}
},
"400": {
"headers": {
"Content-Type": {
"type": "string"
}
}
},
"500": {
"headers": {
"Content-Type": {
"type": "string"
}
}
}
},
"responses": {
"4\\d{2}": {
}
},
"default": {
}
465
},
"5\\d{2}": {
}
}
},
"application/json": "{\n \"StreamName\": \"$input.params('stream-
name')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/DeleteStream",
},
"type": "aws"
}
}
},
"/streams/{stream-name}/record": {
"put": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"StreamName\": \"$input.params('stream-name')\",
\n \"Data\": \"$util.base64Encode($input.json('$.Data'))\",\n \"PartitionKey\":
\"$input.path('$.PartitionKey')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/PutRecord",
},
"type": "aws"
}
}
466
},
"/streams/{stream-name}/records": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "path",
"required": true,
"type": "string"
},
{
"name": "Shard-Iterator",
"in": "header",
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"ShardIterator\": \"$input.params('Shard-
Iterator')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/GetRecords",
},
"type": "aws"
}
},
"put": {
"consumes": [
"application/json",
"application/x-amz-json-1.1"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "header",
"required": false,
"type": "string"
},
{
467
"in": "path",
"required": true,
"type": "string"
},
{
"in": "body",
"name": "PutRecordsMethodRequestPayload",
"required": true,
"schema": {
"$ref": "#/definitions/PutRecordsMethodRequestPayload"
}
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"StreamName\": \"$input.params('stream-name')\",
\n \"Records\": [\n #foreach($elem in $input.path('$.records'))\n {\n
\"Data\": \"$util.base64Encode($elem.data)\",\n \"PartitionKey\":
\"$elem.partition-key\"\n }#if($foreach.hasNext),#end\n #end\n ]\n}",
"application/x-amz-json-1.1": "#set($inputRoot = $input.path('$'))\n{\n
\"StreamName\": \"$input.params('stream-name')\",\n \"records\" : [\n #foreach($elem
in $inputRoot.records)\n {\n \"Data\" : \"$elem.data\",\n \"PartitionKey
\" : \"$elem.partition-key\"\n }#if($foreach.hasNext),#end\n #end\n ]\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/PutRecords",
},
"type": "aws"
}
}
},
"/streams/{stream-name}/sharditerator": {
"get": {
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "path",
"required": true,
"type": "string"
},
{
"name": "shard-id",
"in": "query",
468
"required": false,
"type": "string"
}
],
"responses": {
"200": {
"schema": {
}
}
},
"responses": {
"default": {
"statusCode": "200"
}
},
"application/json": "{\n \"ShardId\": \"$input.params('shard-id')\",\n
\"ShardIteratorType\": \"TRIM_HORIZON\",\n \"StreamName\": \"$input.params('stream-
name')\"\n}"
},
"uri": "arn:aws:apigateway:us-east-1:kinesis:action/GetShardIterator",
},
"type": "aws"
}
}
}
},
"definitions": {
"PutRecordsMethodRequestPayload": {
"type": "object",
"properties": {
"records": {
"type": "array",
"items": {
"type": "object",
"properties": {
"data": {
"type": "string"
},
"partition-key": {
"type": "string"
}
}
}
}
}
},
"Empty": {
"type": "object"
}
}
}
469
API REST de Amazon API Gateway
Cuando utiliza la consola de Amazon API Gateway para crear, configurar, actualizar e implementar una
API, la consola llama a la API REST de API Gateway entre bastidores.
Cuando utiliza AWS Command Line Interface para crear, configurar, actualizar e implementar una API,
la herramienta AWS CLI llama también a la API REST de API Gateway. Para ver un ejemplo, consulte
Create an API using API Gateway and Test It en la AWS Lambda Developer Guide . Para obtener más
información, consulte la AWS Command Line Interface Guía del usuario.
Cuando utiliza un SDK de AWS para crear, configurar, actualizar e implementar una API, el SDK llama a la
API REST de API Gateway entre bastidores.
En lugar de esto, puede llamar a la API REST de API Gateway directamente para crear, configurar,
actualizar e implementar una API en API Gateway.
Para obtener más información acerca de cómo utilizar la API REST de API Gateway, consulte Referencia
de la REST API de Amazon API Gateway.
470
Límites de API Gateway
Límites, precios y problemas

conocidos de Amazon API Gateway
Temas
• Límites de API Gateway (p. 471)
• Precios de API Gateway (p. 473)
• Problemas conocidos (p. 474)
Límites de API Gateway

A menos que se indique lo contrario, los límites se pueden aumentar previa solicitud. Para solicitar un
aumento del límite, póngase en contacto con el centro de AWS Support.
Cuando la autorización está habilitada en un método, la longitud máxima del ARN del método (por ejemplo,
arn:aws:execute-api:{region-id}:{account-id}:{api-id}/{stage-id}/{method}/{resource}/
{path}) es de 1600 bytes. Los valores de parámetros de ruta, cuyo tamaño se determina en tiempo de
ejecución, pueden provocar que la longitud del ARN supere el límite. Cuando esto ocurra, el cliente de la
API recibirá una respuesta 414 Request URI too long.
Límites de API Gateway para configurar y ejecutar una

API
Los siguientes límites se aplican a la configuración y la ejecución de una API en Amazon API Gateway.
Recurso u operación Límite predeterminado Se puede

aumentar
Límites de solicitudes 10 000 solicitudes por segundo (sps) con una capacidad de ráfaga Sí
por cuenta y por adicional proporcionada por el algoritmo de bucket de tokens,
región utilizando una capacidad máxima de bucket de 5 000 solicitudes.
API (o RestApi) por 60 Sí

cuenta y región
471
Límites de API Gateway para crear,
implementar y administrar una API
Recurso u operación Límite predeterminado Se puede

aumentar
Claves de API por 500 Sí

cuenta y región
Certificados de 60 Sí
cliente por cuenta y
región
Autorizadores 10 Sí
personalizados por
API
Partes de 2000 Sí
documentación por
API
Recursos por API 300 Sí
Fases por API 10 Sí
Planes de uso por 300 Sí

cuenta y región
Planes de uso por 10 Sí

clave de API
TTL de 300 segundos de forma predeterminada y configurable entre 0 y No para

almacenamiento en 3 600 por el propietario de la API. el límite
caché de la API superior
(3 600)
Tiempo de espera de 30 segundos para todos los tipos de integración, incluidos las No
integración integraciones de Lambda, proxy Lambda, HTTP, proxy HTTP y AWS.
Tamaño de carga 10 MB No
Número de 1 000 No
iteraciones en un
bucle #foreach ...
#end en las plantillas
de asignación
Longitud del ARN 1600 bytes No

de un método con
autorización
En restapi:import or restapi:put, el tamaño máximo del archivo de definición de la API es de 2 MB.
Los límites que se indican por API únicamente pueden incrementarse para cada API determinada.
Límites de API Gateway para crear, implementar y

administrar una API
Los siguientes límites fijos se aplican a la creación, implementación y administración de una API en API
Gateway, utilizando la AWS CLI, la consola de API Gateway o la API REST de API Gateway y sus SDK.
Estos límites no se pueden aumentar.
472
Precios de API Gateway
Acción Límite predeterminado Se puede aumentar
CreateRestApi 2 solicitudes por minuto (spm) No

por cuenta
ImportRestApi 2 solicitudes por minuto por No

cuenta
PutRestApi 60 solicitudes por minuto por No

cuenta
DeleteRestApi 2 solicitudes por minuto por No

cuenta
CreateDeployment 3 solicitudes por minuto por No

cuenta
UpdateAccount 3 solicitudes por minuto por No

cuenta
GetResources 150 solicitudes por minuto por No

cuenta
CreateResource 300 solicitudes por minuto por No

cuenta
DeleteResource 300 solicitudes por minuto por No

cuenta
CreateDomainName 2 solicitudes por minuto por No

cuenta
UpdateUsagePlan 3 solicitudes por minuto por No

cuenta
Otras operaciones Sin límite hasta el límite total de No

la cuenta
Total de operaciones 10 solicitudes por segundo (rps) No

con un límite de ráfaga de 40
solicitudes.
Precios de API Gateway

Para obtener información general sobre los precios específicos de la región de API Gateway, consulte
Precios de Amazon API Gateway.
A continuación se enumeran las excepciones al esquema de precios generales:
• El almacenamiento en caché de API en Amazon API Gateway no está disponible en la Capa gratuita de
AWS.
• Las llamadas a métodos con el tipo de autorización de AWS_IAM, CUSTOM y COGNITO_USER_POOLS no se
cobran si se producen errores de autorización o autenticación.
• Las llamadas a métodos que requieran claves de API no se cobrarán si faltan las claves de API o no son
válidas.
• Las solicitudes limitadas por API Gateway no se cobrarán si la tasa de solicitudes o ráfagas supera los
límites preconfigurados.
473
Problemas conocidos
• Las solicitudes de uso limitadas por el plan no se cobrarán si los límites de tarifa o la cuota supera los
límites preconfigurados.
Problemas conocidos
• El carácter de barra vertical del texto sin formato (|) no es compatible con las cadenas de las consultas
URL y debe codificarse en formato URL.
• Las rutas de /ping y /sping están reservadas para la comprobación de estado del servicio. No se
producirá el resultado previsto si se usan estos recursos en el nivel de raíz de la API.
• API Gateway no admite actualmente la autenticación entre cuentas en el sentido de que, cuando
se utiliza IAM para autorizar una llamada a una API integrada con otro servicio de AWS, la API
implementada y el servicio de AWS integrado deben pertenecer a la misma cuenta de AWS. Un
intermediario de la API debe ser un usuario de IAM de la cuenta AWS del propietario de la API o un rol
de IAM en el cual confía el propietario de la API.
• Cuando se utiliza la consola de API Gateway para probar una API, es posible que aparezca la respuesta
"errores de punto de enlace desconocido" si un certificado autofirmado se presenta en el backend,
si falta el certificado intermedio en la cadena de certificados o si el backend genera cualquier otra
excepción relacionada con un certificado que no se reconoce.
• Los siguientes backends no son compatibles con la autenticación de clientes SSL con API Gateway:
• NGINX
• API Gateway admite la mayor parte de la especificación de Swagger, con las siguientes excepciones:
• Los modelos de API Gateway se definen utilizando esquemas JSON, en lugar de los esquemas JSON
que utiliza Swagger.
• El campo additionalProperties no se admite en los modelos.
• El campo allOf no se admite en los modelos.
• El campo readOnly no se admite en los modelos.
• El parámetro discriminator no se admite en ningún objeto de esquema.
• La etiqueta example no se admite.
• Las etiquetas maxItems y minItems no están incluidas en la validación de solicitud sencilla. Para
solucionarlo, actualice el modelo después de la importación antes de efectuar la validación.
• El campo readOnly no se admite.
• Las definiciones de respuesta con el formato "500": {"$ref": "#/responses/UnexpectedError"}
no se admiten en la raíz del documento de Swagger. Para solucionar este problema, sustituya la
referencia por el esquema insertado.
• Los números de tipo Int32 o Int64 no se admiten. A continuación se muestra un ejemplo:
"elementId": {
"description": "Working Element Id",
"format": "int32",
"type": "number"
}
• El tipo de formato de número decimal ("format": "decimal") no se admite en una definición de

esquema.
• En las respuestas a métodos, la definición del esquema debe ser un tipo de objeto y no puede tener
un tipo primitivo. Por ejemplo, "schema": { "type": "string"} no se admite. Sin embargo, puede
solucionar este problema con el siguiente tipo de objeto:
"schema": {
"$ref": "#/definitions/StringResponse"
}
474
Problemas conocidos
"definitions": {
"StringResponse": {
"type": "string"
}
}
• API Gateway establece las siguientes restricciones y limitaciones al manipular métodos con una
integración de proxy Lambda o una integración de proxy HTTP.
• No se admiten parámetros de cadena de consulta duplicados.
• No se admiten encabezados duplicados.
• El encabezado Host no se reenvía a puntos de enlace HTTP.
• Los siguientes encabezados se pueden reasignar a x-amzn-Remapped-HEADER durante el envío a o
desde el punto de enlace de integración:
• Accept
• Accept-Charset
• Accept-Encoding
• Age
• Authorization
• Connection
• Content-Encoding
• Content-Length
• Content-MD5
• Content-Type
• Date
• Expect
• Host
• Max-Forwards
• Pragma
• Proxy-Authenticate
• Range
• Referer
• Server
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via
• Warn
• WWW-Authenticate
• El SDK de Android de una API generado por API Gateway utiliza la clase java.net.HttpURLConnection.
Esta clase producirá una excepción no administrada en dispositivos con Android 4.4 y versiones
anteriores si la resignación del encabezado WWW-Authenticate a X-Amzn-Remapped-WWW-Authenticate
produce una respuesta 401.
• A diferencia de los SDK de Java, Android e iOS de una API generados por API Gateway, el SDK de
JavaScript de una API generado por API Gateway no admite reintentos de error de nivel 500.
• La invocación de prueba de un método utiliza el tipo de contenido predeterminado de application/json
y no tiene en cuenta las especificaciones de cualquier otro tipo de contenido.
475
Historial de revisión
En la siguiente tabla se describen los cambios importantes que se han realizado en la documentación
desde la última versión de la Guía para desarrolladores de API Gateway.
• Última actualización de la documentación 6 de junio de 2017
Cambio Descripción Fecha de

modificación
Autorizador Utilice el autorizador de solicitud personalizado para suministrar 15 de

de solicitud información de la autenticación del usuario en los parámetros septiembre de
personalizado de solicitud para autorizar llamadas al método de la API. Los 2017
parámetros de solicitud incluyen encabezados y parámetros
de cadenas de consulta, así como variables de etapa y
de contexto. Para obtener más información, consulte Usar
autorizadores personalizados (p. 239).
Personalización de Personalice las respuestas de gateway generadas por 6 de junio de

las respuestas de la API Gateway a las solicitudes API que no consiguieron 2017
gateway llegar al backend de integración. Un mensaje de gateway
personalizado puede proporcionar al intermediario mensajes
de error personalizados específicos de la API, incluidos los
encabezados de CORS necesarios, o puede transformar
los datos de respuesta de gateway en un formato de un
intercambio externo. Para obtener más información, consulte
Asignar datos de solicitud de método para personalizar
recursos de gateway (p. 151).
Asignar propiedades Asigne las propiedades de errores personalizados devueltas 6 de junio de

de errores por Lambda a los parámetros de encabezado de respuesta de 2017
personalizados método mediante el parámetro integration.response.body,
de Lambda a utilizando API Gateway para deserializar el objeto de error
encabezados de personalizado representado en forma de cadena en tiempo de
respuesta de método ejecución. Para obtener más información, consulte Tratamiento
de errores de Lambda personalizados en API Gateway (p. 92).
Aumento de los Aumente el límite de solicitudes de estado estable de nivel 6 de junio de

límites de solicitudes de cuenta a 10 000 solicitudes por segundo (sps) y el límite 2017
de ráfaga a 5 000 solicitudes simultáneas. Para obtener más
476

modificación
información, consulte Limitar las solicitudes de la API para
mejorar el desempeño (p. 300).
Validación de Configure validadores de solicitudes básicos en el nivel de 11 de abril de

solicitudes de método API o de método para que API Gateway pueda validar las 2017
solicitudes entrantes. API Gateway verifica que los parámetros
obligatorios están establecidos y no están vacíos, y verifica
que el formato de las cargas aplicables es compatible con el
modelo configurado. Para obtener más información, consulte
Habilitar la validación básica de solicitudes para una API en API
Gateway (p. 165).
Integración con ACM Utilice certificados de ACM para los nombres de dominio 9 de marzo de
personalizados de la API. Puede crear un certificado en AWS 2017
Certificate Manager o importar un certificado con formato PEM
existente en ACM. A continuación, puede hacer referencia
al ARN del certificado cuando configure nombre de dominio
personalizado para las API. Para obtener más información,
consulte Configurar nombres de dominio personalizados para el
nombre de host de la API (p. 332).
Generar y llamar a un Deje que API Gateway genere el SDK de Java para su API 13 de enero
SDK de Java de una y utilice el SDK para llamar a la API en su cliente Java. Para de 2017
API obtener más información, consulte Utilice un SDK de Java
generado por API Gateway (p. 350).
Integración con AWS Venda la API en un plan de uso a través de un producto SaaS 1 de
Marketplace mediante AWS Marketplace. Utilice AWS Marketplace para diciembre de
ampliar el alcance de la API. Use AWS Marketplace para 2016
facturar a los clientes en su nombre. Deje que API Gateway se
encargue de la autorización de usuarios y la medición del uso.
Para obtener más información, consulte Vender su API como
SaaS (p. 343).
Habilitar la ayuda de Añada documentación para las entidades de API en recursos 1 de

documentación para DocumentationPart en API Gateway. Asocie una snapshot diciembre de
su API de las instancias de DocumentationPart a una etapa de 2016
la API para crear un elemento DocumentationVersion.
Publique la documentación de la API exportando una versión
de documentación a un archivo externo, como un archivo
Swagger. Para obtener más información, consulte Documentar
una API (p. 177).
Autorizador Una función Lambda de autorizador de clientes devuelve ahora 1 de

personalizado el identificador principal del intermediario. La función también diciembre de
actualizado puede devolver otra información como pares de clave-valor 2016
del mapa context y una política de IAM. Para obtener más
información, consulte Salida de un autorizador personalizado
de Amazon API Gateway (p. 246).
477

modificación
Compatibilidad con Establezca binaryMediaTypes en la API para admitir 17 de

cargas binarias cargas binarias de una solicitud o respuesta. Establezca noviembre de
la propiedad contentHandling en un recurso Integration o 2016
IntegrationResponse para especificar si la carga binaria se
trata como el blob binario nativo, como una cadena codificada
en Base64 o como un paso a través sin modificaciones. Para
obtener más información, consulte Habilitar la compatibilidad
con cargas binarias en API Gateway (p. 94).
Habilitar una Cree un recurso de proxy con un parámetro de ruta expansiva 20 de

integración de proxy con el formato {proxy+} y el método catch-all ANY. El recurso septiembre de
con un backend HTTP de proxy se integra con un backend HTTP o Lambda mediante 2016
o Lambda a través de la integración de proxy HTTP o Lambda, respectivamente.
un recurso de proxy Para obtener más información, consulte Configuración de la
de una API. integración del proxy (p. 115).
Ampliar las API Cree un plan de uso en API Gateway para permitir a los 11 de agosto
seleccionadas en clientes API seleccionados tener acceso a las etapas de de 2016
API Gateway como API especificadas con las tarifas y cuotas acordadas. Para
ofertas de productos obtener más información, consulte Usar planes de uso de API
para sus clientes Gateway (p. 280).
proporcionando uno o
varios planes de uso
Habilitar la Cree un conjunto de usuarios en Amazon Cognito y úselo como 28 de julio de

autorización de nivel su propio proveedor de identidad. Puede configurar el conjunto 2016
de método con un de usuarios como un autorizador de nivel de método para
conjunto de usuarios conceder acceso a los usuarios que están registrados en el
en Amazon Cognito conjunto de usuarios. Para obtener más información, consulte
Usar conjuntos de usuarios de Amazon Cognito (p. 252).
Habilitar métricas Las métricas de API Gateway ahora están normalizadas en 28 de julio de
y dimensiones de el espacio de nombres de CloudWatch de AWS/ApiGateway. 2016
Amazon CloudWatch Puede verlas en la consola de API Gateway y en la consola de
en el espacio de Amazon CloudWatch. Para obtener más información, consulte
nombres de AWS/ Dimensiones y métricas de Amazon API Gateway (p. 368).
ApiGateway
Habilitar la rotación de La rotación de certificados le permite cargar y renovar un 27 de abril de

certificados para un certificado que va a vencer para un nombre de dominio 2016
nombre de dominio personalizado. Para obtener más información, consulte Rotar
personalizado un certificado importado en ACM (p. 341).
Documentar los Obtenga información sobre cómo crear y configurar una API 5 de abril de
cambios de la consola mediante la consola de API Gateway actualizada. Para obtener 2016
de Amazon API más información, consulte Crear una API de API Gateway a
Gateway actualizada partir de un ejemplo (p. 9) y Cree una API de API Gateway para
exponer un punto de enlace HTTP (p. 8).
478

modificación
Habilitar la Con las características de Import API, puede crear una nueva 5 de abril de
característica Import API o actualizar una existente cargando una definición de API 2016
API para crear una externa expresada en Swagger 2.0 con las extensiones de
API nueva o actualizar API Gateway. Para obtener más información sobre Import API,
una existente desde consulte Importar una API (p. 217).
definiciones de API
externas
Exponer la variable Para obtener más información sobre $input.body y 5 de abril de

$input.body $util.parseJson(), consulte Funciones y variables integradas 2016
para tener acceso en la plantilla de asignación (p. 158).
a la carga sin
formato como una
cadena y la función
$util.parseJson()
para convertir una
cadena JSON en un
objeto JSON en una
plantilla de asignación
Habilitar solicitudes Vacíe la caché de nivel de etapa de API e invalide entradas de 25 de marzo
cliente con caché individuales. Para obtener más información, consulte de 2016
invalidación de Vaciar la caché de etapas de API en API Gateway (p. 304)
caché de nivel de y Invalidar una entrada de caché de API Gateway (p. 304).
método y mejorar Mejore la experiencia de la consola para la administración
la administración de limitaciones de solicitudes de API. Para obtener más
de limitaciones de información, consulte Limitar las solicitudes de la API para
solicitudes mejorar el desempeño (p. 300).
Habilitar y llamar a la Cree y configure una función AWS Lambda para implementar la 11 de febrero
API de API Gateway autorización personalizada. La función devuelve un documento de 2016
con autorización de política de IAM que concede los permisos Allow o Deny
personalizada a las solicitudes cliente de una API de API Gateway. Para
obtener más información, consulte Usar autorizadores
personalizados (p. 239).
Importar y exportar Cree y actualice la API de API Gateway utilizando la 18 de

API de API Gateway especificación de Swagger con las extensiones de API diciembre de
mediante un archivo Gateway. Importe las definiciones de Swagger utilizando API 2015
de definición y Gateway Importer. Exporte una API de Gateway API en un
extensiones de archivo de definición de Swagger mediante la consola de API
Swagger Gateway o la característica Export API de API Gateway. Para
obtener más información, consulte Importar una API (p. 217) y
Exportar una API (p. 317).
Asignar campos Asigne el cuerpo de solicitud de método o sus campos JSON a 18 de

JSON de cuerpo o la ruta, cadena de consulta o encabezados de una solicitud de diciembre de
cuerpo de solicitud integración. Asigne el cuerpo de una respuesta de integración 2015
o respuesta a o sus campos JSON a encabezados de una respuesta de
parámetros de solicitud. Para obtener más información, consulte Asignación
solicitud o respuesta de datos de solicitud y respuesta (p. 147).
479

modificación
Trabajar con variables Obtenga información sobre cómo asociar atributos de 5 de

de etapa en Amazon configuración a una etapa de implementación de una API en noviembre de
API Gateway Amazon API Gateway. Para obtener más información, consulte 2015
Configurar variables de etapa para la implementación de la
API (p. 307).
Cómo: Habilitar CORS Ahora es más fácil habilitar el uso compartido de recursos entre 3 de
para un método orígenes (CORS) para métodos en Amazon API Gateway. Para noviembre de
obtener más información, consulte Habilitar CORS para un 2015
recurso (p. 235).
Cómo: Uso de la Utilice Amazon API Gateway para generar certificados SSL que 22 de
autenticación SSL del pueda utilizar para autenticar las llamadas a su backend HTTP. septiembre de
lado cliente Para obtener más información, consulte Usar certificados SSL 2015
del lado cliente (p. 256).
Integración ficticia de Obtenga información acerca de cómo integrar de manera 1 de

métodos ficticia una API con Amazon API Gateway (p. 112). Esta septiembre de
característica permite a los desarrolladores generar respuestas 2015
de API desde API Gateway directamente sin la necesidad de
definir previamente un backend de integración final.
Compatibilidad con Amazon API Gateway ha ampliado el alcance de la variable 28 de agosto

Amazon Cognito $context, de modo que ahora devuelve información sobre de 2015
Identity Amazon Cognito Identity cuando las solicitudes se firman con
credenciales de Amazon Cognito. Además, hemos añadido
una variable $util para incluir caracteres en secuencias de
escape en JavaScript y codificar direcciones URL y cadenas.
Para obtener más información, consulte Funciones y variables
integradas en la plantilla de asignación (p. 158).
Integración de Utilice la herramienta de importación de Swagger en GitHub 21 de julio de

Swagger para importar definiciones de API de Swagger en Amazon API 2015
Gateway. Obtenga más información acerca de Extensiones de
API Gateway para Swagger (p. 373) para crear e implementar
API y métodos utilizando la herramienta de importación. Con
la herramienta de importación de Swagger también puede
actualizar las API existentes.
Referencia de la Obtenga información sobre el parámetro $input y sus 18 de julio de

plantilla de asignación funciones en Funciones y variables integradas en la plantilla de 2015
asignación (p. 158).
Versión pública inicial Esta es la primera versión pública de la Guía para 9 de julio de
desarrolladores de API Gateway. 2015
480
AWS Glossary
For the latest AWS terminology, see the AWS Glossary in the AWS General Reference.
481

Amazon API Gateway - Guía para Desarrolladores

Cargado por

Copyright:

Formatos disponibles

Amazon API Gateway - Guía para Desarrolladores

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Amazon API Gateway - Guía para Desarrolladores

Cargado por

Copyright:

Formatos disponibles

Guía para desarrolladores

Amazon API Gateway: Guía para desarrolladores

Configuración de mapeo de datos entre método e integración .................................................. 87

Eliminar un recurso ......................................................................................................... 292

Rastrear las llamadas a la API con CloudWatch .......................................................................... 366

Llamar a la API mediante un cliente API REST ................................................................... 428

¿Qué es Amazon API Gateway?

Gateway hasta la nube de AWS y más allá

En el siguiente diagrama se muestra la arquitectura de API Gateway.

Parte de la infraestructura sin servidor de AWS

Experiencias del desarrollador

Creación y administración de una API de API Gateway

Llamada a una API de API Gateway

Ventajas de API Gateway

Conceptos de Amazon API Gateway

AWS es un servicio de API Gateway que admite lo siguiente:

Implementación y etapa de API

Introducción a Amazon API Gateway

Prepararse para usar Amazon API Gateway

Para inscribirse en AWS

1. Abra https://aws.amazon.com/ y elija Create an AWS Account.

Crear un usuario, grupo o rol de IAM en su cuenta de

Conceder permisos a usuarios de IAM para tener

Para el servicio de control de API Gateway, la política administrada de AmazonAPIGatewayAdministrator

Para el servicio de ejecución de API Gateway, la política administrada

Cree una API de API Gateway para exponer un

Crear una API de API Gateway a partir de un ejemplo

1. Aplique alguna de las siguientes acciones:

a. En el caso de la primera API de la cuenta, elija Get Started en la página de bienvenida de la

integración al backend y, de forma parecida, la respuesta del backend se transfiere a través de la

Pegue el valor de Invoke URL (obtenido en el paso anterior) en la barra de direcciones de un

Crear la API paso a paso

Otras opciones para un método de API son las siguientes:

• POST, que se utiliza principalmente para crear recursos secundarios.

Asignar parámetros de solicitudes para una API de

Se muestra la siguiente información con formato JSON sobre el elemento con el ID 1:

incluyendo el encabezado Content-type: application/json y el siguiente cuerpo de solicitud:

recibirá el siguiente objeto JSON en el cuerpo de la respuesta:

• Crear una API con un recurso de https://my-api-id.execute-api.region-id.amazonaws.com/test/

Paso 1: Crear recursos

Para crear el primer recurso

Para crear el segundo recurso

1. En el panel Resources, elija /petstorewalkthrough y, a continuación, elija Create Resource.

Para crear el tercer recurso

1. En el panel Resources, elija /petstorewalkthrough/pets y, a continuación, elija Create Resource.

Esto realiza la asignación con /petstore/pets/my-item-id en el punto de enlace HTTP.

Paso 2: Crear y probar los métodos

Para configurar y probar el primer método GET

Este procedimiento muestra lo siguiente:

1. En el panel Resources, elija /petstorewalkthrough/pets, elija Create Method en el menú Actions y, a

Esto especifica el parámetro de consulta petType en la solicitud del método de la API.

Esto especifica el parámetro de consulta petsPage en la solicitud del método de la API.

Para configurar y probar el segundo método GET

Este procedimiento muestra lo siguiente:

• Crear e integrar la solicitud del método GET /petstorewalkthrough/pets/{petId} con la solicitud de

1. En la lista Resources, elija /petstorewalkthrough/pets/{petId}, elija Create Method en el menú

Para configurar y probar el método POST

Este procedimiento muestra lo siguiente: