Save, verify or restore a configuration

put

/rest/{version}/configuration/management

Executes configuration management action to either save, verify or restore a configuration. A restore can be executed from different sources, including a specified file in the /code/bkups directory. The client making the request must already possess the configuration lock or the request fail. This is an asynchronous request, that can take long enough the client must poll the system for the final result. If the request is received successfully, the immediate response to the client (202) simply indicates that the request was received and is being processed. The links section of the response includes the REST resource the client should use to poll for the final result.

Request

Path Parameters
  • REST API version string.
    Available values: v1.2
Query Parameters
  • Configuration management action.
    Available values: save, verify, restore
  • When the restoreSource parameter is "backupFile", this parameter must specify a valid backup file located in the /code/bkups directory. The value should be the filename only; specifying a path in the filename results in an error.
  • Only valid when action is "restore". Specifies the source of the configuration to be used for the restore.
    Available values: running, saved, backupFile
Header Parameters
  • The value in the Authorization header must be the string "Bearer {access token}", where {access token} is a valid, unexpired token received in response to a prior /rest/{version}/auth/token request.
Back to Top

Response

202 Response

The configuration management request was received successfully and is being processed.

400 Response

The request is malformed in some way or is missing required information and therefore cannot be processed.

401 Response

Unauthorized - Request lacks valid authentication credentials.

403 Response

This request requires the client credentials to have administrator privileges.

404 Response

Resource not found

423 Response

The request requires the configuration lock and failed because the client does not currently own the lock. If another client or user currently owns the configuration lock, the error message is "Resource locked by another user". If no client or user owns the configuration lock, the error message is "User does not have the lock".
Back to Top

Examples

Example of Accessing the API with cURL

The following example shows how to save, verify or restore a configuration by submitting a PUT request on the REST resource using cURL. For more information about cURL, see Use cURL.

curl -X PUT \
    --header "Accept: application/xml" \
    --header "Authorization: Bearer $TOKEN" \
    "https://${SBCIP}/rest/v1.1/configuration/management?action=verify"

Note:

If using 'action=restore', set 'restoreSource' to either 'running', 'saved', or 'backupFile'. And if you are restoring from a backup file, set the value of the 'filename' query parameter to the name of the backup file in the /code/bkups directory that you want to restore.

Example of Accessing the API with Python

The following example shows how to save, verify or restore a configuration by submitting a PUT request on the REST resource using Python. This example assumes you have a valid token stored in the token variable. For an example of authenticating with Python, see Authenticate.

import requests
headers = { "Accept":"application/xml", "Authorization":"Bearer " + token }
url  = "https://" + sbcip + "/rest/v1.1/configuration/management?action=verify"
resp = requests.put(url, headers=headers)

Example of the Response Headers

The following shows an example of the response headers.

HTTP/1.1 202
Server: nginx/1.14.1
Date: Wed, 01 Apr 2020 15:29:22 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive

Example of the Response Body

The following example shows the contents of the response body in XML format.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
  <data/>
  <messages/>
  <links>
    <link>https://${SBCIP}/rest/v1.1/admin/asyncstatus</link>
  </links>
</response>

After receiving that response, check the status of the asynchronus action by making a GET request to the /rest/v1.1/admin/asyncstatus endpoint.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
  <data>
    <operationState>
      <operation>verify</operation>
      <status>success</status>
    </operationState>
    <additionalInfo>
      <verifySummary numCriticals="0" numErrors="0" numWarnings="0"/>
    </additionalInfo>
  </data>
  <messages/>
  <links/>
</response>
Back to Top