Become an AWS pro by learning to run serverless applications with AWS Lambda. Developed by AWS Solution Certified Architects. Get hands-on, no setup, no cleanup, no hassle.

aws_image.tar.gz

LANG

LC_ALL

aws_access_key_id

aws_secret_access_key

BUCKET_NAME

aws_region

dockerjob

dockerjob-copy

RunSamLogsTail

RunCfnLint

RunSamLocal

RunVersionCode

RunGradualDeployment

RunDeploymentAlert

RunChap6CustomisingResponses

RunChap6Processingrequestparameters

RunChap6GlobalSettings

RunChap6CreatingParameterisedCloudFormationStacks

RunChap7

RunChap8

RunChap9AvoidingCircularReferences

RunChap9ConditionalResources

RunChap10InvokingSystemUtilities

RunChap10PublishingToSAR

RunChap11UploadingFilestoS3

RunChap12LambdaUtilityFunctions

dockerjob-copy-ForceRelaunch

dockerjob-copy-copy-FR

RunSamLogsTail-copy

RunCfnLint-copy

RunSamLocal-copy

RunVersionCode-copy

RunGradualDeployment-copy

RunDeploymentAlert-copy

RunChap6CustomisingResponses-copy

RunChap6Processingrequestparameters-copy

RunChap6GlobalSettings-copy

RunChap6CreatingParameterisedCloudFormationStacks-copy

RunChap7-copy

RunChap8-copy

RunChap9AvoidingCircularReferences-copy

RunChap9ConditionalResources-copy

RunChap10InvokingSystemUtilities-copy

RunChap10PublishingToSAR-copy

RunChap11UploadingFilestoS3-copy

RunChap12LambdaUtilityFunctions-copy

RunSamLogsTail-copy1

RunVersionCode-copy1

RunGradualDeployment-copy1

RunDeploymentAlert-copy1

RunChap6CustomisingResponses-copy1

RunChap6Processingrequestparameters-copy1

RunChap6GlobalSettings-copy1

RunChap6CreatingParameterisedCloudFormationStacks-copy1

RunChap7-copy1

RunChap8-copy1

RunChap9AvoidingCircularReferences-copy1

RunChap9ConditionalResources-copy1

RunChap10InvokingSystemUtilities-copy1

RunChap10PublishingToSAR-copy1

RunChap11UploadingFilestoS3-copy1

RunChap12LambdaUtilityFunctions-copy1

In the world of modern development, serverless computing has become table stakes. Serverless computing has seen a major uptake with AWS Lambda having an increased adoption of 667% in 2018. Companies are making the switch to serverless for shorter time to market and decreased operational costs, but for you the advantage lies in the ability to offload the burden of managing infrastructure to serverless platforms, so you can focus on building even better apps.

In this course, you will learn how to run serverless applications using AWS Lambda. You’ll start with the basics such as creating a web service where you’ll learn the steps to deploy an AWS Serverless Application Model (SAM). You’ll then move on to more advanced topics such as handling HTTP Requests, using external storage, and managing sessions and user workflows. By the end of this course, you will be ready to work with AWS Lambda in a professional setting, and you’ll have a great, transferable skill that employers will love to see.

Running Serverless Applications with AWS Lambda

_This chapter explains how to structure SAM application templates and source code to make it easy to support, maintain, and evolve applications in the future. You will also learn about protecting serverless applications against abuse._



To avoid conflicts between user uploads, the `ShowFormFunction` function you created in [Chapter 10](https://www.educative.io/courses/running-serverless-applications-aws-lambda/using-mogrify) creates a random upload key and appends the `.jpg` image extension. In the previous chapter, you made user interactions much nicer, but you're still restricting users from converting JPG images. ImageMagick can handle many image formats easily, so you can make the application a lot more useful by letting users upload PNG and GIF images as well.

To support multiple formats, you just need to ensure that users upload images to S3 with the correct extensions, so ImageMagick can load the files appropriately. Restricting uploads to `.jpg` was necessary for Chapter 10 because you had no client-facing logic. `ShowFormFunction` needs to limit the uploads to something, and the client couldn't specify upfront what it wants. Now that the client code is smarter, it could ask for an upload policy for a specific image type.  

# API endpoints with path parameters

So far in this course, you have built API endpoints with parameters either in the query string or the request body. 

There is one more option: you could put parameters in the request paths. 

For example, requests to `/sign/jpg` could produce policies for a `jpg` file upload, and requests to `/sign/png` could do the same for `png` files. 

You could create individual endpoints for each file type, but this would complicate the application template unnecessarily. Extending the application to support more file types would require changing the template and the application code, and it would be error-prone. API Gateway has a much simpler solution for cases when a part of the request path needs to be flexible. Declare an API endpoint using a parameter name in curly braces and API Gateway will use it for all matching requests. For example, you can create a single endpoint using the path `/sign/{extension}`, and it will handle requests for `/sign/png`, `/sign/jpg`, `/sign/gif` and any other request starting with `/sign/` in the future. To read out the value of a parameter from the path in a Lambda function, you can use the `pathParameters` field of the API Gateway event. 

Any component of a path can contain a parameter, so endpoints such as `/sign/{extension}/image` are also OK. You can also add multiple generic components to the same endpoint, for example `/sign/{extension}/image/{size}`. The parameters are not completely arbitrary, though. API Gateway matches paths on non-parameterised parts and requires all endpoint paths to be unique; you can't create `/sign/{extension}` and `/sign/{type}` at the same time because API Gateway would not know how to choose between them. You'd have to add something extra to those paths to make them distinguishable. Also, only full path components can be parameters. API Gateway treats a forward slash (`/`) as a component separator. While `/sign/{extension}/image` and `/sign/{extension}/type` would be perfectly valid paths, 
 `/sign/image.{extension}` and `/sign/{extension}-type` would not.

> ### Greedy path parameters
> 
> In addition to individual path components, you can also use a _greedy parameter_, which matches one or more path components. Just include a plus sign at the end of the component name, for example `/sign/{proxy+}`. This will match `/sign/jpg` and `/sign/jpg/size/500`. This is a useful trick if you want to build your own request routing inside a Lambda function. 

API Gateway does not validate path parameters, so it's not possible to set constraints directly in the API definition. For example, `/sign/{extension}` will match requests to `/sign/png`, but also to `/sign/xls`. Although ImageMagick supports lots of image types, it's still not magic enough to generate thumbnails for Excel files. To prevent user errors, you will need to validate extensions using a list of supported types in the Lambda function connected to the API endpoint.

Let's add another parameter to your application template, so you can configure the supported file types easily. The block from the following listing is added to the `Parameters` section of your application template, indented to align with other parameters (for example `ThumbnailWidth`).



In this lesson, you'll start modifying the application to make it more robust and easier to maintain!

Modifying API Endpoints

Getting Started

Setup Tools for Local Development

Creating a Web Service

Host a Serverless Application on AWS Lambda

Development and Troubleshooting

Core Features of AWS Lambda

Handling HTTP Requests

Using External Storage

Cheaper, Faster, Serverless

Handling Platform Events

Using Application Components

Managing Sessions and User Workflows

Designing Robust Applications

Deployment Options

Process Amazon SNS Notifications with AWS Lambda

Modifying API Endpoints