-
Notifications
You must be signed in to change notification settings - Fork 478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vnd.error path attribute #546
Comments
Before adding anything, I'd like a more comprehensive discussion on why we need this one attribute vs. all the others, and what would be a good example of using them in code. |
What do you mean "all the others"? The path attribute is the only attribute that the vnd.error spec proposes that is not already in the VndErrors class. Obviously, it should be supported to comply with the spec. The utility of the attribute is to locate the field in question in the JSON. |
@gregturn any update on this? Path would allow a client to know which particular parts of a request caused the error e.g. which fields in the input failed validation. |
With my efforts to fix things up through #775, I have submitted blongden/vnd.error#23 (along with PR blongden/vnd.error#24) to improve the spec. While chewing through this, I have realized that Spring HATEOAS lacks a cohesive error handling strategy. |
Thanks for the response. It seems like the draft spec hasn't been touched since 2014. I wonder if it's something spring should fork and take over? I'd consider a few more changes for consistency in that spec if it was up to me too. The response structure differs quite a bit depending on the amount/type of errors, I think it would be nicer if it was consistent e.g. returned _embedded.errors even if there was only one error etc, so that you could deserialize it consistently. I agree that it would be nice to have some proper error infrastructure and a mapper that rendered it in VndError, that said I think VndError for the most part is a good baseline to work off. In the end you need things like a trace id, message, path and potentially links no matter how it's rendered. |
Given how HAL specific |
@gregturn Looks like a good spec, and hopefully more maintained. Thanks for letting me know. |
@gregturn Is there going to be a standard support for a trace reference (e.g. trace id from Sleuth) or would that have to be built into every custom problem type, do you know? |
Resolved via 4f3be11 |
There is a
path
attribute in vnd.error specification but unfortunately there is no such field inVndErrors
class. It could be very handy to have this filed, to be able to report resource validation errors, for example.The text was updated successfully, but these errors were encountered: