Using the REST management API with Swagger UI

To use the REST Swagger interface, you select a resource type and an endpoint method, and then pass the appropriate parameters. When you invoke the endpoint method, the resulting request and response are displayed immediately.

1. Sign in to the Rule Execution Server console as an administrator and click the REST API tab to display the REST Management Swagger UI interface.
2. In the REST API tab, click the section for the resource on which you want to call methods: Ruleapps, Rulesets, Libraries (XOM libraries), Xoms (XOM resources), Decisiontraces (Decision Warehouse traces), Executionunits (execution units), Utilities and Configuration. By default, these sections are collapsed.
3. When expanding a Resource section, a list of rest endpoints is displayed. Each endpoint starts with an HTTP method (GET, POST, PUT, or DELETE), followed by the path of the endpoint, and ends with the name of the endpoint.
   By clicking on an endpoint, its details are displayed using a Parameters section, a Query section (when available) and a Responses section.

   Note:

   • GET endpoints returning a collection (a list of objects) have a special handling mechanism. First, they have two method names in their description: getXXXXXX and getCountOfXXXXX. They also carry an optional boolean count query parameter as the first parameter. By default, the count parameter is not set. When set to true, it overrides all the other non-mandatory parameters, and the endpoint returns the count of items in the collection.
   • On top of the Parameters section, a Try it out button is available. The button must be clicked prior to invoking the execution. Once clicked, it becomes a Cancel button, and then, an Execute button appears at the end of the Parameters section.
4. The Parameters section lists all the parameters that can be used. Each parameter includes a description and details:
   • Mandatory (or optional)
   • Path or Query
   • Possible values for enumerations

   Once the Try it out button has been clicked, parameters can be modified.

   Use the following table to parameterize your request:

   Table 1. Parameters

   Methods	Parameters	Parameter templates
   All	Some methods take parameters for which you can add your own custom values to the predefined values.	Parameter templates, which are displayed between curled brackets ({}) in the calling URLs, are placeholders. You must specify a value for them because they are mandatory.
   GET	In some GET methods, no parameters are mandatory. In this case, you can click the Execution button directly.

5. The Request body section (only for POST or PUT HTTP methods) displays a sample representation. You can change the representation of the sample by changing the media type for the request body only when multiple media types are available. Once the Try it out button has been clicked, the request Body content can be modified.

   Some methods do not take a request body.

   Table 2. Request Body

   Methods	Input format	Resources
   POST and PUT methods	For the methods that require a request body, the request body uses one of the following formats: An XML or JSON description of the object A binary file, which makes the parameter mandatory: until you select a file, a warning icon is displayed. A value in a plain-text field, such as a property value	For RuleApp and ruleset resources, you must pass a valid ruleset archive in one of two ways: You encode an existing ruleset in Base64 and add the resulting code to the XML or JSON code. You leave the bytecode provided in the <archive></archive> XML tag pair or in the JSON "archive" tag of the Request Body. This bytecode composes a valid ruleset archive with no rules, no rule flow, no parameters. You can later update this empty ruleset archive with a real ruleset archive.

6. In the Responses section, the HTTP response codes and their descriptions are displayed. A sample is displayed for successful response code. You can change the representation of the sample response by changing the media type.
   Note: When invoking an endpoint, the media type specification can only be handled in the Request body and the Responses section, where the media types can be changed. These are the only places where the Media type parameters can be handled in the Swagger UI interface.
7. After the endpoint is invoked, by clicking on the Execute button, new information is then available in the Responses section:
   • Curl information displays a curl command similar to the endpoint invocation that was done.
   • Request URL information displays the URL of the endpoint that was invoked.
   • Server response information displays the return code, the response body (if any) and the response headers information.