Rest Abstraction for Serverless API


Middleware for AWS Lambda and Api Gateway.

Provides support for:

- Fully customizable parameter types
- Support for header, json, query and context, parameter positions
- Abstraction for text, json, and binary response types
- Full support for custom authentication
- Full support for cors
- Full support for versioning and deprecation
- Automatic generation of Swagger documentation
- Rate limiting using in-memory or S3
- Access and error logging using lambda-monitor

Install

$ npm install --save lambda-serverless-api

Getting Started

Define api and handlers in handler.js as follows:

``js
import { Api } from 'lambda-serverless-api';

const api = Api({/ options /});

api.wrap('POST register', [
api.Str('name', 'json', { required: false }),
api.Email('email', 'json'),
api.Str('password', 'json')
], / options, / ({ name, email, password }) => {
// handle registration logic here ...
if (new Date().getHours() === 4) {
throw api.ApiError('I am a teapot', 418);
}
return api.JsonResponse({ message: 'Success!' });
});

export default api;
`

then hook the router endpoint into the Serverless Framework configuration as

`
functions:
router:
handler: handler.router
events:
- schedule: rate(10 minutes)
- http:
path: /{proxy+}
method: ANY
`

Api Options

The api is plugin based and all options are tied to plugins. The following plugins are customizable:

- _cors_: Used to handle CORS Option requests as well as injecting CORS headers into responses
- _versioning_: Used to declare valid api version and handle deprecation
- _logger_: Log responses to console (CloudWatch), which can then be picked up by lambda-monitor
- _preValidation_: Hook to allow pre-validation (e.g. authentication)
- _rateLimit_: Used for rate limiting
- _router_: Used to modify the router, e.g. set a custom route prefix
- _robots_: Used to modify robots.txt response
- _responseHeaders_: Used to inject certain predefined response headers, such as Date
- _preLogic_: Used to e.g. modify parameters after they are parsed

Please see implementation for details.

Endpoint Definition: wrap()

Takes the following positional arguments:
- _route_ string: The method and the uri of the format ${method} ${uri}
- _params_ Array: Parameter definitions
- _options_: Endpoint options (optional)
- _handler_ function: The handler using parsed parameters as the first argument

Note: The (slightly modified) original event and context can be accessed as additional handler parameters

$3

- _limit_: ...
- _deprecated_: ...
- _versioning_: ...
- _logSuccess_: ...
- _logError_: ...
- _allowUnknownJson_ (default false): Allow unknown json body parameters

Api Parameters

There are various pre-defined parameters available

- _Bool_: Boolean input
- _IsoDate_: Date input as YYYY-MM-DD
- _Email_: Email input
- _Enum_: Enum input
- _FieldsParam_: String input that gets parsed as object-fields
- _GeoPoint_: GPS coordinate input
- _GeoPoly_: GPS coordinate of polygon input and holes
- _GeoPolyList_: List of GPS coordinate of polygon input and holes
- _GeoRect_: GPS coordinate rectangle input
- _GeoShape_: GPS coordinate polygon input
- _GeoShapeList_: GPS coordinate polygon list input
- _Int_: Integer input
- _IntShort_: Short Integer input
- _IsoTimestamp_: Iso timestamp input
- _Json_: Json input that has to conform to Joi schema
- _Json-list_: List of Json input that has to conform to Joi schema
- _List_: List input
- _NumberList_: Number list input
- _NumberParam_: Number input
- _Regex_: String input that has to conform to a regex
- _Str_: String input
- _StrList_: String list input
- _UUID_: Uuid input

$3

There are four types of parameter types:
- json: parsed from the json request body
- query: parsed from the query string
- header: parsed from the header and case insensitive
- context: parsed from the lambda event context. Useful to e.g. obtain the client IP

$3

Below are the default parameter options. Most parameters have several customization options. Please see implementation for details.

#### required

Allow input to be not present

Type: boolean

Default: true

#### nullable

Allow input value to be null.

_Note: Parameter position must be in [json, context]_

Type: boolean

Default: false

#### getter

> _Experimental_

_Note: only recommended for advanced use cases._

Optionally asynchronous custom "getting" of variables.

Getter function takes raw input from event, IE a query parameter will always pass String values into the getter function.

Warnings:
* If used with { nullable: true }, if a rawInput is passed as null, or if a non-required parameter is not sent, the getter function will _not_ be used.
* Some params (such as Bool, Int, Json, etc) do extra processing _after_ the getter function has returned, and may return inconsistent results. Thorough testing is recommended.

Takes unresolved parameters as second parameter. Simple parameters can be accessed directly, unresolved can be resolved by using await.

Type: Function

Default: null

Example

`javascript
/ { "name": " John "} /
export default api.wrap('POST name', [
api.Str('name', 'json', true, { getter: (input, params) => input.trim() })
], ({ name }) => {
console.log(name); // "John"
});
`

$3

Parameter names are converted to camel case when passed into the handler.

E.g. the header X-Custom-Header would be passed as xCustomHeader.

Api Response

There are two types of api responses: Success and error responses. Error responses need to be thrown, while success responses
need to be returned from the endpoint handler. The following responses are available:

- _Success_: ApiResponse (e.g. for plain text), JsonResponse (for json), BinaryResponse (e.g. for images)
- _Failure_: ApiError

Success responses take the positional parameters data (required), statusCode (optional) and headers (optional).

Error responses take the positional parameters message (required), statusCode (optional), messageId (optional) and context (optional). They are always of Json format. It is recommended that an easily identifiable messageId is set on all error responses.

Please see implementation for details.

Rate Limiting

Done globally through the API configuration. However can be overwritten on a per-endpoint basis
by specifying limit as an integer in the endpoint definition option.

Rate limiting uses memory by default, which is not shared across function containers. However one can configure S3 to share the rate limiting (recommended). This will (1) increase latency and (2) increase costs per api call.

By default the client IP (['requestContext.identity.sourceIp']) is used for rate limiting. However this can be customized.

General Notes

Each endpoint definition can also be exposed as a separate lambda function. However this is not recommended for
larger APIs due to CloudFormation limitations (maximum number of resources and stack invalidation issues).

Consider using yaml-boost for loading Serverless Framework configuration.

Consider using a single router function instead of declaring each function individually.

Swagger Documentation

To generate swagger documentation we can call api.generateSwagger() after the api is initialized with routes. For merge-overwrite the swagger definition fs.smartWrite() can be used.

_Example_


`js
import path from 'path';
import fs from 'smart-fs';

const updateSwagger = async () => {
const swaggerFile = path.join(fs.dirname(import.meta.url), '..', 'swagger.yml');
const swaggerContent = await api.generateSwagger();
const result = fs.smartWrite(swaggerFile, swaggerContent);
expect(result, 'Swagger file updated').to.equal(false);
};
updateSwagger();
``

Logging Api Errors / Exceptions

To monitor api errors and exceptions, lambda-monitor should be configured with rollbar.