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:
- Should follow ONAP or wider best practice
- Documented on ONAP Wiki
- Discussed and agreed within CPS Team
- Discussed and agreed with wider community
Currently we are considering 3 'separated' Java APIs or 'groups' of methods:
- Models (add, list)
- Data (CRUD)
- Queries
Jira Ticket:
- CCSDK-2871Getting issue details... STATUS
Jira Backlog:
External Resources
https://wiki.onap.org/display/DW/Data+Representation
https://wiki.onap.org/display/DW/Interface+style
Open Issues/Decisions
# | Description | Details | Decisions |
---|---|---|---|
1 | Should the java interface take in one (JSON) objects(like REST interface) or a few individual fields in a signature? | ||
2 | Input streams or files? | ||
3 | API uses (generated) ID's or customer provided names | Using ID would mean client has to get/cache ID's all the time | |
4 | Should a user be able to override/delete a module? (of the same revision) |
CPS provides the following interfaces:
Interface Name | Interface Definition | Interface Capabilities | Consumed Models |
---|---|---|---|
Model Interface | Behavior interface that represents cps modules. |
| Yang models that are broken into fragments. |
Data Interface | Behavior interface that represents CPS data. |
| |
Query Interface | Provides the capability to query CPS data using XPaths. |
| |
Query Builder Interface | Provides the capability to query CPS data using restrictions from a query builder (see open issue 1). |