You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #4447 (issue #3499) improves update request error responses to provide a more accurate information regarding full/partial success, including information in description about the exact items that are failing (e.g. whole entities, specific attributes in particular entities, etc).
See the modifications to orion-api.md in that PR to know how it works.
However, the current mechanism could be considered somehow complex and some simplifications has been proposed. In particular:
Return always the same response code, no matter if the operation was full successful, full failure or partial success/fail. That code would be 200 OK.
Include detail in the response payload about the result of the request. Note that currently we include that information in description (e.g. "description": "do not exist: E/T - [ C, D ], G/T [entity itself]") which is human oriented. A formal format (i.e. a JSON multi-level object) should be defined.
Backward compatibility considerations should be taken into account. For instance, existing clients current error processing logic probably is just checking the HTTP response code, so if code != 2xx they know there is an error. If know all times we return 200 OK, these clients will break.
The text was updated successfully, but these errors were encountered:
For instance, existing clients current error processing logic probably is just checking the HTTP response code, so if code != 2xx they know there is an error. If know all times we return 200 OK, these clients will break.
In that case, the client will need to inspect the response payload to know if an error occurs.
In some way, it remembers how NGSIv1 worked (in NGSIv1 200 OK was returned at HTTP level and the actual error was in the internal StatusCode in the payload)... and that's not good :)
fgalan
changed the title
Improve erquest error responses to provide better error reporting
Improve request error responses to provide better error reporting
Dec 13, 2023
PR #4447 (issue #3499) improves update request error responses to provide a more accurate information regarding full/partial success, including information in
description
about the exact items that are failing (e.g. whole entities, specific attributes in particular entities, etc).See the modifications to orion-api.md in that PR to know how it works.
However, the current mechanism could be considered somehow complex and some simplifications has been proposed. In particular:
description
(e.g."description": "do not exist: E/T - [ C, D ], G/T [entity itself]"
) which is human oriented. A formal format (i.e. a JSON multi-level object) should be defined.Backward compatibility considerations should be taken into account. For instance, existing clients current error processing logic probably is just checking the HTTP response code, so if code != 2xx they know there is an error. If know all times we return 200 OK, these clients will break.
The text was updated successfully, but these errors were encountered: