HTTP Node

The HTTP Node allows a workflow to make an arbitrary HTTP request and optionally place the response on the current payload.

Node Properties

The HTTP Node can be configured with all the common properties of an HTTP request - request method, request URL, request body, and request headers. In addition, the node can optionally store the response of the request at a spot in the payload.

Request Configuration

HTTP Request Configuration contains the following fields:

• Request Method (Required): The HTTP request method. Available methods are GET, POST, PUT, PATCH, and DELETE.
• URL Template (Required): The URL to make the request to. This field supports static URLs or string templates.
• Timeout Template (Required): A string template or integer for the number of seconds to wait before a timeout will occur. The maximum and default timeout is 30.
• Body Type: If using a Request Method that allows for sending a body (POST, PUT, and PATCH requests), you must choose a Body Type for constructing the body. Options are:
  • None: Do not send a body with the request.
  • Raw input: This option is selected by default. When choosing this method, you must enter the following fields:
    • Body Encoding Type: Select an encoding type for your request body. By default UTF8 is selected.
    • Body Template: Enter a value for the body of the request. Many web servers will expect a Content-Type header to be set with a value matching the format of the data submitted here (for example, application/json or text/plain).
  • multipart/form-data: Selecting this option submits the body with the multipart/form-data encoding type. Then, enter one or more “Name Template” and “Value Template” values to send as the body.
  • application/x-www-form-urlencoded: Selecting this option submits the body with the application/x-www-form-urlencoded encoding type. Then, enter one or more “Name Template” and “Value Template” values to send as the body.

In the above example, the node is making a GET request to the URL http://example.datasource.com, thus Body Type is disabled.

Note: For Edge Workflows, the option to select different Body Types is only available in GEA version 1.30.0 or higher. In previous GEA versions, Raw input is the assumed choice, and you must enter a Body Template and a Body Encoding Type.

Furthermore, the option to choose a Body Encoding Type other than UTF8 is only available in GEA version 1.9.0 or higher.

Header Configuration

The HTTP Node also has optional support for adding headers to the HTTP request. Each header is a combination of a header name and a header value. Header values can take string templates to dynamically build headers out of the current payload if needed. The above example has a single header of User-Agent whose value is the template Losant/{{flowId}}.

Authorization

The HTTP Node can optionally set authorization information for requests. There are three options for authorization:

• None: No authorization information is sent with the request.
• Basic: The request is sent with a Basic authorization header. When selecting this method you must also provide a Username and Password, which will automatically be Base64-encoded and sent as the value of the header. The screenshot above shows a basic auth configuration, with the username exampleUser and the password examplePass.
• Client Certificate: The request is sent with the Client Certificate for the server to authenticate. When selected, you must also provide a Client Certificate Key and a Client Certificate.

Note: For Edge Workflows, authorization features are only available for workflows targeting GEA version 1.2.0 or higher, and the Client Certificate method is only available for workflows targeting GEA version 1.5.0 or higher.

SSL Options

Next, you can decide whether to Disable SSL Verification, which is useful if you are connecting to a server with a self-signed SSL certificate. In the given example, the SSL certificate will still be verified by the request and if it is invalid, the node will return an error. However, if this box was checked, it would not ensure that the SSL certificate is valid.

If you are using a self-signed, custom, or uncommon Certificate Authority, you can also optionally provide the CA certificate. This allows you to keep SSL verification enabled, even when using certificates that Losant normally would not be able to verify.

Note: For Edge Workflows, this feature is only available for workflows targeting GEA version 1.5.0 or higher.

Response Configuration

There are two optional fields to set for handling the response to the HTTP request.

• Response Encoding Type: Optionally, you can specify the body response encoding type. By default, the encoding type is UTF8.
• Payload Path to Store Response: The HTTP Node can optionally store the response from the request at an arbitrary payload path. If a path is defined, the body, headers, status code, and original request information are stored at the given path. The node also attempts to parse the body as JSON. if it is parsable, the parsed object is placed on the payload instead of the raw response body string. In the example above, the response will be stored at the working.result field.

Note: For Edge Workflows, the body response encoding type will only be available for workflows targeting GEA version 1.8.0 or higher.

Error Configuration

Any HTTP request that returns an actual response (even if it is a 4XX or 5XX status code) will be treated as a response, and so will be stored at the response path. However, there are many reasons why the HTTP node might error without a response, such as timeouts, unreachable servers, DNS resolution failures, and the like.

In those cases, there are two possible options:

• Error The Workflow: The workflow will throw an error, meaning it will stop execution at this node.
• Store HTTP Response At Payload Path: The error can be stored at a path on the payload that you define, in which case the workflow execution will continue. If you choose to store the error at a path on the payload, an object will be placed at that path with the original request information as well as the particular error that occurred.

Note: For Edge Workflows, this feature is only available in GEA version 1.1.1 or higher. In earlier GEA versions, the workflow will throw an error and cease execution if the HTTP Node receives no response.

Node Example

With the above example (a GET request to http://example.datasource.com) and the result placed at the payload path of working.httpResponse, a successful response to the request would result in a payload like the following:

{
  "applicationId": "555555555555eeeeeeeeeeee",
  "applicationName": "My Great Application",
  "data": {},
  "flowId": "333333333333cccccccccccc",
  "flowName": "My Great Workflow",
  "flowVersion": "myFlowVersion",
  "globals": {
    "aJsonGlobal": {
      "key": "value"
    },
    "aNumberGlobal": 42,
    "aStringGlobal": "My value"
  },
  "relayId": "333333333333cccccccccccc-<unique trigger key>",
  "relayType": "timer",
  "time": Fri Feb 19 2016 17:26:00 GMT-0500 (EST),
  "triggerId": "333333333333cccccccccccc-<unique trigger key>",
  "triggerType": "timer",
  "working": {
    "httpResponse": {
      "body": [
        {
          "millisUTC": 1456158300000,
          "price": 2.5
        },
        {
          "millisUTC": 1456158000000,
          "price": 2.5
        }
      ],
      "headers": {
        "strict-transport-security": "max-age=15768000",
        "content-type": "text/html; charset=UTF-8",
        "connection": "close",
        "transfer-encoding": "chunked"
      },
      "statusCode": 200,
      "request": {
        "headers": {
          "User-Agent": "Losant/333333333333cccccccccccc"
        },
        "strictSSL": true,
        "uri": "http://example.datasource.com",
        "method": "GET"
      }
    }
  }
}

Node Errors

If Error The Workflow is selected in the Error Configuration, an error object will be placed at the specified payload path (if one is provided. Given an error path of working.httpError and a request the failed due to an invalid URL, an error response would be placed on the payload like so:

{
  "applicationId": "555555555555eeeeeeeeeeee",
  "applicationName": "My Great Application",
  "data": {},
  "flowId": "333333333333cccccccccccc",
  "flowName": "My Great Workflow",
  "flowVersion": "myFlowVersion",
  "globals": {
    "aJsonGlobal": {
      "key": "value"
    },
    "aNumberGlobal": 42,
    "aStringGlobal": "My value"
  },
  "relayId": "333333333333cccccccccccc-<unique trigger key>",
  "relayType": "timer",
  "time": Fri Feb 19 2016 17:26:00 GMT-0500 (EST),
  "triggerId": "333333333333cccccccccccc-<unique trigger key>",
  "triggerType": "timer",
  "working": {
    "httpError": {
      "error": {
        "message": "Invalid URL: api.losant.com/devices",
        "name": "ValidationError"
      },
      "request": {
        "timeout": 30000,
        "headers": {},
        "strictSSL": true,
        "uri": "api.losant.com/devices",
        "method": "GET"
      }
    }
  }
}

Related Nodes

• HTTP Output Node