REST stands for REpresentational State Transfer. REST services are type of Web services that typically expose some of the following four types of operations:

GET - to get a resource

POST - to make a new resource or to perform a request (such as search)

PUT - to update a resource

DELETE - to delete a resource

Adding a REST Service

Expand Service templates under Available services in the Service Panel.

Select REST service.

Drag REST service and drop it into the Workflow Diagram.

In a dialog that pops up, configure the REST service as explained next.

Configuring a REST Service

When you add a REST service to your workflow, you can configure:

The URL of the service you want to add

Type of the operation you want to perform on the service (GET, POST, PUT or DELETE), and

The expected data type as returned by the services.

The URL of the service you enter is actually a template that can take configurable parameters (such as parameter "id" in the figure above). Parameters can be used when you do not know their value in advance (i.e. at the time of adding the service to the workflow diagram) and they depend on some of the previous services in the workflow. Value in braces (such as {userID} in the figure above) will be replaced with the actual value at the time of running the workflow and an input port named "userID" will be automatically be created for your REST service.

Advanced Configuration

There are few advanced options you can configure on a REST service:

Send HTTP Expect request-header field.

Show "Redirection" output port.

HTTP Expect request-header

Send HTTP Expect request-header field option allows Taverna to set a special "Expect" header when sending a request to the service. When this header is set, client requests that use the POST method expect to receive, e.g. a 100-Continue or Redirect response from the service to indicate that the client should proceed to send the POST data. This mechanism allows clients to avoid sending large amounts of data over the network twice when the service could reject or redirect the request.

For example, if this header is set, initially only the request headers are sent to the service (while the data to be POSTed is not transmitted). If the service does not reject the request, it sends, for example, a 100-Continue or Redirect response signaling to the client that the data can be transmitted (in the case of Redirect, the data should be transmitted to a different URL). If, for example, the service requires authentication, it sends the 401 response and the client has not unnecessarily transmitted the data.

Selecting this option may significantly improve performance when large volumes of data are to be sent to the service and authentication or a redirect from the original URL to the one specified by the service is likely.

Redirection output port

Show "Redirection" output port option makes the service's redirection output port visible (this output port is hidden by default). The port will contain the URL of the final redirect that has yielded the output data on the responseBody port.