Replies: 1 comment 1 reply
-
|
@lampajr I think this is an important improvement for the API, especially as we integrate with an increasing number of systsems and tools. I think the areas that would need to improve would be;
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In the past days I spent some time analyzing how horreum client could manage API errors in a clean way, and I found out that it should be sufficient to describe error responses (along with the status codes) in the OpenAPI spec that we use to generate them.
Given that, I see two main issues:
200response, completely ignoring the other status codes like401or400, thus we should set them for all endpoints (maybe there is a way to set a default for every one?)text/plainas error response body and atm Horreum always return that type of content for errorsGiven the previous two issues, here my proposal:
statusCodeand anerrorMessageapplication/json, more coherence as regardless of the success or not of the request the result would be in the same formatServiceExceptionto set asentitythe new objIllegalArgumentExceptionor anyuncheckedone will be converted to the new custom error (I guess there is a way in Quarkus for that)horreum-apiendpoints to return the new schema error objI can provide a very minimal PoC in a pull request to showcase the proposal much more concretely.
Beta Was this translation helpful? Give feedback.
All reactions