Persistent and Transient REST Hosts

The HTTP-REST plug-in supports two types of REST hosts that you can use to make requests to REST endpoints - persistent hosts and transient hosts.

Differences between persistent and transient hosts

The following table compares the two types of REST hosts.


Persistent Hosts	Transient Hosts
Stored in the vRealize Orchestrator database.	Not stored in the vRealize Orchestrator database. Transient hosts are virtual objects which reside in memory while a script is being executed.
Stored in the vRealize Orchestrator inventory. Persistent hosts can also be viewed in form drop-down menus of the RESTHost type.	Not stored in the vRealize Orchestrator inventory.
Available after restart, failover, and upgrade. When a workflow token gets interrupted, it can continue from where it left off if the workflow item takes a persistent REST host as input. Use persistent hosts as inputs/outputs of workflow items. You can create them at the beginning of the scripting and delete them if you don't need them anymore.	Not available after restart and failover. When a workflow gets interrupted, it can't restore a workflow item input which carries a transient REST host. Use transient hosts in scripting when you make isolated requests against a server which you otherwise don't use.
Can be exported and imported as resource elements.	Transferable across different vRealize Orchestrator instances because they are created and managed entirely from scripting. Use transient hosts when you work on multiple environments with no need to migrate persistent hosts.
Each persistent host has a dedicated HTTP client that is used for managing requests to the endpoint.	Hosts reuse the same HTTP client instance.
Parallel requests are supported for persistent and transient hosts. If you activate parallel requests, each request is executed with a separate context, and the state, including cookies, is not preserved between requests. If support for parallel requests is deactivated, consecutive requests share the same HTTP context.

Considerations for transient hosts

When creating transient hosts, consider the following.

Transient hosts passed between workflow items as input/output might not work in all cases. Transient hosts rely on workflow cache, which doesn't work when asynchronous workflows are started, for example. Nested workflows might also fail.
Only GET and HEAD requests get redirected automatically. URL redirection uses the default strategy.
Host name verification is not supported.
Client certificate authentication is not supported.

Troubleshooting

If you use transient hosts without support for parallel requests, you might experience scripting regressions after upgrading your vRealize Orchestrator environment or upgrading the HTTP-REST plug-in to version 2.4.1.19272162 or later. Using different transient host instances to run requests, which depend on one another for cookies, is not supported as of vRealize Orchestrator 8.7.

To avoid this problem, use one of the following methods.

Instead of transient hosts, use persistent hosts and operations. You can create persistent REST hosts in one of two ways.
1. Create a REST host pointing to the server using the Add a REST host workflow.
  Instead of using transient hosts, use the REST host as input everywhere where you need to create a request to it.
  - Do not create transient operations pointing to this host. Create regular operations instead.
  - Support for parallel requests must be deactivated, otherwise cookies are not preserved.
  This approach is not recommended if you make multiple requests in parallel to this host in your workflows.
2. Create a REST host per workflow run from the scripting, and then delete it.
  Use this method if you make parallel requests to the server. For example, if you have two parallel requests, create two different hosts.
  1. Clone a workflow.
  2. Add a scripting element which creates the host that you want to use for future requests.
  3. Use the host as the output of the workflow and as input to all other scripting that makes requests to that host.
  4. To clean the state, add an element at the end of the scripting which deletes the host you created.
Use one transient host for all dependent requests in a given workflow and pass it between workflow items as input/output as needed.
Passing transient hosts between multiple workflow elements is not officially supported, but expected to work. Note that during restart, the workflow state might be lost and the workflow might not resume successfully.
If you use transient hosts and you want to make requests which depend on each other for cookies, you must use the same transient host instance for all requests. If the requests span multiple workflow items, create the host in the first workflow item and then pass it as input to the rest.
Use your current transient hosts, but modify the failing requests to include the necessary cookies by adding the respective headers.
You might have to parse the cookies from the previous response and use them in subsequent requests.