...
| # | Existing Endpoint | Updated Endpoint | Path/Query Parameters | Response Codes | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | GET-/v2/dataspaces/{dataspace-name}/anchors/{anchor-name}/deltaAnchors | GET-/v2/dataspaces/{dataspace-name}/anchors/{source-anchor-name}/delta |
|
| ||||||||||||||||||||||||
| 2 | POST- /v2/dataspaces/{dataspace-name}/anchors/{anchor-name}/deltaPayload | POST- /v2/dataspaces/{dataspace-name}/anchors/{source-anchor-name}/delta |
|
Changes and Justification for going
...
with second approach
The second proposed approach is best suited for the scenario, but there are a few minor changes to it:
...
- we have two different ways to generate delta, so we can say the final operation is common that is "delta". So, the idea is to have the common components between the operations as path parameters, i.e dataspace name and first anchor name
- remaining components should be in query, that is target anchor name, and fetch descendants' option in first operation and JSON payload and schema in second operation.
- this approach is also consistent with existing CPS API's such as list-node APIs where a singular endpoint performs different operations while having similar parameters