HTTP Request

Description

The HTTP Request action allows a Flow to perform an HTTP action on an REST endpoint.

Additional configuration can be passed like Headers, ContentType (list of most important MIME types) and Content.

After executing the request it will return the HTTP response status code and the response content as string.

REST Request

Usage

This action could be used for example to POST or DELETE to an endpoint, in order to create, update or delete a REST resource.

It can also be used to GET HTTP request method to retrieve data to pass to the next action.

There are three types of authentication for the request:

None: No authentication needed.

Basic: Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header, that contains the username and password encoded in base64 form.

Basic Authentication

Bearer: Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name Bearer authentication can be understood as give access to the bearer of this token.

Bearer Authentication

Input samples in JSON notation

Authentication type: None

{
    'AuthenticationType': 'None'
    'Method': 'string',
    'Url': 'string',
    'ContentType': 'string',
    'Content': 'string',
    'Headers': {
        'key': 'value'
    }
}

Authentication type: Basic

    {
      'AuthenticationType': 'Basic',
      'Username': 'string',
      'Password': 'string',
      'Method': 'string',
      'Url': 'string',
      'ContentType': 'string',
      'Content': 'string',
      'Headers': {
        'key': 'value'
        }
    }

Authentication type: Bearer

    {
      'AuthenticationType': 'Bearer',
      'Token endpoint': 'string',
      'Client': 'string',
      'Client Secret': 'string',
      'Requested Scope': 'string',
      'Method': 'string',
      'Url': 'string',
      'ContentType': 'string',
      'Content': 'string',
      'Headers': {
        'key': 'value'
        }
    }

Output sample

{
    'StatusCode': 200,
    'Headers': {
        'key': [
         'value'
        ]
    },
  'Response': 'string'
}
}

Certificates

A Client Certificate can be attached to the HTTP request sent, this can be done under "Advanced configuration" section. In this section, a dropdown is displayed and will allow the user to select one of the certificates that have been added for this tenant.

There is also the option to attach a Remote Certificate, providing added identity authentication on received data through a mTLS protocol. You can find more info about setting up certificates here.

NOTE In order to add a Remote Certificate to the HTTP request a Client Certificate must be already provided.

Certificate dropdown

Multipart/form-data content type support

The HTTP Request action supports the usage of multipart/form-data content type.

Multipart/form-data dropdown

Once the content type is selected, a new Form Data section will be displayed, where the Form Data can be configured.

Multipart/form-data form list

Form Data fields can be added and configured using the Add button and filling the information in the popup.

There are two types of fields available: Text and File:

The Text form data value requires the key and value provided in the configuration.
The File form data value requires a key, the file content value and a filename. The supported file content is plain text for text files (XML, CSV, Json, etc...) and Base64 encoding for binary files (PDF, PNG, etc...).

Multipart/form-data form text Multipart/form-data form file

Binary application/octet-stream content type support

The HTTP Request action supports the usage of Binary application/octet-stream content type.

Content type dropdown menu for Binary application/octet-stream

General retry settings

The HTTP request performed in this action is implemented with some default retry settings so that the operation is resilient and can adapt to the most typical cases of the returning statuses considered transient: * 403 - Forbidden * 408 - Request timeout * 429 - Too many requests * 5XX - Server errors

The maximum number of retries set for each operation is 5.

The complete retry operation (within the retries and corresponding waiting times in between) will timeout after 9 minutes.

Each retry operation will timeout after 100 seconds.

Retry-after

Retry after header is a standard response HTTP header that indicates how long the user agent should wait before making another request.

It is sent within statuses 503 (Service unavailable), 429 (Too Many request) as detailed here.

Also with status code 403 (Forbidden) when it is the result of a quota exceeded. For more info see here.

It will be taken into account in the default retry pattern implementation.

403 (Forbidden) or 429 (Too many request)

When one of these statuses is returned by the HTTP request, the waiting time before retrying is: * Retry-after header value if received (with a maximum time of thirty seconds) * A random amount of time as per this distribution. The random time is generated between 250 milliseconds and 30 seconds.

503 - Service unavailable

When a status 503 (Service unavailable) is returned by the HTTP request, the waiting time before retrying is: * Retry-after header value if received (with a maximum time of one minute) * One minute wait if no retry-after header received

Any of the other statuses considered previously as transient

When a status 5XX (Server error) besides 503, or 408 (Request timeout) is returned by the HTTP request, the waiting time before retrying is: * A random amount of time as per this distribution. The random time will be generated between 250 milliseconds and 30 seconds.