Fully Open Edge Cloud

A new test suite for SlapOS REST API

SlapOS new REST API is now validated by a complete test suite which demonstrates the relevance of a content-based approach.
  • Last Update:2023-12-22
  • Version:001
  • Language:en

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.