...
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 | Should system check which dmi-plugin 'owns' cm handle before deleting it? ie. is is the same service that registered the cm-handle |
| Just delete for now until Acces Control gets implemented |
Agreed with stakeholder in meeting | |
| 3 | Preferred output format |
Alternative B: only failed cm handles, no status code for each handle. Stakeholder expected that errors are rare and does not want to process data if successful ie. in most cases and empty response is expected (statuscode 200 code) | empty arrays will not appear in json at |
| all. I.e. if there are no 'failed delete cm handles' the 'failedDeletedCmHandles' property will simply not appear in the response. | |||
| 4 | Order of processing | Change to: delete → create → update | It will help us to handle the case where the user wants to recreate the cm handle |
Response Structure
HttpStatus
...