Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The file that is linked below includes two different examples of workflow configurations that use the REST Client agent:

  • WF_REST_EXAMPLE_NOAUTH periodically sends GET and POST requests to http://httpbin.org. Debug events are generated to display the responses from the server. No authentication is used.
  • WF_REST_EXAMPLE_OAUTH20 sends a single query, when the workflow starts, via the Twitter REST API at https://api.twitter.com. Debug events are generated to display the response from the server. OAuth 2.0 is used for authentication.
  • WF_REST_EXAMPLE_SESSION periodically sends GET requests to http://httpbin.org. The APL in this example has been configured to extract the redirect location from the response header and reprocess the request. The workflow uses an Aggregation agent to keep track of the number of reprocessing attempts. The APL configuration also handles token expiration. However, token expiration will not occur since the REST Client agent has not been configured to use authentication.

Example workflows: REST_example_export.zip

Note!

In order to run the workflow WF_REST_EXAMPLE_OAUTH20, you must first register an application at https://apps.twitter.com. Once the registration is completed, you will receive a "Consumer Key" and a "Consumer Secret". Use these to set the Client ID and the Client Secret in the Authentication tab of the REST Client agent.

Before you use the Twitter REST API, read the Rate Limiting documentation. If your registered application exceeds the rate limit, it may be blacklisted.

  • No labels