Table of Contents |
---|
References
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
RESTful API Design Specification
Issues and Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | How will hostname and port be provided when DMI-Plugin dmiPlugin register itself and its list of cmHandles with NCMP | The team thinks that the information should instead be provided in the form of a ‘host-name’ and a ‘port’ (there was some debate on service-name v. host-name but it was settled on host-name) e.g. "dmi-plugindmiPlugin" : { <host-name>, <port> } Where the host-name is unique. (the DB might assign an internal unique ID for each entry but that is just for indexing and x-referencing in a relation DB and this ID is not to be used/ exposed externally) | Instead of using ‘host-names’ and ‘ports’ parameters between java applications when in the cloud all we need is ‘service-names’ . The mapping of service-names to hosts and ports is done as part of the cloud configuration, in our case Kubernetes. And these are dynamic! The client application can then use a simple dns-lookup to connect to an instance of the service. Using service names also allows any plugin to use implement scaling as they see fit e.g. partitioning |
DMI URI
DMI URI format to follow below pattern Sandeep Shah
<OP>dmi/<v{v-number}>/ch/<cm-handle>/<data|operations|dmi-action>/ds/{datastore}/[rp:]<resource-path>?<query>
...
2 | Additional information in request body duplicates cmHandleId this is redundant information | Suggested to remove from request body to avoid possible error scenarios. | Only the one with the additionalInformation is needed and remove body |
3 | No need for Sync method, this is basic standard read operation at the root level for that cmHandle | ||
4 | Use include 'location' property when request yang-module sources | Suggestion: do include it in the request but allow dmiPlugin to decide to use it or now. Location (this leaf is called schema in older RFC7895) is not mandatory to support in YANG library and nodes may not include it. Another alternative presumably used also by ODL itself is the <get-schema> RPC. The key difference is that the YANG module definition is sent directly over the NETCONF channel, not requiring separate file servers and clients. So this is maybe one more reason that the ONAP DMI plugin currently doesn’t need the location attribute. | Location is not needed for any plugin and could only lead to ambiguity therefore will NOT be included in this request |
5 | Inconsistent use of "Operation" and/or HTTP Methods to distinguish write operations | Currently this page proposes to use "Operation=update" request body parameter for restconf "Replace" and "Patch" operations and use the HTTP (RESTFul) operation to distinguish between them. It also proposes to use PUT HTTP for Read and Delete operations | Proposal Toine: For Consistent (restful) design I would suggest to think as the operation to DMI-Plugin (always with body) as "creating a new order to do something" toward DMI-Plugin. Ie always a HTTP POST (or PUT?) operation. The "operation " in the body can simple be extended to include both "update" and "patch" as required. If the 'operation' is NOT supplied "read" wil be assumed as the default operation See also CPS-NCMP - DMI - SDNC Request and Response Mapping Proposal agreed by stakeholders in meeting
|
DMI URI
Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from
- Gerrit Source
- Read-the-docs: https://docs.onap.org/projects/onap-cps-ncmp-dmi-plugin/en/latest/design.html
DMI URI format to follow below pattern
<OP>dmi/<v{vNumber}>/ch/<cmHandle>/<data|operations|dmiAction>/ds/<datastore>/[rp:]<resourcePath>?<query>
URI | Mandatory or Optional | Description |
---|---|---|
<OP> | mandatory | the HTTP method |
dmi | mandatory | the dmi root resource |
<v{vNumber}> | mandatory | version of the dmi interface is the target resource URI is the query parameter list |
<cmHandle> | mandatory | unique (string) identifier of a yang tree instance. |
<data|operations|dmiAction> | mandatory | yang data, rpc operation or a (non-modeled) dmi action |
{datastore} | mandatory | mandatory datastore |
<resourcePath> | optional | the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself. |
<query> | optional | the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI |
NCPS-NCMP - DMI Plugin Write Request Flow
See CPS-NCMP - DMI - SDNC Request and Response Mapping
Datastore
If the cmhandle metadata indicates that data is not synched in CPS then the request is forwarded to the dmiPlugin
RESTCONF/NETCONF relationship
Excerpt | |||||||
---|---|---|---|---|---|---|---|
Request Format for Data Access
|
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from
|
Datastore
If datastore (ds/{datastore}) is not included in the URL then the request is defaulted to ncmp-datastore:running/operational.
If the cmhandle metadata indicates that data is not synched in CPS then the request is forwarded to the dmi-plugin
RESTCONF/NETCONF relationship
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8 | Read data resources with specified fields under a given data resource for a given cmHandle | PUT | {dmi-root}/dmi/v1/ch/<cm-handle> | operational/data/ds/ncmp-datastore: | resource-identifier}?fields={fields-expression}running/{
see example 12 CPS-391Spike: Define and Agree NCMP REST Interface#RESTAPI | 9 | Get data resource with 'fileds' for a cmhandle with a given scope condition | PUT | parentDataResourceIdentifier} { Content-Type: application/json "data" payload : yang-data+json 2 | Delete a data resource for a cmHandle | PUT | {dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:running/{resourceIdentifier} | 3 | Patch a data resource for a cmHandle | PATCH | {dmiRoot {dmi-root}/dmi/v1/ch/ {cm-handle}<cmHandle>/data/ds/ncmp-datastore: operationalrunning/{ resourcepathresourceIdentifier} ?fields={fields}&scope={scope}see example 2 CPS-391Spike: Define and Agree NCMP REST Interface#RESTAPI | 10 | Read descendant nodes to a given depth for a given cmHandle | PUT | {dmi-root}/dmi/v1/ch/{cm-handle}/data/ds/ncmp-datastore:operational/{resource-identifier}?depth={level}
{ Content-Type: application/json "data" payload : yang-data+json 4 | Patch multiple child resources for a single cmHandle | PATCH | {dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/<dsName>/{resourceIdentifier} Content-Type: application/json "data" payload : yang-patch+json 5 | Execute a yang action on a cmhandle instance | POST | {dmiRoot}/dmi/v1/ch/<cmHandle>/ see example 12 CPS-391Spike: Define and Agree NCMP REST Interface#RESTAPI | 11 | Replace data for a CMHandle | PUT | {dmi-root}/dmi/v1/ch/<cm-handle>/data/ds/ncmp-datastore:runningoperational/{resourceIdentifier}/{resource-identifieraction}{data input: { }} see example 12 CPS-391Spike: Define and Agree NCMP REST Interface#RESTAPI | "param1Name" :"param1Value”, } Note : If the "action" statement has no "input" section, the request message MUST NOT include a message-body 6 | Execute an rpc operation | POST | {dmiRoot}/dmi/v1/operations/ch/<cmHandle>/ds/ncmp-datastore:operational/ {module-name}:{action} { input: { Note: If there is no "input" section, the request MUST NOT include a message-body 7 | Read a filtered set of data under a data resource for a cmHandle | PUT | {dmiroot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:operational/{resourceIdentifier}?fields={fields-expression}
8 | Read data resources with specified fields under a given data resource for a given cmHandle | PUT | {dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:operational/{resourceIdentifier}?fields={fields-expression}
9 | Get data resource with 'fileds' for a cmhandle with a given scope condition | PUT | {dmiRoot}/dmi/v1/ch/{cmHandle}/data/ds/ncmp-datastore:operational/{resourcepath}?fields={fields}&scope={scope} | 10 | Read descendant nodes to a given depth for a given cmHandle | PUT | {dmiRoot}/dmi/v1/ch/{cmHandle}/data/ds/ncmp-datastore:operational/{resourceIdentifier}?depth={level}
11 | Replace data for a CMHandle | PUT | {dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:running/{resourceIdentifier} {data : { .... the complete tree config to be replaced }} |
DMI Inventory, Model & Data Sync API
View file | ||||
---|---|---|---|---|
|
Expand | |||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||
Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from
*For response output, where applicable the yang-library format and conventions are used 'as is' or extended
| |||||||||||||||||||||||||||||||||||||||||||
Expand | |||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
# | Use Case | Rest Method | Service | URI | Example | 1 | DMI notifies NCMP of new , deleted or changed cmhandles DMI Plugin NCMP. Including initial registration | POST json attributes:
| NCMP | {ncmp-root}/ncmp/v1/ch/ | Scenario : DMI notifies NCMP of new cmhandles2 | Get all the registered cmhandles for a given plugin | GET | NCMP | {ncmp-root}/ncmp/v1/dmi-plugins/{plugin-id}/ch | Scenario : Get all cmhandles from NCMP for a given dmi-plugin. May be used3 | Get model (schema set) for cmhandle | GET | DMI-Plugin | {ncmp-root}/ncmp/v1/dmi-plugins/{plugin-id}/ch/<cm-handle>/schema-sets/{schema-set-name} | Scenario : NCMP requests a list of modules for a cmhandle|||||||||||||||||||||||
4 | Get yang module for list of modules | POST | DMI-Plugin | {dmi-root}/dmi/v1/model/ch/<cmhandle> | Body : { [ "org:onap:cps:test:store:2020-12-09??", "org:onap:cps:test:bookstore" ] } | ||||||||||||||||||||||||||||||||||||||
Expand | |||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Use Case | Rest Method | URI | Example | 1 | Get model (module set) for cmhandles | PUT | {dmi-root}/dmi/v1/model/ch/<cm-handle> Scenario: Get the model data for a given cmhandle Method: PUT URI : {dmi-root}/dmi/v1/model/ch/cmhandle-001?fields=ietf-yang-library:modules-set Header : Body : {"operation" : "read", "cmhandle" : "cmhandle-001", "additionalProperties" : [ "target" : "sample-target", "subSystem" : "subSystem-001" ] } |
...
References
Follow principles/patterns of RESTCONF RFC-8040 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of yang-patch RFC-8072 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of RESTCONF NMDA RFC-8527 https://datatracker.ietf.org/doc/html/rfc8527
...