Table of Contents |
---|
Jira | ||||||
---|---|---|---|---|---|---|
|
Description/Scope
There are 3 datastore related endpoints exists on the proxy controller.
- /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-operational:
- $ref: 'ncmp.yml#/getResourceDataForPassthroughOperational'
- /v1/ch/{cm-handle}/data/ds/ncmp-datastores:operational:
- $ref: 'ncmp.yml#/getResourceDataOperational'
- /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 |
---|---|---|---|---|---|---|
/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 |
Info |
---|
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 |
---|---|---|
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
Use just a switch to execute the appropriate function from the old functions
Use Factory pattern alone
Use Builder pattern to
make a theset config for the Factory (Thanks Andras for the idea)
Make handler Builder (Solution will be proposed by Andras)
Advantages and Disadvantages of Proposed Solutions
...
Advantages | Disadvantages | ||
---|---|---|---|
Really easy to understand cos one can clearly see the switch and the original interface endpoint functions | All the logic will be present in the switch | 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 | Hard to maintain and expand | Hard to see the common parts |
Advantages and Disadvantages of the Factory Pattern
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 | ||
---|---|---|---|
All the advantages of Factor pattern solution | All the disadvantages of Factor pattern solution | Like above | Like above |
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 |
---|---|
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