I noticed the following when calling the service. If I call the service with the responseBody containg
204: (A) a valid object path
(B) this is also the case if the attribute-name points to a non existent attribute
500: an invalid object path -> returns a 500, internal server error
(C) the object-path becomes invalid if the mountName and/or ltp is unknown
(D) and/or if the path in general is not known
See examples below.
Having a 500 for unknown mountName/ltp combination but having no error for an unknown attribute is kinda incosistent.
Also the error messages are not meaningful
Initially I expected to always get a 204, as long as the requestBody follows the correct format (i.e. independent of the actual attribute values).
Having an error response if the object-path is unknown might be reasonable
if we return an error response for that, the message should indicate why we got an error
but we possibly might need to differentiate between a path that's wrong because (a) there is no related API path and (b) because the MWDI doesn't have the device/ltp combination in it's cache
also we are currently aligning on error codes, so depending on the outcome we might need to change the error response code (this also may impact the error message; I could also image 400: Bad request could be a candidate).
The service returns inconsistent responses.
I noticed the following when calling the service. If I call the service with the responseBody containg
See examples below.
Examples:
Screenshots: