...
Style and payload structure
Pending decisions: Data Representation and Interface style
REST payload structure
Java payload structure
Access methods
Name | Description | Parameters | Return |
---|---|---|---|
Add model | Add a YANG model to the CPS so that compliant data may be stored & retrieved |
| Some identifier |
Remove model | Mark a model for removal, and remove when no data remains that relies on the model |
| Success/Number of model instances still using model |
Upgrade model | T.B.D |
| - |
Create model instance | Prepare the underlying DB for the storage of data compliant to the model. |
| Model instance identifier |
Delete model instance | Remove the data and any artifacts from the underlying DB |
| Success/Failure |
Create data | [Validate &] Store data compliant to a model |
| Success/Failure |
Replace data | [Validate &] Store data compliant to a model in place of existing data |
| Success/Failure |
Update data | [Validate &] Update data that is (1) compliant to a model and (2) already stored |
| Success/Failure |
Delete data | Remove data from a model instance |
| Success/Failure |
Behavior
T.B.D.: Eventual consistency; Data integrity guarantees; Fast failure; Progress; Cancellation;
REST
Will be specified as part of the PoC execution, and updated/referenced from here
Java
Will be specified as part of the PoC execution, and updated/referenced from here