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

Reference Documentation: instruct how RestTemplate should handle the errors thrown about @Validated (JSR 303/349) [SPR-14724] #19289

Closed
spring-projects-issues opened this issue Sep 16, 2016 · 4 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 16, 2016

Manuel Jordan opened SPR-14724 and commented

Hello

In the current Reference Documentation, for the 28.10 Accessing RESTful services on the Client section.

Why not add a section about how RestTemplate should handle the errors thrown by validation (JSR 303/349)?. It when a @Controller for Rest is using @Validated. Consider cover the testing scenarios too.

I have seen some tutorials but seems the developer must write his own code. Even more, I did realise exists many approaches, in some way verbose until some point.

Therefore just curious what is the best approach recommended by the source (Spring Reference documentation) with the current version 4.3.2 and 5 coming, just curious if the API is friendly for this.

Thanks by your understanding.


Affects: 4.3 GA, 4.3.1, 4.3.2, 5.0 M1

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 12, 2016

Rossen Stoyanchev commented

I'm not quite sure what you mean. By default in the case of validation errors, the server responds with a 400 status code. Are you looking to add a response body with more details? Or are you asking something else?

There is a base class called ResponseEntityExceptionHandler that can be useful for generating error responses with error details. See the reference. Generally speaking however we've considered in the past providing support for writing errors to the body but have rejected it because it is very application specific. See for example #17136. Also note that Spring Boot does generate error details in the response body and that makes perfect sense in the context of a more opinionated solution.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2016

Manuel Jordan commented

Hello Rossen

I'm not quite sure what you mean. By default in the case of validation errors, the server responds with a 400 status code. Are you looking to add a response body with more details? Or are you asking something else?

I already have resolved this. I did it manually and doing a research in google. It working with the ResponseEntityExceptionHandler abstract class with a @ControllerAdvice.

My point was indicate or give some clues to the developer about best practices about how handle this.
For example the ResponseEntityExceptionHandler appears twice in the current reference documentation (just in the link you have shared).

To be honest when I do a research through the reference documentation, I always start looking for snippet code, later I analyze the theory. Yes I know, is a huge documentation and has no sense add a snippet code for each section.

Since this is not critical, you can proceed to close this ticket.

As usual thanks by your support.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2016

Rossen Stoyanchev commented

I've added a small section to the reference e3ecf01.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2016

Manuel Jordan commented

Hi Rossen

Nice improvement. Now the developers have an idea about what to do.

Best

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants