This is a Feature Proposal

Description

APIG selects the proper response content type based on the request Accepts Header.
From AWS APIG documentation:

Select Mapping Templates

The request mapping template used to transform the method request body into the integration request body is selected by the value of the "Content-Type" header sent in the client request.

The response mapping template used to transform the integration response body into the method response body is selected by the value of the "Accept" header sent in the client request.

For example, if the client sends headers of "Content-Type : application/xml", and "Accept : application/json", the request template with the application/xml key will be used for the integration request, and the response template with the application/json key will be used for the method response.

Only the MIME type is used from the Accept and Content-Type headers when selecting a mapping template. For example, a header of "Content-Type: application/json; charset=UTF-8" will have a request template with the application/json key selected.

We have several API's that rely on this behavior to allow users to select the response's content-type The current design of serverless response template only allows a single content-type to be defined, rather than allowing for multiple content types.

response:
    contentType: text/html
    template:
        - "#set($inputRoot = $input.path('$'))"
        - "$inputRoot.html"

If the response template was patterned after the request templates, users of a service could determine the content-type of the response using the standard Accepts header mechanism.

          request:
            template:
              text/xhtml: { "stage" : "$context.stage" }
              application/json: { "httpMethod" : "$context.httpMethod" }

Specific Use Cases

There are two specific use cases we have for this functionality:

1. Our configuration service allows a client to determine which format it wants in the response. Each request Accepts header maps directly to the equivalent content-type:
   Accepts: application/json
Accepts: application/xml
Accepts: application/x-sh
2. Most of our services use the quasi-standard mechanism of using the request Accepts header to select a version of our API. This is the same mechanism Github and other sites use to select different versions of an API (Github API Versioning)
   Accepts: application/vnd.shelfbucks.v5+json
Accepts: application/vnd.shelfbucks.v6+json
Accepts: application/vnd.shelfbucks.v7+json
   This use case results in the responses all mapping to same content-type (application/json) but with different json schemas.

Similar or dependent issues:

Additional Data

• _Serverless Framework Version 1.0.0-rc.1_:
• _Operating System_:
• _Stack Trace_:
• _Provider Error messages_: