Post Top Ad

Your Ad Spot

sábado, 1 de agosto de 2020

Anuncio de soporte para las API de AWS HTTP

¡El soporte de AWS HTTP API acaba de aterrizar!

Ejemplo de configuración de API HTTP serverless.yml
Al presentar el servicio HTTP API (todavía en versión beta) en diciembre pasado, AWS nos ofreció una alternativa más ligera, más barata , más rápida y en general mejor diseñada a las API REST. Más importante aún, la API HTTP es mucho más fácil de configurar y también se puede crear importando un archivo de definición de API abierta . ¿Qué no se podría amar?

¿En qué se diferencian las API HTTP de las API REST?

Las API HTTP realmente representan el ethos "menos es más": tienen menos opciones de configuración pero admiten el enrutamiento general (que no es posible con las API REST), la autorización JWT incorporada, las reglas globales para los encabezados CORS y las implementaciones automáticas que hacen que despliegue de API de producción muy simple.
En este punto, podemos dirigir los puntos finales para activar AWS Lambda o para otro punto final URL, pero no hay integración con otros servicios de AWS.
Dicho esto, las API de HTTP todavía están en beta y tienen varias limitaciones, como se resalta a continuación:
  • No hay soporte para planes de uso y claves API como con las API REST.
  • No hay subdominios comodín
  • Transformación de solicitud y respuesta inexistente
  • Sin almacenamiento en caché, validación, etc. (debe implementarse en lógica lambda)
  • No se pueden implementar API optimizadas para bordes o privadas. Todos los despliegues son regionales y públicos.
  • Si bien podemos habilitar registros de acceso simples y recibir métricas de CloudWatch, no hay compatibilidad con AWS X-Ray ni la capacidad de propagar registros a Kinesis Data Firehose
Para obtener un resumen completo de las diferencias, consulte la sección Elegir entre las API HTTP y las API REST en la documentación de AWS. Sin embargo, el servicio está mejorando rápidamente y a medida que avanza hacia GA, esperamos que se aborden muchos de estos.

¿Cómo configurar una API Rest respaldada por HTTP API con Serverless Framework?

Como HTTP API difiere de API Gateway en muchas partes, y solo la configuración muy básica de Rest API se puede traducir fácilmente de API Gateway a HTTP API, decidimos proponer un nuevo evento (httpApi) para el caso de HTTP API, que debería adjuntarse a funciona de la manera tradicional:
1functions:
2  someFunction:
3    handler: someFunction.handler
4      events:
5        - httpApi: ....

Configurar rutas

Configurar una ruta básica para un método específico es tan simple como:
httpApi: GET /get-something
La ruta de acceso de API Gateway también puede incluir parámetros:
httpApi: GET /get-something/{param}
También podemos configurar un método de ruta general para una ruta específica:
httpApi: * /get-something
O defina una ruta general y maneje todas las solicitudes desde el alcance de la función lambda única:
httpApi: *
Nota: Al configurar la ruta general, aún puede redirigir las solicitudes de rutas específicas a diferentes lambdas configurando las rutas dedicadas previstas
Si es necesario personalizar httpApiaún más el evento (con las opciones de configuración que se mencionan a continuación), la configuración del evento debe resumirse en forma de objeto de la siguiente manera:
1httpApi:
2  method: GET
3  route: /get-something

Configurar autorizadores JWT

Al configurar rutas simples, configuramos una API de acceso público. Si es necesario restringir el acceso a la API completa o algún punto final, debemos confiar en los autorizadores JWT, ya que actualmente es el único método de restricción de acceso actualmente compatible con la API HTTP. Afortunadamente, las agrupaciones de usuarios de AWS Cognito se adaptan perfectamente a este propósito.
Para agregar grupos de usuarios, debemos configurar los autorizadores en la sección provider.httpApi.authorizers, donde enumeramos los autorizadores JWT por nombre de la siguiente manera:
1provider:
2  httpApi:
3    authorizers:
4      someAuthorizer:
5        # Point request header at which JWT token will be provided
6        identitySource: $request.header.Authorization
7        # Issuer url, in case of Cognito User Pools url will be like: 
8        # https://cognito-idp.${region}.amazonaws.com/${cognitoPoolId}
9        issuerUrl: <url>
10        # Audience for which access is intended
11        # In case of Cognito User Pools we need to list client ids
12        audience:
13          - <audience1>
14          - <audience2>
Teniendo eso, necesitamos indicar puntos finales para los cuales queremos restringir el acceso con autorizadores configurados:
1functions:
2  someFunction:
3    handler: someFunction.handler
4    events:
5     - httpApi:
6          method: GET
7          path: /some-function
8          authorizer: someAuthorizer
Si necesitamos proporcionar ámbitos de autorización, la configuración del punto final debe ampliarse como:
1functions:
2  someFunction:
3    handler: someFunction.handler
4    events:
5      - httpApi:
6          method: GET
7          path: /some-function
8          authorizer:
9            name: someAuthorizer
10            scopes:
11              - user.id
12              - user.email

Configurando CORS

Si tiene la intención de consumir puntos finales API en un navegador, lo más probable es que necesite encabezados CORS. Los encabezados de CORS se pueden configurar de forma global para todos los puntos finales de API, y en Serverless Framework puede configurarlos de dos maneras.
El primero es establecer lo siguiente y confiar en los valores predeterminados de Framework:
1provider:
2  httpApi:
3    cors: true
Asegurará los siguientes encabezados:
  • Access-Control-Allow-Origin*
  • Access-Control-Allow-Headers:
    • Content-TypeX-Amz-DateAuthorizationX-Api-KeyX-Amz-Security-Token,X-Amz-User-Agent
  • Access-Control-Allow-Methods:
    • OPTIONSY todos los métodos definidos en sus rutas ( GETPOST, etc.)
Si necesita más personalización de grano fino, puede configurar cada encabezado individualmente con la siguiente configuración:
1provider:
2  httpApi:
3    cors:
4      allowedOrigins:
5        - https://url1.com
6        - https://url2.com
7      allowedHeaders:
8        - Content-Type
9        - Authorization
10      allowedMethods:
11        - GET
12      allowCredentials: true
13      exposedResponseHeaders:
14        - Special-Response-Header
15      maxAge: 6000 # In seconds
Nota: cualquier encabezado no configurado volverá al valor predeterminado de Framework

¿Que sigue?

Las API HTTP están sujetas a otras extensiones en el marco. En particular, se publicará próximamente la capacidad de configurar registros de acceso y la capacidad de compartir la misma API en diferentes servicios. También estamos planeando agregar una opción para hacer referencia a una especificación Open API en la serverless.ymlconfiguración de sus funciones.
Siga este problema de GitHub para obtener actualizaciones. Si aborda algún problema o desea proponer una mejora, no dude en compartirlo comentando este tema o abriendo un nuevo informe dedicado.
¡Que te diviertas! ¡Esperamos que la introducción de soporte para AWS HTTP API en Serverless Framework acelere su proceso de desarrollo sin servidor y no podemos esperar a ver qué construye con él!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas