SlapOS is currently based on an API which relies on remote procedure calls in XML (XML-RPC). Although it is very reliable and can be used easily with slapos console, some users have been requesting a pure REST API.
This new API is now closer than ever to be released. It is based on a CRUD (Create Read Update Delete) approach similar to JIO. Rather than a procedural approach, the new SLAP API is content-based. A user creates content (ex. a compute node registration) and tracks the progress of the registration process by looking up how the original content evolves with new properties added as part of this process.
The procedural XML-RPC API of SlapOS has mostly been translated into content-based API:
β Done, β Not Done,π Not used and not planned
| SlapTool Action (XMP-RPC API) |
REST API side |
REST API Portal Type |
API Tested |
Client Side |
Client Tested |
| softwareReleaseError |
β PUT |
Software Installation |
β |
β |
β |
| availableSoftwareRelease |
β PUT |
Software Installation |
β |
β |
β |
| buildingSoftwareRelease |
β PUT |
Software Installation |
β |
β |
β |
| destroyedSoftwareRelease |
β PUT |
Software Installation |
β |
β |
β |
| supplySupply |
β POST |
Software Installation |
β |
β |
β |
| requestComputer |
π |
|
|
|
|
| getFullComputerInformation |
β |
|
β |
β |
β |
| useComputer |
β |
|
β |
β |
β |
| loadComputerConfigurationFromXML |
β PUT |
Compute Node |
β |
β |
β |
| computerBang |
β PUT |
Compute Node |
β |
β |
β |
| getComputerStatus |
π |
|
π |
π |
π |
| revokeComputerCertificate |
π |
|
π |
π |
π |
| generateComputerCertificate |
π |
|
π |
π |
π |
| destroyedComputerPartition |
β PUT |
Software Instance |
β |
β |
β |
| startedComputerPartition |
β PUT |
Software Instance |
β |
β |
β |
| stoppedComputerPartition |
β PUT |
Software Instance |
β |
β |
β |
| softwareInstanceError |
β PUT |
Software Instance |
β |
β |
β |
| softwareInstanceBang |
β PUT |
Software Instance |
β |
β |
β |
| softwareInstanceRename |
β PUT |
Software Instance |
β |
β |
β |
| setComputerPartitionConnectionXml |
β PUT |
Software Instance |
β |
π |
π |
| getInstanceParameterDict |
β GET |
Software Instance |
β |
β |
β |
| getComputerPartitionCertificate |
β GET |
Software Instance |
β |
β |
β |
| getComputerPartitionStatus |
π |
|
|
π |
π |
| getHostingSubscriptionIpList |
β |
|
β |
β |
β |
| updateComputerPartitionRelatedInstanceList |
PUT β |
Software Instance |
β |
β |
β |
| registerComputerPartition |
β POST |
Software Instance |
β |
|
|
| getSoftwareReleaseListFromSoftwareProduct |
N/A |
N/A |
N/A |
N/A |
N/A |
As we can observe, only three types of contents (Compute Node, Software Installation and Software Instance) are sufficient to describe the whole process of managing a distributed architecture such as a cloud platform, an edge platform or a vRAN. A fourth portal type (Software Product) might be necessary to cover service catalogs and support introspection on software release (ex. equivalence). This remains to be discussed though since it could also be implemented as part of Software Instance additional properties.
The new API is now fully tested with automated tests (see also here and here).
Moving from procedural API to content-based API was actually a challenge posing certains risks and uncertainties. The current state of the ongoing implementation demonstrates that content-based API works well and can actually simplify a lot the description of the SLAP protocol. Content-based API might also simplify disaster recovery procedure whenever a single instance has to handle millions of shared instances (ex. CDN, SDN, etc.). This topic will be discussed in future blog.