Adding an HTTP or HTTPS URL as an API Gateway Back End

To add an HTTP or HTTPS back end to an API deployment specification using the Console:

1. Create or update an API deployment using the Console, select the From Scratch option, and enter details on the Basic Information page.

   For more information, see Deploying an API on an API Gateway by Creating an API Deployment and Updating an API Gateway or an API Deployment.

2. On the Authentication page, specify authentication options.

   For more information about authentication options, see Adding Authentication and Authorization to API Deployments.

3. On the Routes page, create a new route and specify:

   • Path: A path for API calls using the listed methods to the back-end service. Note that the route path you specify:

     • is relative to the deployment path prefix (see Deploying an API on an API Gateway by Creating an API Deployment)
     • must be preceded by a forward slash ( / ), and can be just that single forward slash
     • can contain multiple forward slashes (provided they are not adjacent), and can end with a forward slash
     • can include alphanumeric uppercase and lowercase characters
     • can include the special characters $ - _ . + ! * ' ( ) , % ; : @ & =
     • can include parameters and wildcards (see Adding Path Parameters and Wildcards to Route Paths)
   • Methods: One or more methods accepted by the back-end service. For example, GET, PUT.

   • Add a single backend or Add multiple backends: Whether to route all requests to the same back end, or to route requests to different back ends according to the context variable and rules you enter.

     These instructions assume you want to use a single back end, so select Add a single backend. Alternatively, if you want to use different back ends, select Add multiple backends and follow the instructions in Using the Console to Add Dynamic Back End Selection to an API Deployment Specification.

   • Backend Type: The type of the back-end service as HTTP.

   • URL: The URL you want to use as the back-end service, in the format <protocol>://<host>:<port>/<path> where:

     • <protocol> is either http or https.
     • <host> is the host name or the host IP address of the back-end service. For example, api.weather.gov. If you provide a host name, use the DHCP Options property of the API gateway's subnet to control how host names are resolved to IP addresses at runtime.
     • <port> is optionally a port number.

     • <path> is optionally a subdirectory or file at the host where the back-end service is located.

       Note that <path> must not contain parameters directly, but can contain context variables. For more information and examples showing how to use context variables to substitute path, query, and header parameters into the path, see Adding Context Variables to Policies and HTTP Back End Definitions.

     For example, "url": "https://api.weather.gov".

   • Connection establishment timeout in seconds: Optionally, a floating point value indicating how long (in seconds) to allow when establishing a connection with the back-end service. The minimum is 1.0, the maximum is 75.0. If not specified, the default of 60.0 seconds is used.
   • Request transmit timeout in seconds: Optionally, a floating point value indicating how long (in seconds) to allow when transmitting a request to the back-end service. The minimum is 1.0, the maximum is 300.0. If not specified, the default of 10.0 seconds is used.
   • Reading response timeout in seconds: Optionally, a floating point value indicating how long (in seconds) to allow when reading a response from the back-end service. The minimum is 1.0, the maximum is 300.0. If not specified, the default of 10.0 seconds is used.
   • Disable SSL verification: Whether to disable SSL verification when communicating with the back-end service. By default, this option is not selected.

   In this example, the route defines a weather service as an HTTP back end.

   Field:	Enter:
   Path:	/weather
   Methods:	GET
   Backend Type:	HTTP
   URL:	https://api.weather.gov
   Connection establishment timeout in seconds:	45
   Request transmit timeout in seconds:	15
   Reading response timeout in seconds:	15
   Disable SSL verification:	(Not selected)

4. (Optional) Click Another Route to enter details of additional routes.
5. Click Next to review the details you entered for the API deployment.
6. Click Create or Save Changes to create or update the API deployment.
7. (Optional) Confirm the API has been deployed successfully by calling it (see Calling an API Deployed on an API Gateway).

To add an HTTP or HTTPS back end to an API deployment specification in a JSON file:

1. Using your preferred JSON editor, create a new API deployment specification (see Creating an API Deployment Specification) in the format:

   {
     "requestPolicies": {},
     "routes": [
       {
         "path": "<api-route-path>",
         "methods": ["<method-list>"],
         "backend": {
           "type": "HTTP_BACKEND",
           "url": "<identifier>",
           "connectTimeoutInSeconds": <seconds>,
           "readTimeoutInSeconds": <seconds>,						
           "sendTimeoutInSeconds": <seconds>,
           "isSSLVerifyDisabled": <true|false>
         },
         "requestPolicies": {},
       }
     ]
   }

   where:

   • "requestPolicies" specifies optional policies to control the behavior of an API deployment. If you want to apply policies to all routes in an API deployment specification, place the policies outside the routes section. If you want to apply the policies just to a particular route, place the policies inside the routes section. See Adding Request Policies and Response Policies to API Deployment Specifications.

   • <api-route-path> specifies a path for API calls using the listed methods to the back-end service. Note that the route path you specify:

     • is relative to the deployment path prefix (see Deploying an API on an API Gateway by Creating an API Deployment)
     • must be preceded by a forward slash ( / ), and can be just that single forward slash
     • can contain multiple forward slashes (provided they are not adjacent), and can end with a forward slash
     • can include alphanumeric uppercase and lowercase characters
     • can include the special characters $ - _ . + ! * ' ( ) , % ; : @ & =
     • can include parameters and wildcards (see Adding Path Parameters and Wildcards to Route Paths)
   • <method-list> specifies one or more methods accepted by the back-end service, separated by commas. For example, "GET, PUT".
   • "type": "HTTP_BACKEND" specifies the API gateway back end is an HTTP or HTTPS URL.

   • "url: "<identifier>" specifies the URL you want to use as the back-end service, in the format <protocol>://<host>:<port>/<path> where:

     • <protocol> is either http or https.
     • <host> is the host name or the host IP address of the back-end service. For example, api.weather.gov. If you provide a host name, use the DHCP Options property of the API gateway's subnet to control how host names are resolved to IP addresses at runtime.
     • <port> is optionally a port number.

     • <path> is optionally a subdirectory or file at the host where the back-end service is located.

       Note that <path> must not contain parameters directly, but can contain context variables. For more information and examples showing how to use context variables to substitute path, query, and header parameters into the path, see Adding Context Variables to Policies and HTTP Back End Definitions.

     For example, "url": "https://api.weather.gov".

   • "connectTimeoutInSeconds": <seconds> is an optional floating point value indicating how long (in seconds) to allow when establishing a connection with the back-end service. The minimum is 0.0, the maximum is 75.0. If not specified, the default of 60.0 seconds is used.
   • "readTimeoutInSeconds": <seconds> is an optional floating point value indicating how long (in seconds) to allow when reading a response from the back-end service. The minimum is 0.0, the maximum is 300.0. If not specified, the default of 10.0 seconds is used.
   • "sendTimeoutInSeconds": <seconds> is an optional floating point value indicating how long (in seconds) to allow when transmitting a request to the back-end service. The minimum is 0.0, the maximum is 300.0. If not specified, the default of 10.0 seconds is used.
   • "isSSLVerifyDisabled": <true|false> is an optional boolean value (either true or false) indicating whether to disable SSL verification when communicating with the back-end service. If not specified, the default of false is used.

   For example, the following basic API deployment specification defines a weather service as an HTTP back end:

   {
     "routes": [
       {
         "path": "/weather",
         "methods": ["GET"],
         "backend": {
           "type": "HTTP_BACKEND",
           "url": "https://api.weather.gov",
           "connectTimeoutInSeconds": 45,
           "readTimeoutInSeconds": 15,						
           "sendTimeoutInSeconds": 15,
           "isSSLVerifyDisabled": false
         }
       }
     ]
   }

2. Save the JSON file containing the API deployment specification.

3. Use the API deployment specification when you create or update an API deployment in the following ways:

   • by specifying the JSON file in the Console when you select the Upload an existing API option
   • by specifying the JSON file in a request to the API Gateway REST API

   For more information, see Deploying an API on an API Gateway by Creating an API Deployment .

4. (Optional) Confirm the API has been deployed by calling it (see Calling an API Deployed on an API Gateway).