References

RESTful API Design Specification

Issues and Decisions

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 Basically a very confusing an unintuitive use of HTTP operations to distinguish ambiguous operations that instead easily could be defined by just using the 'operation' field in the request body.	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 09 Nov 2021  Only 'POST' method needs to be supported use term 'Update' instead of 'replace'

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>

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

Image Added

REST Data API

The DMI APIs for data access are similar to corresponding NCMP APIs. The following list is a summary of the main differences:

1. The URI prefix is /dmi instead of /ncmp.
2. For non-passthrough datastores, the resource path will be converted from cpsPath to RESTConfPath

3. The body for each request will contain additional information and any data provided on the NCMP interface (write operations) will be embedded in a larger JSON structure as described in example below.
   

4. Since all requests will have a message body, in some cases the HTTP method will be different to allow passing data. Thus POST can be used, the actual operation will be read from the body.

{
  “operation”: “<operation>”,         // Valid operations are: “create”, “read”, “update”, “patch” and “delete”.
                                      
  "dataType": "<dataType>", 

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

Image Removed

REST API

The examples in the below table refer back to the NCMP interface as the only difference is the  URI prefix /dmi instead of /ncmp

{dmi-root}/dmi/v1/ch/<cm-handle>/data/ds/ncmp-datastore:running/{resource-identifier}

Content-Type: application/json

"data" payload : yang-patch+json

{dmi-root}/dmi/v1/ch/<cm-handle>/data/ds/ncmp-datastore:operational/{resource-identifier}/{action}

input: {
         "param1Name" :"param1Value”,
          "param2Name" : "param2Value”

}

Note : If the "action" statement has no "input" section, the request message MUST NOT include a message-body

{dmiroot}/dmi/v1/ch/<cm-handle>/data/ds/ncmp-datastore:operational/{resource-identifier}?fields={fields-expression}