Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 30 Next »

Introduction

Although the PoC will only implement a few of the possible Java API methods it is important to have a good detailed view of the structure and naming of this interface going forward and document it.

Acceptance Criteria for Proposed Java Interface:

  1. Should follow ONAP or wider best practice
  2. Documented on ONAP Wiki
  3. Discussed and agreed within CPS Team
  4. Discussed and agreed with wider community


Currently we are considering 3 'separated' Java APIs or 'groups' of methods:

  1. Models (add, list)
  2. Data (CRUD)
  3. Queries

Jira Ticket:

CCSDK-2871 - Getting issue details... STATUS

Jira Backlog:

https://jira.onap.org/secure/RapidBoard.jspa?rapidView=223&view=planning.nodetail&selectedIssue=CCSDK-2912&issueLimit=100

Gerrit Review

https://gerrit.nordix.org/#/c/onap/ccsdk/features/+/6477/

External Resources

https://wiki.onap.org/display/DW/Data+Representation

https://wiki.onap.org/display/DW/Interface+style


Open Issues/Decisions

#

Description

Details

Decisions

1Should the java interface take in one (JSON) objects(like REST interface) or a few individual fields in a signature? 

Mapping the request body to an object


2Input streams or files?Toine has a preference for input stream.

03/11/12 Team meeting Niamh, Toine, Rishi, Aditya, Bruno, Phillipee

We have decided to use input streams.

3

API uses (generated) ID's or customer provided names? If names are used should we return IDs at all?

03/11/12 Team meeting notes - Niamh, Toine, Rishi, Aditya, Bruno, Phillipee

  1. Using ID would mean client has to get/cache ID's all the time.
  2. The Java API follow the REST API. If the rest API is using names then the java API should also use names.
  3. Create methods should return the objects created. If the module already exists, an exception should be thrown.
  4. All ID's generated should be in the response. If we return the ID we also need methods to use the ID. If we update the java API to use ID, we should also update the rest API.
  5. Create methods should be void.

4Should a user be able to update/override/delete a dataspace, module, module set? (of the same revision)
  1. Business logic to check on create if it already exists. If it exists we do not create it.
  2. If the module already exists, an exception should be thrown.

CPS provides the following interfaces:

Interface Name

Interface Definition

 Interface Capabilities

Consumed Models

Model InterfaceBehavior interface that represents cps modules.
  1. Create a module set
  2. Add modules to a module set
  3. Read all modules
  4. Validate modules
  5. Upgrade a module set (individual module upgrade)
  6. Create a module set and validate it against a module reference (using a separate SPI)
Yang models that are broken into fragments.
Data Interface

Behavior interface that represents CPS data.

  1. Create a node under an anchor.
  2. Delete a dataspace
  3. Create a dataspace
  4. Create an anchor
  5. Read an anchor of a particular node
  6. Read an anchor in a namespace and dataspace
  7. Read all anchors for one dataspace
  8. Delete an anchor for a namespace in a dataspace
  9. Associate an anchor to a module set
  10. Associate an dataspace to a anchor
  11. Read all dataspaces
  12. Create a node under another node.
  13. Associate an a node to a anchor

Query InterfaceProvides the capability to query CPS data using XPaths.
  1. Read the parent of a node that matches an xpath expression
  2. Read all nodes under an anchor point
  3. Read the anchor of a node
  4. Read all nodes that match a schema node identifier

Query Builder InterfaceProvides the capability to query CPS data using restrictions from a query builder (see open issue 1).


  • No labels