REST stands for Representational State Transfer and provides an interface for configuration, status query and execution of manual actions of the router via HTTP and HTTPS protocol.
The following commands (HTTP methods) are available for editing the resources (parameters or entries):
Documentation of the REST API
The REST API (programming interface) is documented in a JSON file according to the OpenAPI specification 3.0. The file can be downloaded in the Administration menu on the REST interface page. It contains all commands that are available in the various configurationen and equipment variants of the router. Not all contained commands are supported by your router.
The syntax of the available commands can easy be determined using the REST API documentation file by opening it with an OpenAPI tool, such as Swagger or Postman.
See the Command reference page for this.
Activating the REST interface
Before an access to the REST interface of the router via HTTP or HTTPS is possible, this must be configured accordingly in the Administration menu on the REST interface page. For this, access via HTTP and/or HTTPS must be activated and, if the firewall is active, an appropriate exceptional rule must be present and active. The standard ports (9090 for HTTP and 9091 for HTTPS) can be adjusted. The unencrypted HTTP protocol should only be used, if the connection is encrypted otherwise, e.g. using a VPN.
Addressing takes place using the IP address of the router, the port for REST access and the path to the parameters.
The path to the parameters is also structured in sections here as in the CLI.
Addressing for the parameters of the REST interface in a router with the IP address 192.168.1.10 and the HTTPS port is for example:
All REST commands are responced with HTTP status codes. The following codes are returned for the parameters described here to indicate a successful transmission of the REST command:
The commands (HTTP methods) GET, POST, PUT and DELETE are available for reading out or modifying the configuration. For configuration parameters, the path always starts with /configuration/.
Reading out parameters (GET)
Parameters are read out using the HTTP method GET.
Example for reading out the parameters of the REST interface:
All parameters with their settings are returned in JSON format as response:
The first section of the response references the profile, the second the configuration with the individual parameters.
Specifying the profile in the GET command
Without a specification, the GET command will always refer to the running profile. If the parameters of another profile are to be read out, the command must be complemented by the specification of the name of the profile.
Example for reading out the users of profile "Profile_2":
All users of profile "Profile_2" are returned in JSON format as response:
Filtering a list in the GET command
In case of a list, the GET command will return all entries. In order to see only the desired entries in the response, the command can be passed with a filter. The parameter that is to be filtered, an operator for the filter function and the desired value of the parameter are specified in a JSON array for the filter:
The parameter is one of the configuration parameters in the list entry.
Example for outputting all users with the "Read" right:
All parameters of all users with the "Read" right are returned in JSON format as response:
Multiple filters are also possible. Then, all filters will be combined using a logical AND, i.e. all filter criteria must be met that an entry will be displayed.
Example for outputting all users with the "Read" right and the string "ic" in the user name:
Querying the number of list entries using the GET command
In order to query the number of entries of a list, the command will be complemented by the parameter return_size; here, it is important to pass a value with the parameter whose figure is not important.
Example for outputting the number of existing users:
The number of users is returned in JSON format as response:
If a filter is handed over with this, only the number of list entries will be put out that meet the filter criteria.
Example for outputting the number of existing users with the "Read" right and the string "ic" in the user name:
Adding parameters (POST)
The HTTP method POST is used to add entries to lists. The entry must not have a list index for this since the entry will be appended to the end of the list.
Example for adding the new user "newuser" with read rights to the profile "Profile" and simultaneous activation of the modified profile:
Above example adds the new user to the profile "Profile". The parameter "name": "Profile" specifies the profile to which the modifications are applied. If it will be left out, the user will be added to the running profile. The parameter "activate": "1" activates the modified profile. If it will be left out, the profile will only be modified. but not activated. If modifications are only to be applied to the running profile and this shall not be activated, the complete profile section can be left out.
Some router functions require lists within lists.
Example for adding a new interface "net3" with a connection check interval of 13 minutes and the fall-back WAN chain "wan2" to the WAN chain "wan1":
Modifying parameters (PUT)
The HTTP method PUT is used to modify existing entries in lists.
Example for modifying the user name of the user "user2" to "newuser" and the rights to read/write::
The list identifier, here the parameter "index" is imperative for specifying the entry to be modified.
Deleting parameters (DELETE)
The HTTP method DELETE is used to delete complete lists or existing entries from lists. If no filters are used, all entries will be deleted. Filters permit a selective deletion of certain entries.
Example for deleting all host names:
Example for deleting all users with the string "test" in the user name from the profile "Profile_2":
Example for deleting all WAN interfaces:
Example for deleting the interface "group2" from the WAN chains:
The command (HTTP method) GET is available for querying status information. For querying status information, the path always starts with /status/.
Example for reading out the current values of the device info:
All parameters with their values are returned in JSON format as response:
The command (HTTP method) GET is available for displaying log files and profiles. For displaying log files and profiles, the path always starts with /download/.
An overview of all log files stored in the router is returned by a GET call of the log file list:
A log file is displayed by the GET call of the respective file:
2018-04-19 07:44:46 [configd] Started
An overview of all profiles stored in the router is returned by a GET call of the profile list:
A profile is displayed by the GET call of the respective profile:
The command (HTTP method) POST is available for debugging and triggering manual actions. For debugging and triggering manual actions, the path always starts with /operation/.
It is possible to execute manual actions for debugging purposes.
Example for the manual dispatch of the message "message1":
Example for the manual activation of the Info LED:
See this example for the proceeding to determine the command syntax
The following cURL command can be used to read the configuration of the REST interface in the Administration menu for example:
In order to determine the cURL syntax, refer to the Command reference page and the Configuration Guide linked there.
Tip: In case of problems with the cURL syntax, it might be helpful to use the option '-v' (verbose) to facilitate troubleshooting: