Skip to content
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

Closed
s303 opened this issue Mar 3, 2017 · 9 comments
Closed

vnd.error path attribute #546

s303 opened this issue Mar 3, 2017 · 9 comments
Labels
in: mediatypes Media type related functionality
Milestone

Comments

@s303
Copy link

s303 commented Mar 3, 2017

There is a path attribute in vnd.error specification but unfortunately there is no such field in VndErrors class. It could be very handy to have this filed, to be able to report resource validation errors, for example.

@gregturn
Copy link
Contributor

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.

@douglassparker
Copy link

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.

@hughwphamill
Copy link

@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.

@gregturn
Copy link
Contributor

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. vnd.error is confined to HAL, and I feel like we need a little more. So I opened #786.

@hughwphamill
Copy link

hughwphamill commented Mar 12, 2019

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.

@gregturn
Copy link
Contributor

Given how HAL specific VndErrors is, we're actually looking at RFC-7807.

@hughwphamill
Copy link

@gregturn Looks like a good spec, and hopefully more maintained. Thanks for letting me know.

@hughwphamill
Copy link

@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?

@gregturn gregturn added in: mediatypes Media type related functionality and removed process: waiting for feedback labels Dec 10, 2019
@gregturn gregturn added this to the 1.1.0.M1 milestone Dec 10, 2019
@gregturn
Copy link
Contributor

Resolved via 4f3be11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: mediatypes Media type related functionality
Projects
None yet
Development

No branches or pull requests

4 participants