Amazon API Gateway important notes
The following section details notes that might impact your use of API Gateway.
Topics
Amazon API Gateway important notes for HTTP APIs
-
HTTP APIs translate incoming
X-Forwarded-*headers into a standardForwardedheader and will append the egress IP, Host, and protocol. -
API Gateway adds the Content-type header to your request if there is no payload and the Content-Length is 0.
Amazon API Gateway important notes for HTTP and WebSocket APIs
-
Signature Version 4A is not officially supported by Amazon API Gateway for HTTP and WebSocket APIs.
Amazon API Gateway important notes for REST and WebSocket APIs
-
API Gateway does not support sharing a custom domain name across REST and WebSocket APIs.
-
Stage names can only contain alphanumeric characters, hyphens, and underscores. Maximum length is 128 characters.
-
The
/pingand/spingpaths are reserved for the service health check. Use of these for API root-level resources with custom domains will fail to produce the expected result. -
API Gateway currently limits log events to 1024 bytes. Log events larger than 1024 bytes, such as request and response bodies, will be truncated by API Gateway before submission to CloudWatch Logs.
-
CloudWatch Metrics currently limits dimension names and values to 255 valid XML characters. (For more information, see the CloudWatch User Guide.) Dimension values are a function of user-defined names, including API name, label (stage) name, and resource name. When choosing these names, be careful not to exceed CloudWatch Metrics limits.
-
The maximum size of a mapping template is 300 KB.
Amazon API Gateway important notes for WebSocket APIs
-
API Gateway supports message payloads up to 128 KB with a maximum frame size of 32 KB. If a message exceeds 32 KB, you must split it into multiple frames, each 32 KB or smaller. If a larger message is received, the connection is closed with code 1009.
Amazon API Gateway important notes for REST APIs
-
The plain text pipe character (
|) and the curly brace character ({or}) are not supported for any request URL query string and must be URL-encoded. -
The semicolon character (
;) is not supported for any request URL query string and results in the data being split. -
REST APIs decode URL-encoded request parameters before passing them to backend integrations. For UTF-8 request parameters, REST APIs decode the parameters and then pass them as unicode to backend integrations. REST APIs URL-encode the percent character (
%) before passing it to backend integrations. -
When using the API Gateway console to test an API, you may get an "unknown endpoint errors" response if a self-signed certificate is presented to the backend, the intermediate certificate is missing from the certificate chain, or any other unrecognizable certificate-related exceptions thrown by the backend.
-
For an API
ResourceorMethodentity with a private integration, you should delete it after removing any hard-coded reference of aVpcLink. Otherwise, you have a dangling integration and receive an error stating that the VPC link is still in use even when theResourceorMethodentity is deleted. This behavior does not apply when the private integration referencesVpcLinkthrough a stage variable. -
The following backends may not support SSL client authentication in a way that's compatible with API Gateway:
-
API Gateway supports most of the OpenAPI 2.0 specification
and the OpenAPI 3.0 specification , with the following exceptions: -
Path segments can only contain alphanumeric characters, underscores, hyphens, periods, commas, colons, and curly braces. Path parameters must be separate path segments. For example, "resource/{path_parameter_name}" is valid; "resource{path_parameter_name}" is not.
-
Model names can only contain alphanumeric characters.
-
For input parameters, only the following attributes are supported:
name,in,required,type,description. Other attributes are ignored. -
The
securitySchemestype, if used, must beapiKey. However, OAuth 2 and HTTP Basic authentication are supported via Lambda authorizers; the OpenAPI configuration is achieved via vendor extensions. -
The
deprecatedfield is not supported and is dropped in exported APIs. -
API Gateway models are defined using JSON schema draft 4
, instead of the JSON schema used by OpenAPI. -
The
discriminatorparameter is not supported in any schema object. -
The
exampletag is not supported. -
The
nullablefield is not supported. -
exclusiveMinimumis not supported by API Gateway. -
The
maxItemsandminItemstags are not included in simple request validation. To work around this, update the model after import before doing validation. -
For OpenAPI 3.0, you can't have a
oneOf,anyOf, orallOfthat uses$refto a definition within the same schema. You can either directly input your schema or define a separate API Gateway model resource. For more information, see Creating more complex models. -
oneOfis not supported for OpenAPI 2.0 or SDK generation. -
The
readOnlyfield is not supported. -
$refcannot be used to reference other files. -
Response definitions of the
"500": {"$ref": "#/responses/UnexpectedError"}form is not supported in the OpenAPI document root. To work around this, replace the reference by the inline schema. -
Numbers of the
Int32orInt64type are not supported. An example is shown as follows:"elementId": { "description": "Working Element Id", "format": "int32", "type": "number" } -
Decimal number format type (
"format": "decimal") is not supported in a schema definition. -
In method responses, schema definition must be of an object type and cannot be of primitive types. For example,
"schema": { "type": "string"}is not supported. However, you can work around this using the following object type:"schema": { "$ref": "#/definitions/StringResponse" } "definitions": { "StringResponse": { "type": "string" } } -
API Gateway doesn't use root level security defined in the OpenAPI specification. Hence security needs to be defined at an operation level to be appropriately applied.
-
The
defaultkeyword is not supported.
-
-
API Gateway enacts the following restrictions and limitations when handling methods with either Lambda integration or HTTP integration.
-
Header names and query parameters are processed in a case-sensitive way.
-
The following table lists the headers that may be dropped, remapped, or otherwise modified when sent to your integration endpoint or sent back by your integration endpoint. In this table:
-
Remappedmeans that the header name is changed fromto<string>X-Amzn-Remapped-.<string>Remapped Overwrittenmeans that the header name is changed fromto<string>X-Amzn-Remapped-and the value is overwritten.<string>
Header name Request ( http/http_proxy/lambda)Response ( http/http_proxy/lambda)AgePassthrough Passthrough AcceptPassthrough Dropped/Passthrough/Passthrough Accept-CharsetPassthrough Passthrough Accept-EncodingPassthrough Passthrough AuthorizationPassthrough * Remapped ConnectionPassthrough/Passthrough/Dropped Remapped Content-EncodingPassthrough/Dropped/Passthrough Passthrough Content-LengthPassthrough (generated based on body) Passthrough Content-MD5Dropped Remapped Content-TypePassthrough Passthrough DatePassthrough Remapped Overwritten ExpectDropped Dropped HostOverwritten to the integration endpoint Dropped Max-ForwardsDropped Remapped PragmaPassthrough Passthrough Proxy-AuthenticateDropped Dropped RangePassthrough Passthrough RefererPassthrough Passthrough ServerDropped Remapped Overwritten TEDropped Dropped Transfer-EncodingDropped/Dropped/Exception Dropped TrailerDropped Dropped UpgradeDropped Dropped User-AgentPassthrough Remapped ViaDropped/Dropped/Passthrough Passthrough/Dropped/Dropped WarnPassthrough Passthrough WWW-AuthenticateDropped Remapped * The
Authorizationheader is dropped if it contains a Signature Version 4 signature or ifAWS_IAMauthorization is used. -
-
-
The Android SDK of an API generated by API Gateway uses the
java.net.HttpURLConnectionclass. This class will throw an unhandled exception, on devices running Android 4.4 and earlier, for a 401 response resulted from remapping of theWWW-Authenticateheader toX-Amzn-Remapped-WWW-Authenticate. -
Unlike API Gateway-generated Java, Android and iOS SDKs of an API, the JavaScript SDK of an API generated by API Gateway does not support retries for 500-level errors.
-
The test invocation of a method uses the default content type of
application/jsonand ignores specifications of any other content types. -
When sending requests to an API by passing the
X-HTTP-Method-Overrideheader, API Gateway overrides the method. So in order to pass the header to the backend, the header needs to be added to the integration request. -
When a request contains multiple media types in its
Acceptheader, API Gateway only honors the firstAcceptmedia type. In the situation where you cannot control the order of theAcceptmedia types and the media type of your binary content is not the first in the list, you can add the firstAcceptmedia type in thebinaryMediaTypeslist of your API, API Gateway will return your content as binary. For example, to send a JPEG file using an<img>element in a browser, the browser might sendAccept:image/webp,image/*,*/*;q=0.8in a request. By addingimage/webpto thebinaryMediaTypeslist, the endpoint will receive the JPEG file as binary. -
Customizing the default gateway response for
413 REQUEST_TOO_LARGEisn't currently supported. -
API Gateway includes a
Content-Typeheader for all integration responses. By default, the content type isapplication/json.