Understanding RESTful APIs

Introduction

The RESTful approach makes the development of modern web applications much more flexible and maintainable.

The new tendency is to build more complex clients with client-side frameworks such as AngularJS, ReactJS, PolymerJS, etc. This way, your web app can easily be distributed as a set of static assets - HTML, JavaScript and CSS files - which will load dynamic content via API.

This new architectural pattern allows you to separate business logic from your presentation layer(s). At the same time, your services will be easier to scale and reuse, eventually by more than one client, including your own mobile apps too.

In the AWS world, a typical configuration looks similar to the following:

• Static website hosted on Amazon S3 and distributed via Amazon CloudFront (learn more).
• RESTful API implemented with AWS Lambda and HTTP endpoints exposed via Amazon API Gateway.
• Dynamic data stored in DynamoDB, RDS or other database as a service alternative.

This is how you'd build a completely serverless web application, meaning that you won't need to manage, patch or maintain any server during your development and deployment workflow.

What is REST?

REST stands for Representational state transfer and is meant to be an architectural reference for developing modern and user-friendly web services.

Instead of defining custom methods and protocols such as SOAP or WSDL, REST is based on HTTP as the transport protocol. HTTP is used to exchange textual representations of web resources across different systems, using predefined methods such as GET, POST, PUT, PATCH, DELETE, etc.

The standard representation format is JSON, which is also the most convenient format to develop modern web applications since it's natively supported by JavaScript.

The level of abstraction provided by a RESTful API should guarantee a uniform interface and a set of stateless interactions: this means that all the information necessary to process a request must be included in the request itself (i.e. URL, headers, query string or body). Furthermore, each resource should be eventually cachable by the client, based on the particular use case.

What's next? 

With Amazon API Gateway, you can define resources, map them to custom models, specify which methods are available (i.e. GET, POST, etc.) and eventually bind each method to a particular Lambda function. Alternatively, you can attach more than one method to one single Lambda function. This way, you will maintain fewer functions and partially avoid the cold-start Lambda issue.

In the next steps, you will learn how to create new resources/endpoints and how to implement a serverless backend for your API.