What is the advantage of using Spring view resolver.
I am using ajax calls to call the web service without view resolver. Whether changing the configuration using view resolver provides benefits.
More specifically does html view resolver provides anything related to security or session management .
Thanks in advance
No, it's not related to security or session management. In your case, i.e. when you are using #RestController or #Controller+#ResponseBody to send the response directly, view resolvers wouldn't be needed. They are needed only when you want your controller methods to forward to a view.
Related
Assuming an application with a traditional UI based on Spring MVC and Thymeleaf, it seems like there are a few ways to expose a REST API...
Add a completely separate set of Controllers using #RestController - Feels like a lot of duplication, but allows complete separation of UI vs REST logic
Use a single Controller for each entity, with a mix of both #ResponseBody methods and ModelAndView methods - Keeps all logic for a given entity in a single place, but requires mixing different concepts
Use a single Controller for each entity, use only ModelAndView, and use content negotiation with a JSON view resolver like the MappingJackson2JsonView (https://spring.io/blog/2013/06/03/content-negotiation-using-views/)
I'm particularly interested in #3 as it feels similar to how Ruby on Rails Controllers work with the respond_to for different content types.
Is this a common approach / best-practice in Spring applications?
Would POST and DELETE requests still require separate methods since they may work differently between a REST API vs the UI? (i.e. posting a form vs posting a json entity)
Would it require separate Exception handling based on whether it was a UI request or API request?
I'd go with option 1. Having a separate set of #Controller and #RestController avoids mixing MVC pattern with your REST api. To avoid code duplication, you should add a service layer and have the REST endpoint and the MVC controller to make use of that service layer.
I need to create a project able to render views (with JSP) and I need to provide a REST API too.
It's possible to have all of this in the same project?
How will the URLs works to access each things?
Thanks you!
If you are trying to follow the strict Roy Fielding-like principles of REST, then probably not.
But if you just want a REST API in a loose meaning, lets say an interface that returns a resource (JSON, HTML, a documents, etc.), sure. Think of it this way. Most web applications (ones that render views) are also going to have some form of AJAX calls, AJAX calls are just calling a REST API (~ish) that returns some JSON (or something) and then JavaScript is going to parse the response and render something on the views.
So, most modern websites that are powered by or assisted by AJAX are going to be a mix of a REST API and a view rendering one.
Hehe. I just made REST developers around the world cringe.
Now, is this a good practice? That is a whole other story. If you are talking about about a large application that is a GUI based and a large application that uses a REST API, normally you don't mix them. Things get confusing and modularity is awesome for maintenance. Also for what it is worth, normally if you are going 100% RESTful, technology you may need for UI development are no longer available since you begin to track state and such. But if its something small or UI related go for it!
As for the URLs, think about this. You tagged Spring so, I am using that.
//I will render a view!
#RequestMapping("/blah")
public String blah(Model model){
return "/view/blah";
}
//I return a JSON string of "/view/blah"
#RequestMapping("/blah")
public #ResponseBody String blah(Model model){
return "/view/blah";
}
Both of these would be inside a #Controller, they are both doing the same thing but the #ResponseBody in a very, very loose sense, makes the second a REST service, as it tells Spring that what you are returning is the response and not to render a view from it. Granted Spring will only try to render a view if you have a ViewResolver set up.
Baeldung has a great breakdown of RESTful controllers versus non in Spring, and yes they can be used in the same application.
Hopefully that helps!
Yes you can mix in an application a classic #Controller with a configuration that provides a view based on JSP and a #RestController that, as you can read from official javadoc, is a
A convenience annotation that is itself annotated with #Controller and
#ResponseBody.
Yes, you can, only have precaution about the url that you configure in your controllers, with #RequestMapping configure the correct URL for every path in your application.
I have few spring controllers all of these controller modelAttribtes are extended some commonForm(BaseForm). All common properties were in BaseForm and specific properties are in sub classes which acts as ModelAttributes for controllers.
Based on special condition I have scenarios to forward to another controller but while this forward is happening the request contains old data as well and giving double values to the parameters and failing the forwarded request.
Actually this code is copied from struts based project as part of migrating to spring MVC.
Please help me on this.
Thanks,
Syamala.
I'm new to java and web apps and after trying out a few things I went with a set up of Spring webmvc using annotations and velocity as templating engine. It's not that hard to do simple #RequestMapping annotations to controller methods and returning ModelAndView instances filled with data, however I was wondering how things are done when you have data you need in the model that occurs on every page, for example "latest 5 news items" or something similar. You could of course always fill the model with such data in every method that is handled by a #RequestMapping, but I'm quite sure that that is not the way to do it.
What is the correct way of filling the model with recurring data, without poluting your controller methods with calls to the same method for this recurring data.
Any help is appreciated.
You could use a servlet filter or a Spring interceptor, and get the recurring data from this filter or interceptor and place it in a request attribute.
Another solution is to let the page call more than one controller, for example by using multiple ajax requests. Then one controller could is responsible for the specific page and another is responsible for "latest 5 news items", see related question.
Good question dude. In my current app i am using sessions to store my username which is appearing on all the rest of the app.
#JB Nizet thanks for the link.. now ill go for spring interceptor
In it's simplest form, I want an interceptor that checks session data to see if a user is logged in, and if not redirects them to the login page. Obviously, I wouldn't want this interceptor to be used on say the welcome page or the login page itself.
I've seen a design that uses a listing of every url to one of two interceptors, one doing nothing and the other being the actual interceptor you want implemented, but this design seems very clunky and limits the ease of extensibility of the application. It makes sense to me that there should be an annotation-based way of using interceptors, but this doesn't seem to exist.
My friend has the idea of actually modifying the handler class so that during each request it checks the Controller it is mapping the request to for a new annotation we would create (ex #Interceptor("loginInterceptor") ).
A major point of my thinking is the extensibility, because I'd like to later implement similar interceptors for role-based authentication and/or administration authentication.
Does it sound like my friend's approach would work for this? Or what is a proper way of going about doing this?
Use Spring Security.
Please have a look at these sites, Spring Framework Annotation-based Controller Interceptor Configuration and
Ability to restrict HandlerInterceptors to specific controller paths
Hope it will be useful.
What about a Servlet Filter on all requests that sends the user to the login page if the user object isn't in the session? For the second part you can use security annotations on the controller methods that can check the user's role.