Tasks are the building blocks for all data interactions, declaring how to communicate with a given app over HTTP.
Under the hood, tasks just model regular HTTP interactions.
We support either
https to indicate a secure connection.
This is the service we intend on talking to. E.g.
api.server.com would be a host.
This is the specific path the request will make to the server. E.g. a path could be
/resources/123 to indicate a request to a specific resource.
HTTP headers are a collection of key value pairs sent to the server. They are often used to send authentication credentials as they are considered more secure than other parts of the request which are not usually logged.
Some requests can have a body, which could be structured JSON, free text or binary form data. It is common for most tasks to not have a body.
Each task may declare a set of inputs to customize exactly what the task does. For example, if your task is to fetch the current weather for a given city, you may want to make the ZIP code of the city an input for users to enter.
Inputs are implemented via templating, allowing you to find and replace via string matching in the following parts of the HTTP request:
When a task is run, first the inputs are injected into the task definition resulting in an HTTP request to the service in question.
Task collections allow you to automatically extract expected, structured data from task results. These currently only work with JSON responses.