Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

serverless-auto-swagger

Package Overview
Dependencies
Maintainers
1
Versions
30
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

serverless-auto-swagger

Automatically generate a swagger file from your Serverless Framework config file

  • 3.0.0
  • latest
  • Source
  • npm
  • Socket score

Version published
Maintainers
1
Created
Source

Serverless Auto Swagger

This plugin allows you to automatically generate a swagger endpoint, describing your application endpoints. This is built from your existing serverless config and typescript definitions, reducing the duplication of work.

Install

yarn add --dev serverless-auto-swagger
# or
npm install -D serverless-auto-swagger

Add the following plugin to your serverless.yml or serverless.ts:

plugins:
  - serverless-auto-swagger
plugins: ['serverless-auto-swagger'];

NOTE: This plugin should come before any transform plugins (i.e. serverless-webpack or serverless-plugin-typescript), and must come before serverless-offline if included.

Usage

This plugin is designed to work with vanilla Serverless Framework. All you need to do is add this plugin to your plugin list, and it will generate the swagger file and add the endpoints required. When you deploy your API, your new swagger UI will be available at https://{your-url-domain}/swagger.

You can also run sls generate-swagger if you want to generate the swagger file without deploying the application.

Config Options

All config options are optional. Defaults are shown in the table below.

custom:
    autoswagger:
        title: 'string'
        apiType: 'http' | 'httpApi'
        generateSwaggerOnDeploy: true | false
        typefiles: ['./src/types/typefile1.d.ts', './src/subfolder/helper.d.ts']
        swaggerFiles: ['./doc/endpointFromPlugin.json', './doc/iCannotPutThisInHttpEvent.json', './doc/aDefinitionWithoutTypescript.json']
        swaggerPath: 'string'
        apiKeyHeaders: ['Authorization', 'anyOtherName']
        useStage: true | false
        basePath: '/string'
        host: 'http://some-host'
        schemes: ['http', 'https', 'ws', 'wss']
        excludeStages: ['production', 'anyOtherStage']
        lambdaAuthorizer: ${self:custom.myAuthorizer}
        useRedirectUI: true | false
OptionDescriptionDefaultExample
apiKeyHeadersArray of strings used to define API keys used in auth headers[]apiKeyHeaders: ['Authorization', 'x-api-key']
apiTypeAPI type for which your Swagger UI and Swagger JSON lambdas should be deployed. Options are http and httpApihttpApi
basePathString that can be prepended to every request. Should include leading /-/some-base => http://localhost/some-base/my-endpoint
excludeStagesArray of strings that contains stages in which Swagger UI and Swagger JSON lambdas should not be deployed in.[]
generateSwaggerOnDeployBoolean which indicates whether to generate a new swagger file on deploymenttrue
hostString that overrides the host. With this you can set your custom domain for your application endpoints-http://some-host => {http://some-host}/my-endpoint
lambdaAuthorizerA String or authorizer object to add security to the lambda /swagger and /swagger.json endpoints-
schemesArray (containing one of http, https, ws, or wss) for specifying schemesScheme used to serve the API specification (reflecting Swagger's behavior)
swaggerFilesArray of string which will merge custom json OpenApi 2.0 files to the generated swagger[]
swaggerPathString for customize swagger path. Your new swagger UI will be available at https://{your-url-domain}/{swaggerPath}swaggermy-swagger => https://{your-url-domain}/my-swagger
titleString to overwrite the project title with a custom oneServerless service name
descriptionString to add the project description-
versionString to overwrite the project version with a custom one1
typefilesArray of strings which defines where to find the typescript types to use for the request and response bodies['./src/types/api-types.d.ts']
useStageBoolean to either use current stage in beginning of path or notfalsetrue => dev/swagger for stage dev
useRedirectUIBoolean to include a path and handler for the oauth2 redirect flow or notfalse

Adding more details

The default swagger file from vanilla Serverless framework will have the correct paths and methods but no details about the requests or responses.

API Summary and Details

The optional attributes summary and description can be used to describe each HTTP request in Swagger.

swaggerTags is an optional array that can be used to group HTTP requests with a collapsible name (i.e. grouping two endpoints GET /dogs and POST /dogs together). If not specified, all HTTP requests will be grouped under default.

http: {
    summary: 'This is a cool API',
    description: 'Cool API description is here',
    swaggerTags: ['Dogs']
}

Adding Data Types

This plugin uses typescript types to generate the data types for the endpoints. By default, it pulls the types from src/types/api-types.d.ts.

You can then assign these typescript definitions to requests as bodyType on the http or https config, or to the response as seen just below.

Responses

You can also add expected responses to each of the http endpoint events. This is an object that contains the response code with some example details:

responseData: {
    // response with description and response body
    200: {
        description: 'this went well',
        bodyType: 'helloPostResponse',
    },

    // response with just a description
    400: {
        description: 'failed Post',
    },
    // shorthand for just a description
    502: 'server error',
}

Post request expected body

When you create a POST or PUT endpoint, you expect to receive a specific structure of data as the body of the request.

You can do that by adding a bodyType to the http event:

http: {
    path: 'hello',
    method: 'post',
    cors: true,
    bodyType: 'helloPostBody',
}

Query String Parameters

If you want to specify the query string parameters on an endpoint you can do this by adding an object of queryStringParameters to the event (original I know). This has two required properties of required and type as well as an optional description.

http: {
    path: 'goodbye',
    method: 'get',
    queryStringParameters: {
        bob: {
            required: true,
            type: 'string',
            description: 'bob',
        },
        count: {
            required: false,
            type: 'integer',
        },
    },
},

Query String Parameters

If no queryStringParameters are defined, the plugin will do its best to generate headers based on any Serverless request.parameters.querystrings that are defined.

Multi-Valued Query String Parameters

If you use multi-value query string parameters (array), then you must specify that your type is array and specify your data type (string or integer) in arrayItemsType

http: {
    path: 'goodbye',
    method: 'get',
    queryStringParameters: {
        bob: {
            required: true,
            type: 'array',
            arrayItemsType : 'string',
            description: 'bob',
        },
        count: {
            required: false,
            type: 'array',
            arrayItemsType : 'integer',
        },
    },
},

Query String Parameters

Header Params

Works the same way as queryStringParameters, but for headers.

To use it, just define it under headerParameters:

http: {
    path: 'goodbye',
    method: 'get',
    headerParameters: {
        bob: {
            required: true,
            type: 'string',
            description: 'bob',
        },
        count: {
            required: false,
            type: 'integer',
        },
    },
},

If no headerParameters are defined, the plugin will do its best to generate headers based on any Serverless request.parameters.headers that are defined.

Path Parameters

Path parameters are resolved first by looking at request.parameters.paths, and then by resolving any additional parameters in the http event path (i.e. /{id}).

Exclude an endpoint

You can exclude some endpoints from the swagger generation by adding exclude to the http event:

http: {
    path: 'hello',
    method: 'post',
    exclude: true,
}

Custom operationId

You can override the automatically generated operationId by adding the operationId property to the http event. This can be useful when using code generators.

http: {
    path: 'hello',
    method: 'post',
    operationId: 'postHello',
}

MIME Types

You can specify the MIME types by adding consumes and produces to the http event. Default for both is ['application/json']

http: {
    path: 'hello',
    method: 'post',
    consumes: ['application/json', 'application/pdf'],
    produces: ['application/json', 'application/pdf'],
}

with Serverless Offline

In the plugin list, you must list serverless-auto-swagger before the serverless-offline plugin. If you don't, you won't get the required endpoints added to your local endpoints.

To use serverless v2, you must run serverless-offline in backwards compatibility mode with serverless offline start.

FAQs

Package last updated on 09 May 2024

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc