You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Resources

Assumptions

#Description
1Yang namespaces are globally unique (except for multiple revisions)

Open Issues/Decisions

#DescriptionDetailsDecisions
1How to differentiatie GET queries with different parameters. If we dont have named parameters how best to know what is meant

Alternatives

  1. GET /anchorpoint/dataspace/{dataspace} versus /anchor-point/name/{dataspace}
  2. GET /anchorpoint?dataspace={dataspace} versus /anchor-point?name={dataspace}
  3. GET /dataspace/{dataspace-id}/anchorpoint versus /anchor-point/{name}
  4. GET /dataspace/{dataspace-id}/anchorpoint versus /anchor-point/name/{name}
  5. GET /dataspace/{dataspace-id}/anchorpoint versus /name/{name}/anchor-point

GET cps/fragment/xnfProxy-left|AthloneNode?xpath="..."

GET cps/fragment/namedId=xnfProxy-left|*?xpath=a/b/c (DB has als uuid)

GET cps/uuid=123456789  (remove 'fragment') !

GET cps/nameId?dataspace="..."

xnfProxy-left|*?xpath=*/b/*/d

xnfProxy-right|AthloneNode?xpath=....

 [xnfProxy-left,xnfProxy-Right]/AthloneNode


2Advance queries v Simple Queries (gets) for data fragments. Do we want/need differentiatie on UTL?
  1. GET /fragment/query/{xpath}
  2. GET/fragment/{xpath}  
  3. GET /query/{xpath}

Note . The xpath could be a full unambiguous xpath returning one object or it could be partial path using wildcards etc allowing for more advanced queries return 0 or more fragments (developed over many iterations)


3We have no modules sets!model files just arbitrarily group a few modules, is there a need to persist this grouping (We do have the concept of a dataspace as well)

API definitions

Group#OperationPayloadDescription

Modelling storage

1PUT /module/{dataspace}FileCreate/Update (and validate) a module set. (upload a model file)
2GET /module/
Read all modules in the store.
3GET /module/{namespace} (see assumption #1 and issue #1)
Read all modules in the store for the given namespace
4GET /module/{namespace}/{revision}
Read all modules in the store for the given namespace and revision
5GET /module/{dataspace} (see issue #1)
Read all modules in the store for the given dataspace

Anchor Points persistence

6PUT /anchor-point/Json Object 

Create an anchor point given a name and a dataspace and module (namespace and revision)

7GET /anchor-point/{dataspace}/{name}/
Read an anchor point and the associated attributes given a name and a dataspace.
8DELETE /anchor-point/{dataspace}/{name}

Delete an anchor point given a name and a dataspace. (will delete whole tree)

9GET /anchor-point/{dataspace} (see isue#1)

Read all anchor points in the system given a dataspace.

10GET /module/{dataspace}/{anchor-point}/

Get a module (reference), given an anchor point 

11GET /anchor-point/fragment/{dataspace}/{xpath}/
Get the anchor point of a fragment given a fragments xpath

Fragment persistence

12PUT /fragment/{dataspace}/{name}/FileCreate a (root) fragment for a given anchor point, the fragment can have children.
13PUT /fragment/{parent-fragment-id}/FileCreate a fragment given an ID relative to the parent
14GET /fragment/{dataspace}/{name}/
Get a fragment given a anchor point (return just one level with just xpath references to its children)
15GET /fragment/{dataspace}/{xpath}/ (see isue#2)
Get a fragment given a Xpath expression 
16GET /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!)
17GET /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'

  1. name =  dataspace  [ + anchor-name ]      We will need some token to separate them e.g. |
    1. &name=xnfProxy
    2. &name=xnfProxy|nodeInAthlone
    3. &dataspace=xnfProxy&anchor-name=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)
  2. uuid = unique id (generated by the DB). This wil be useful to share an 'instance' with other applications without having to share dataspace name
    1. &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="..."

GET <server>/cps/v1/dataspaces/{dataspace_id}/anchors → returns Anchor-points

GET <server>/cps/v1/dataspaces/{dataspace_id}/anchors/{anchor-point-id}/nodes?xpath="..."  → returns Node(s)

GET <server>/cps/v1/dataspaces/{dataspace_id}/anchors/{anchor-point-id}/nodes?schemaNodeIdentifier="..."  → returns Node(s)


GET <server>/cps/v1/dataspaces/{dataspace_id}/nodes&xpath="..." → returns Node(s)

(the same can be used for PUT and DELETE operations)


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














  • No labels