For the complete documentation index, see llms.txt. This page is also available as Markdown.

REST API definition

Response definition

The API supports ONLY REST services that return the type application/json .

The default ContentType used when sending requests to the service is application/json. Also supported is multipart/form-data, if the parameter is passed in the header {'Content-Type': 'multipart/form-data'}. For example:

api.rest.v1.get('serviceId', {queryParams: {'key': 'value'}}, {'Content-Type': 'multipart/form-data'});

The response from the service looks as follows:

{
    status: {
        code: int,
        message: String
    },
    headers: Map<String, String>,
    body: Map<String, Object>
}

All elements in the response are processed as native JavaScript variables. They can be accessed, for example, like this:

response.status.code   // <--- get the value from the `code` field, containing the response code, e.g. 200
response.status.message   // <--- get the value from the `message` field, containing the response message, e.g. "Accepted"
 
response.headers.language    // <--- get the value of the return header named `language`
 
response.body.user.type    // <--- get the value of a specific field from the response, where the response looks like: {"user": {"type": "userType"}}

Exception definition

In the case of any return code other than 2XX, we get an exception that can be handled. E.g. in the case of code 404 (service unavailable or invalid address), code 405 (invalid method) or code 500 (internal service error).

The exception looks as follows:

To verify whether this is an exception that we should handle, we can check whether the caught item has the fields we are interested in.

Request definition

A request can be parameterized.

Requests may contain a payload:

And they can be without a payload:

Below is the definition of the parameters:

The PATH definition looks as follows:

The TIMEOUTS definition looks as follows:

Example request executions are in the sections below.

Requests

For each of the following requests, we assume a consistent configuration:

GET

Request without payload.

Examples:

And an example ScriptService:

DELETE

Request without payload.

Examples:

And an example ScriptService:

POST

Request with payload.

Examples:

And an example ScriptService:

PUT

Request with payload.

Examples:

And an example ScriptService:

PATCH

Request with payload.

Examples:

And an example ScriptService:

Eximee Designer

API hints have been provided in the Eximee Designer.

Figure 1. Hints for GET / POST / PUT / DELETE requests.
Figure 2. Description of the hint for a specific request (GET).
Figure 3. View after automatically inserting code from the hint.

And hints for possible serviceId values to use at the current moment. If there is a problem fetching the current list of serviceId values, the editor continues to work, but does not provide information about any serviceId.

Figure 4. serviceId hint outside the characters: ' and "
Figure 5. serviceId hint limited by the character: "

Examples

"demo_api_RestTest" - executing requests with different parameters

"demo_api_exchangeRate_404" - exception handling

"demo_api_exchangeRate_validator" - an example validator calling an external service

API testing (Postman)

Postman is a tool for testing and working with APIs that makes it easy to send HTTP requests (e.g. GET, POST) and analyze server responses. (https://www.postman.com/)

Last updated

Was this helpful?