The endpoints in the v1 REST API allow the client to query, list, and modify different resources in the system. This article contains the basic usage of the v1 REST API endpoint.
| Table of Contents |
|---|
URL structure
The endpoints can be reached in the following URL structure:
| Code Block |
|---|
https://{vcf_mr_domain}/verba/restapi/v1/{resource_plural}/{id}?{query_parameters} |
The different resources like users , and storage targets can be reached by dedicated endpoints. These endpoints allow to list entities of a resource. To reach a specific entity of the resource the ID must be placed in the URL too.
In some scenarios, the request requires to add additional query parameters to modify the response.
The resource endpoints usually have options endpoints too. These endpoints list dynamic values that are relevant to the usage of the specific resource endpoint. The URL structure of the option endpoints is the following:
| Code Block |
|---|
https://{vcf_mr_domain}/verba/restapi/v1/{resource_singular}Options/{option_method} |
URL parameter | Description | Example |
|---|---|---|
vcf_mr_domain | Domain or the IP address of the VFC MR or Combo server installation, where the VFC Web Application can be reached | “localhost” |
resource_plural | Name of the resource type in plural form | For the user resource: “users” |
resource_singular | Name of the resource type in singular form | For the user resource: “user” |
id | The uni |
HTTP Method
On the same resource, different actions can be achieved with different HTTP methods if applicable. The actions are collected in the following table.
Method | Action description |
|---|---|
GET | Retrieve one ore or more resources. |
POST | Send sensitive data to trigger a new events such as create creating a new resource, validate passwordvalidating passwords, etc. |
PUT | Update a specific entity. As a payload a full object is necessary. |
PATCH | Update a specific entity. As a payload, a partial object is enough. |
DELETE | Delete specific entityentities. |
Authentication
To use the REST API endpoints the client has to authenticate themselves. With the Authentication endpoint access token and refresh token can be generated. The protected endpoints can be used with the access token.
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
In the case of a multitenant system, the generated access token is only valid for a certain tenant. By default, the token is valid only for the authenticated user’s tenant. But if the client user is in the reference tenant, then they are able to can specify another tenant during the token generation with the “targetEid” property. In this case, the “eid” property should be left out from the requestmust be “0000”. |
Access token generation with credential
Request
| Code Block |
|---|
POST https://{vcf_mr_domain}/verba/restapi/v1/auth/token
{
"client_id": "user_login",
"client_secret": "secret_plain_password",
"eid": "user_own_tenant"
} |
...
The access token has an expiration, that is specified in the response too. That access token can be used to use the other endpoints. The refresh token has no expiration, it can be stored. The refresh token allows to generate the generation of a new access token without user credentials.
Access token generation with a refresh token
| Code Block |
|---|
POST https://{vcf_mr_domain}/verba/restapi/v1/auth/token
{
"client_id": "user_login",
"refresh_token": "mE07g3HZkoSaqkysDZLC6B3JA0stEiUz0maA9fu1GhblAQc3"
} |
Access token usage
The generated access token is a bearer token. The token must be placed in the Authorization header.
| Code Block |
|---|
GET https://{vcf_mr_domain}/verba/restapi/v1/users
Authorization: Bearer fL9QPL2U667bBpitMFhtNIn2kLHC15WB |
Query parameters
The listing endpoints allow to influence influencing the response list with different query parameters. The following section covers the different action actions that are available with the query parameters.
Pagination
The listing endpoints uses a use server-side pagination. The page size can be modified with the “limit” query parameter. In case of the result set resultset would contain more entities than the page side a “nextPageToken” property is represented in the response. That token can be used to navigate to the next page. If there isn’t a “nextPageToken” property in the response, then there are no more entities.
...
With the following request, the page size is maximized in 2 entities. If there is any more entity in the system that could be listed then a those can be accessed on a the next page.
| Code Block |
|---|
GET https://{vcf_mr_domain}/verba/restapi/v1/users?limit=2 |
...
| Code Block |
|---|
{
"nextPageToken": "4ifAzqxn7aI3UdCMzngVWE92NFQ",
"list": [
{
"id": 1348,
"name": "Test user 1",
"login": "test_user_1",
"email": "test_user_1@verba.com"
},
{
"id": 1590,
"name": "Test user 2",
"login": "test_user_2",
"email": "test_user_2@verba.com"
}
]
} |
In the response, the next page token is represented, that which means there are other users that can be listed. So, a next request in is necessary.
Request for 2nd page
...
| Code Block |
|---|
{
"list": [
{
"id": 1595,
"name": "Test user 3",
"login": "test_user_3",
"email": "test_user_3@verba.com"
}
]
} |
In the response, there is no next page token, so there is no more page to display, and no more request is needed.
Filtering
With the “filters” query parameter filtering criteria list can be set to reduce the result list for certain entities. The filters are in a JSON structure which is shown below. If there are multiple filtering criteria, the system links them with the logical AND operator.
| Code Block | ||
|---|---|---|
| ||
{
"filtersList": [
{
"field": "login",
"operator": "STARTS_WITH",
"values": ["john"]
},
{
"field": "id",
"operator": "GREATER_THAN_OR_EQUAL",
"values": [100]
}
]
} |
The example above can be used to search for user entities whose “login” property starts with “john” and whose “id” property is greater or equal to 100.
| Info |
|---|
Not necessarily every property of an entity can be used for filtering. Also, the available operators may be different for the different types of properties. |
The supported properties for filtering can be retrieved from a specific endpoint. Every resource type has its own “options” endpoints. The naming convention of that endpoints follows the structure: /v1/{resource_singular}Options/getAllowedFilters
The following example lists the allowed filtering properties and their allowed operators for user entities.
Request
| Code Block |
|---|
GET https://{vcf_mr_domain}/verba/restapi/v1/userOptions/getAllowedFilters |
Response
| Code Block |
|---|
[
{
"operators": [
"EQUAL",
"NOT_EQUAL",
"GREATER_THAN",
"GREATER_THAN_OR_EQUAL",
"LESS_THAN",
"LESS_THAN_OR_EQUAL",
"CONTAINS",
"ENDS_WITH",
"STARTS_WITH",
"LIKE",
"BETWEEN",
"IN",
"NOT_IN"
],
"paramName": "login"
},
{
"operators": [
"EQUAL",
"NOT_EQUAL",
"GREATER_THAN",
"GREATER_THAN_OR_EQUAL",
"LESS_THAN",
"LESS_THAN_OR_EQUAL",
"BETWEEN",
"IN",
"NOT_IN"
],
"paramName": "id"
}
] |
Sorting
The order of entities in the list response can be modified with the “sortBy“ and the “sortOrder“ query parameters. The allowed values of the “sortOrder” parameter are “asc” for ascending and “desc” for descending order.
| Info |
|---|
Not necessarily every property of an entity can be used for sorting. |
The supported properties for sorting can be retrieved from a specific endpoint. Every resource type has its own “options” endpoints. The naming convention of that endpoints follows the structure: /v1/{resource_singular}Options/getSortableFields
The following example lists the allowed sorting properties for user entities.
Request
| Code Block |
|---|
GET https://{vcf_mr_domain}/verba/restapi/v1/userOptions/getSortableFields |
Response
| Code Block |
|---|
[
"login",
"id"
] |