Withdraw of the 6.9.2 Release
Unfortunately, due to critical issues identified with version 6.9.2, we have decided to remove it and ensure it's no longer available for download. These issues impacted the ability to install or upgrade but none were security-related. We are diligently working to resolve these issues and are planning to release an updated version 6.9.3 in early May.
What if you've already upgraded?For customers who have already upgraded to 6.9.2, no immediate action is required, as none of these issues are security-related. Once it's available, you will still be able to upgrade to 6.9.3 as normal. We appreciate your patience and trust as we continue to enhance our software to better serve you. Thank you for your understanding.
Config - Request Format
URL: /rest/config/{object_type}
GET— list object type. Can pass in search attributes.POST— add a new object or a list of object type.PUT— create or update (based on unique keys) object or a list of objects.DELETE— delete a list of objects. Only implemented for host object type. Unimplemented for all other object types .
URL: /rest/config/{object_type}/{id}
GET— get object details.POST— clone this object with merged incoming data to create new object.PUT— update this object’s details.DELETE— delete object.
URL: /rest/config/{object_type}/exists?name={name}
GET— get object existential status.
Updating a single object Copied
When POST or PUTting a single object, the API expects a hash input with key value pairs. If successful, the API will return back the new serialised object.
All ref attributes are ignored when updating - the ref key is for clients that may want further information about the foreign object.
Updating a list of objects Copied
When POST or PUTting a list of objects, the API expects a hash with a key of list which is an array of hash objects. Each object will then be POST or PUT in turn.
If successful, the data returned will be of the format:
{
"objects_updated" : 3
}
There is an extra parameter that can be used:
synchronise— this means that any objects left after the individual PUTs will be deleted
The whole request is wrapped in a transaction. If there is a failure for any item, a rollback will occur and no changes will have been made to the system. The response will be:
{
message:"Rollback. Error trying to synchronise object: 2",
detail:"detail about the error",
objects_updated:0
}
Deleting a list of objects Copied
Example:
DELETE /rest/config/OBJECTTYPE?id=X&id=Y&id=Z
This expects a list of ids as parameters of the objects to delete. Will return a 400 error if no ids are specified (as it is dangerous to delete everything).
You can also use “s.id” as the parameter name, for consistency with the GET /rest/config/OBJECTTYPE REST API.
If you have a long list of ids which could potentially hit the URL query string length, you can use the x-tunneled-method to tunnel the DELETE verb inside a POST request and set body parameters with the id values.
On success, will return HTTP status 200 with:
{ "objects_deleted": X }
On failure to delete an object, the whole transaction will be rolled back and will return HTTP status 400 with the standard error and detail response:
{
"message": "Cannot delete as object still in use",
"detail": ....
}