Open serpens24 opened 2 years ago
This issue is stale because it has been open for 6 months with no activity. Consider reviewing and taking an action on this issue.
This issue is stale because it has been open for 6 months with no activity. Consider reviewing and taking an action on this issue.
This issue is stale because it has been open for 6 months with no activity. Consider reviewing and taking an action on this issue.
Description
The current Response.java implementation in CoreUtilities\rest could do with an update/overhaul as it is potentially contributing to wider issues.
There is no clean handling of response parsing (in the constructor). This means that is JSON is expected (isJson == true) then if the endpoint returns non-Json - ugly exceptions are thrown as the returned payload is parsed.
To replicate this, modify a rest endpoint being connected to to an invalid URL and see the result. In my case I received a 404 Not Found error with the "bytes" returned being HTML to represent this - obviously this HTML block doesnt parse nicely to JSON.
It would be much neater to catch the invalid JSON, return the invalid response body in a logged error and let the caller decide how to proceede. In my case my calling app is looking for the return code and moving forward off of that, we should be able to handle a 404 coming back if an endpioint is down and report as such rather than an exception saying ot couldnt parse a "<" character in a string.
I also noted that the method isCodeSuccess is suggesting that not only are responses in the 200 range valid but also in the 400 range - this doesnt seem correct to me.
Speaking tio Arcturus there is probably a good argument to rework this class as it had resulted in multiple issues elsewhere, there may be better options out there or a rework can be designed to be cleaner in howe it handles -highly likely results from external endpoints.
Steps to Reproduce
Behaviour
As per description
Expected behaviour: Clean handling of interactions with external endpoints, with error reporting or logging that clearly identifies what is happening
Actual behaviour: Exceptions and stack traces that dont provide users with an understanding of the underlying problems - such as: the endpoint is not available, or the returned payload is not JSON etc
Reproduces how often: 100% under ewrror conditions mentioned above.
Additional Information