You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spring-MVC currently let's the server decide which view to render for a given request, through it's View, view name and ViewResolver abstractions. In a more RESTful scenario, it is a best practice to let the client decide the representation, via the "Accept" HTTP header. The server responds with the delivered representation via the "Content-Type" header.
One issue with the "Accept" header is that is impossible to change it in a web browser; it is always fixed to "text/html, image/gif", etc. Looking at the file extension is a good workaround, i.e. http://example.com/hotels.pdf retrieves the PDF view of the hotel list, as does http://example.com/hotels with an Accept header of "application/x-pdf".
We should create a ViewResolver which respects the client-side Accept header, but also looks at file extensions. This view resolver acts as an adapter other ViewResolvers, simply delegating to the correct one given a particular media type.
Arjen Poutsma opened SPR-5452 and commented
Spring-MVC currently let's the server decide which view to render for a given request, through it's View, view name and ViewResolver abstractions. In a more RESTful scenario, it is a best practice to let the client decide the representation, via the "Accept" HTTP header. The server responds with the delivered representation via the "Content-Type" header.
One issue with the "Accept" header is that is impossible to change it in a web browser; it is always fixed to "text/html, image/gif", etc. Looking at the file extension is a good workaround, i.e. http://example.com/hotels.pdf retrieves the PDF view of the hotel list, as does http://example.com/hotels with an Accept header of "application/x-pdf".
We should create a ViewResolver which respects the client-side Accept header, but also looks at file extensions. This view resolver acts as an adapter other ViewResolvers, simply delegating to the correct one given a particular media type.
This issue is a sub-task of #9097
Referenced from: commits df563df
The text was updated successfully, but these errors were encountered: