Creating Serverless application using SAM Part2

There are two ways to create API gateway resource using SAM template. These two types are called explicit API definition and implicit API definition.

An explicit API gateway creation involves defining the resource explicitly with type
AWS::Serverless::API
In this type we give the API resource some name and thus we have an handle to the API.

An implicit API gateway involves defining the end points for API as part of the serverless function event definition. There is no separate API gateway resource defined. As part of SAM deployment, all the endpoints are collected and a new API gateway resource is automatically created by the SAM.

Implicit API Gateway
Using our previous example where we created lambda function, we add few more properties as shown in the below snippet which creates an API gateway resource











Explicit API Gateway example



As we see that we don't have control with implicit API gateway. Also it is not possible to create a custom stage name for implicit API. The default stage name is prod. This name cannot be deleted or renamed.

With explicit API gateway definition we have more control towards configuration of API. The default stage name created by SAM for this type is called stage. It cannot be deleted or renamed. However we can create our own stage with custom name in addition to the default value.



As discussed in part1 of this blog series, we can use global section configuration to define various gateway resource properties like cors headers, method settings and end point configuration.



API gateway needs more configuration unlike  lambda function. For example, we need to specify what is the input content type for API end point. The format that the API will produce and the parameters expected in the API. We might want to configure path parameters, caching, input transformation, response transformation, handling of error code and how the lambda is tied to the API.



To provide detailed configuration and documentation of the end points we use swagger file. SAM template provides both the option to include the swagger definition body as part of the template or externalize the content to some s3 bucket location and reference that as an URI














































Comments











Post a Comment























Popular posts from this blog









Integrate an API with lambda - Part 5




















Image







 In this part of the blog we will cover the section Integration Response  in detail.    This is where we configuration how the response needs to be mapped. On clicking the  details we get a similar screen     In here we could add multiple integration responses. This is a very important section for output error code mapping.  If we intend to capture some keyword coming from backend we can use regex expression to filter response and handle the conversion. For example, we could expression .*exception*. to filter responses which has exception occurring any where and map it to error code like 500. Below screenshots shows the steps involved in achieving this.               








Read more










Custom authorizer





















 Creating custom authorizer using SAM    AWSTemplateFormatVersion: '2010-09-09'  Transform: AWS::Serverless-2016-10-31  Resources:    Api:      Type: AWS::Serverless::Api      Properties:        StageName: devtesting        DefinitionBody:          swagger: "2.0"          info:            title:              Ref: AWS::StackName          description: My API that uses custom authorizer          version: 1.0.0          paths:            "/getmesomething":              get:                x-amazon-apigateway-integration:                  httpMethod: GET                  type: aws_proxy          ...








Read more










Integrate an API with lambda - Part 3




















Image







 Let us look at request validation features in API gateway  when user requests for an end point (resource) we could perform few validations before processing the request. For example, the end point might require one or more of the below fields    query parameters  path parameters   header  body    API gateway provides validation for these fields.       There are multiple options available here. Default is none. Validate body is used if the request has a payload and that needs to be schema validated before processing. We could also use the option that validates for required query string parameters and headers. Names for the parameter that are applicable can be provided in the section as shown below         If the parameters need to be part of the cache we need to enable caching so that parameter becomes part of the cache key. Also the request body section will need the name of the model and the content type of the body. We need to create models in the section below first and then re...








Read more