...
NCMP CMhandle registration endpoint receives multiple operations to create, update or delete cm-handles in a single request. As there are multiple operations, the endpoint response structure should be able to provide the status of all operations separately with consistent error-code to allow users to retrigger failed operations programmatically if possible.
Questions:
| # | Question | Agreed Solution | Remarks |
|---|---|---|---|
| 1 | Are multiple operations for one cm-handle is considered invalid input? | No special validation, process as usual |
|
| 2 | shodul Should system check which plugin 'owns' cm handle before deleting it? | Toine Siebelink will check with Tony Finnerty | |
| 3 | Preferred output format | Team prefers alternative A; with 'status' field |
Response Structure
HttpStatus
...
The response body can be structured in two ways
Alternative A: Group by operation
...
type, with status fields
The interface is generic and if we need to send the status of all operations in the future it can be achieved without any breaking change.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"createdCmHandles": [
{
"cmHandle": "cmHandle-1",
"status": "FAILURE", // Extra field to indicate the status
"error-code": "01",
"error-text" : "cmhandle already exist"
}
],
"updatedCmHandles": [
{
"cmHandle": "cmHandle-2",
"status": "FAILURE" ,
"error-code": "02" ,
"error-text" : "cmhandle does not exist"
}
],
"faileddeletedCmHandles": [
{
"cmHandle": "cmHandle-3",
"status": "FAILURE" ,
"error-code": "02" ,
"error-text" : "cmhandle does not exist"
}
]
} |
Alternative B: Group by operation type but only for failed operations
This approach meets the current requirement and has a smaller payload size (no extra field for the status).
...