CPS-1177 Proposal for merging the endpoints of the datastore API

CPS-1177 Proposal for merging the endpoints of the datastore API



https://lf-onap.atlassian.net/browse/CPS-1177



Description/Scope

There are 3 datastore related endpoints exists on the proxy controller.

  1. /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-operational:

    •  $ref: 'ncmp.yml#/getResourceDataForPassthroughOperational'

  2.  /v1/ch/{cm-handle}/data/ds/ncmp-datastores:operational:

    •  $ref: 'ncmp.yml#/getResourceDataOperational'

  3.  /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running:

    •  $ref: 'ncmp.yml#/resourceDataForPassthroughRunning'

Parameters used by each endpoint

Endpoints/Params

datastoreName

cmHandleInPath

resourceIdentifierInQuery

optionsParamInQuery

topicParamInQuery



includeDescendantsOptionInQuery

Endpoints/Params

datastoreName

cmHandleInPath

resourceIdentifierInQuery

optionsParamInQuery

topicParamInQuery



includeDescendantsOptionInQuery

/v1/ch/{cm-handle}/data/ds/

ncmp-datastore:passthrough-operational



/v1/ch/{cm-handle}/data/ds/

ncmp-datastores:operational





/v1/ch/{cm-handle}/data/ds/

ncmp-datastore:passthrough-running





It would be better to have just one handling all the cases like /v1/ch/{cm-handle}/data/ds/{ncmp-datastore-name}

where {ncmp-datastore-name} can be set to ncmp-datastore:operational or ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running



Open questions

Question/Issue

Decision/Notes

Question/Issue

Decision/Notes

1

If want to have full backward compatibility than we will have ':' in the URL,

alternative way: just remove "ncmp-datastore:" prefix

Its not problem as it is more important to stay backward compatible



Proposed solutions

  1. Use just a switch to execute the appropriate function from the old functions

  2. Use Factory pattern alone

  3. Use Builder pattern to set config for the Factory (Thanks Andras for the idea)

  4. Make handler Builder (Solution will be proposed by Andras)



Advantages and Disadvantages of Proposed Solutions

Advantages and Disadvantages of the simple switch

Advantages

Disadvantages

Advantages

Disadvantages

Really easy to understand cos one can clearly see the switch and the original endpoint functions

Hard to see the common parts

Easy to maintain

If the parameters of any original function change you have to change the new one also



Not that elegant

Advantages and Disadvantages of the Factory Pattern

Advantages

Disadvantages

Advantages

Disadvantages

Easy to understand by look

It cannot be a classic Factory because of the common services and constants used in the logic of the handlers

All the business logic is abstracted away (switch and the handlers)

Factory has a constructor because of the common services and constants used in the logic of the handlers

The business logic of the handlers are in their own Handler class

Handlers has many parameters because of the different parameter list used by the original endpoints

Advantages and Disadvantages of the Builder Pattern and Factory used together

Advantages

Disadvantages

Advantages

Disadvantages

All the advantages of Factor pattern solution

All the disadvantages of Factor pattern solution

The user can clearly see which parameter has been set to which value on the constructor of the Factory

One more layer of abstraction

Advantages and Disadvantages of the Handler Builder

Advantages

Disadvantages

Advantages

Disadvantages

All the advantages of the Builder Pattern and Factory used together

All the disadvantages of the Builder Pattern and Factory used together

No factory is needed the handle function will be reused from the above

Not really a builder nor a Factory so maybe a bit hard to grasp at first

Decision & Rationale

The number 4 will be implemented which is mix of Builder and Factory