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
, andDELETE
. - URL Template (Required): The URL to make the request to. This field supports static URLs or string templates.
- Timeout Template: 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
, andPATCH
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
ortext/plain
).
- Body Encoding Type: Select an encoding type for your request body. By default
- 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 passwordexamplePass
. - 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
Was this page helpful?
Still looking for help? You can also search the Losant Forums or submit your question there.