HTTP header fields and URI parameters

HTTP header fields

Accept

Specifies the content types that are valid in the response message. If the server cannot respond with the requested content type, the 406 Not Acceptable HTTP status code is returned. You can use the equivalent URI parameter instead of the HTTP header field.

Accept-Language

Sends the list of languages that are valid for the response message. For example, Accept-Language: fr, pt-BR means that the preferred language is French but Brazilian Portuguese is also accepted. You can use the equivalent URI parameter instead of the HTTP header field.

Content-Type

Indicates which content type of the entity body is sent to the recipient.

X-Method-Override

X-HTTP-Method-Override

Indicates the HTTP operation that is passed through the current request. You can use the equivalent URI parameters instead of the HTTP header fields.

Generic URI parameters

In the Rule Execution Server REST API, the following parameters are generic.

accept

Use this parameter in the request message to specify the content types that are valid in the response message. This parameter is equivalent to the Accept HTTP header field.

accept-language

Use this parameter in the request message to send the list of languages that are valid for the response message. This parameter is equivalent to the Accept-Language HTTP header field.

parts

Use this parameter in the request message to specify a list of one or more parts to be returned in the response message. Use a vertical line |(%7C in URL encoding) to separate the items in the list. You can also specify all or none as the value of the parts parameter. The default value is all. For example, the response to the following request contains the name, version number, and properties of the rulesets that belong to the specified RuleApp.

http://localhost:9080/res/apiauth/v1/ruleapps/myRuleApp/1.0?parts=name|version|properties

date

Used in the request message to specify the date format that is expected in the response message: iso8601 for the ISO-8601 or long for the Linux style. The default value is iso8601. Use the following syntax:

date=iso8601
date=long

Parameters for collection types

All Rule Execution Server REST results that are collections of resources support the count parameter, filters, and paging services. You can use the DOJO API to define paging services.

These parameters apply only to the GET method, which returns collections. Use the following syntax elements to build the request and response:

Request

• URL: /collection
• Method: GET
• Header: "Range: items=start-stop"

Response

• Header: "Content-Range: items start-stop/count"
• Body: the content of the collection between the start-stop index.

count

If the value of this parameter is true or is not specified, the response returns plain text that contains the number of elements in the resulting collection of the query URI path.

fieldName

To provide filtering services, you can add key/value pairs as query parameters that apply to the collection members. The value can be a static name or a regular expression. To use a regular expression, start the value with exp( and end with a closing parenthesis ).

Note: The regular expression might not be valid. For example, a character is not escaped properly. In this case, the system raises an HTTP 412 error.

In the following example, the request retrieves the RuleApps the name of which starts with Hello.:

http://localhost:9080/res/apiauth/ruleapps?name=exp(Hello.*)

In the following example, the request is incorrect and returns an HTTP 412 error because the regular expression misses one closing parenthesis.

http://localhost:9080/res/apiauth/ruleapps?name=exp(Hello(.*)

orderby

This parameter orders the resulting list according to the specified field name. You can add more than one orderby parameter. The following example orders the RuleApps by name and version number.

http://localhost:9080/res/apiauth/ruleapps?orderby=name&orderby=version