Resources
Assumptions
| # | Description |
|---|---|
| 1 | Yang namespaces are globally unique (except for multiple revisions) |
Open Issues/Decisions
API definitions
| Group | # | Operation | Payload | Description |
|---|---|---|---|---|
Modelling storage | 1 | PUT /module/{dataspace} | File | Create/Update (and validate) a module set. (upload a model file) |
| 2 | GET /module/ | Read all modules in the store. | ||
| 3 | GET /module/{namespace} (see assumption #1 and issue #1) | Read all modules in the store for the given namespace | ||
| 4 | GET /module/{namespace}/{revision} | Read all modules in the store for the given namespace and revision | ||
| 5 | GET /module/{dataspace} (see issue #1) | Read all modules in the store for the given dataspace | ||
Anchor Points persistence | 6 | PUT /anchor-point/ | Json Object | Create an anchor point given a name and a dataspace and module (namespace and revision) |
| 7 | GET /anchor-point/{dataspace}/{name}/ | Read an anchor point and the associated attributes given a name and a dataspace. | ||
| 8 | DELETE /anchor-point/{dataspace}/{name} | Delete an anchor point given a name and a dataspace. (will delete whole tree) | ||
| 9 | GET /anchor-point/{dataspace} (see isue#1) | Read all anchor points in the system given a dataspace. | ||
| 10 | GET /module/{dataspace}/{anchor-point}/ | Get a module (reference), given an anchor point | ||
| 11 | GET /anchor-point/fragment/{dataspace}/{xpath}/ | Get the anchor point of a fragment given a fragments xpath | ||
Fragment persistence | 12 | PUT /fragment/{dataspace}/{name}/ | File | Create a (root) fragment for a given anchor point, the fragment can have children. |
| 13 | PUT /fragment/{parent-fragment-id}/ | File | Create a fragment given an ID relative to the parent | |
| 14 | GET /fragment/{dataspace}/{name}/ | Get a fragment given a anchor point (return just one level with just xpath references to its children) | ||
| 15 | GET /fragment/{dataspace}/{xpath}/ (see isue#2) | Get a fragment given a Xpath expression | ||
| 16 | GET /fragments/{dataspace}/{anchor-point}/ | Get all the fragments under an anchor point given a anchor point (notice similarity with /fragment/{dataspace}/{anchor-point}/ (just one letter!) | ||
| 17 | GET /fragment/{dataspace}/schema-node-identifier/{schema-node-identifier}/ | Get all the relevant fragments given a schema node identifier (not need to specify dataspace is schema-node-identifier is globally unique) |
Some thoughts from Toine after discussion with Tony & Flavio
Two possible identifiers for 'anchor points'
- name = dataspace [ + anchor-name ] We will need some token to separate them e.g. |
- &name=xnfProxy
- &name=xnfProxy|nodeInAthlone
(we still have the issue of naming the parts in documentation and in error scenarios ie. if the 'dataspace' does not exist but maybe its OK to us that term then)
- uuid = unique id (generated by the DB). This wil eb useful to share an 'instance' with other applications without having to share dataspace name
- &uuid
Tony suggested to just use cps and nothing else to return yang data e..g.
GET <server>/cps/v1?name=xnfproxy&xpath="..." i'm a bit worried that this really looks strange and wrong from REST conventions but I can see why we cannot use the term 'fragment' as that is an application detail. The generic Yang term (as Mark suggested to use Yang terminology) I think is 'Node' or (yang-nodes to prevent confusion with teleccoms nodes)
GET <server>/cps/v1/nodes?name=xnfproxy&xpath="..."
GET <server>/cps/v1/nodes?name=xnfproxy|nodeInAthlone&xpath="..."
(the same can be used for PUT and DELETE operations)
If we also support getting trees (more then one level) I'm note sure if we need another url or another parameter
GET <server>/cps/v1/node-trees?name=xnfproxy&xpath="..."
GET <server>/cps/v1/nodes?name=xnfproxy&includeChildrenLevels=3&xpath="..."
getting modules seems straight-forward enough:
GET <server>/cps/v1/modules?name=xnfproxy
But not sure what do do to get all the anchor points, maybe
GET <server>/cps/v1/uuids?name=xnfproxy
GET <server>/cps/v1/names?name=xnfproxy