2
votes

I'm late to the spring mvc/rest development area, so I'm trying to get my head around the concept.

I read this stackoverflow post: Which is better, return "ModelAndView" or "String" on spring3 controller which discusses the merits of ModelAndView and using a String return on a controller(with Model as a method parameter). I'm reposting the code

@RequestMapping(value = "/list", method = RequestMethod.GET)
public ModelAndView list(
    @UserAuth UserAuth user, 
    ModelAndView mav) {

    if (!user.isAuthenticated()) {
        mav.setViewName("redirect:http://www.test.com/login.jsp");
        return mav;
    }

    mav.setViewName("list");
    mav.addObject("articles", listService.getLists());

    return mav;
}


@RequestMapping(value = "/list", method = RequestMethod.GET)
public String list(
    @UserAuth UserAuth user, 
    Model model) {

    if (!user.isAuthenticated()) {
       return "redirect:http://www.test.com/login.jsp";
    }

    model.addAttribute("articles", listService.getLists());

    return "list";
}

Also this time, I found another set of spring mvc controller codes:

The controller is defined as:

@RestController
public class EmployeeRESTController

This has a method that returns an EmployeeListVO.

@RequestMapping(value = "/employees")
public EmployeeListVO getAllEmployees()
{
    EmployeeListVO employees = new EmployeeListVO();

    EmployeeVO empOne = new EmployeeVO(1,"Lokesh","Gupta","[email protected]");
    EmployeeVO empTwo = new EmployeeVO(2,"Amit","Singhal","[email protected]");
    EmployeeVO empThree = new EmployeeVO(3,"Kirti","Mishra","[email protected]");


    employees.getEmployees().add(empOne);
    employees.getEmployees().add(empTwo);
    employees.getEmployees().add(empThree);

    return employees;
}

Another method this time

@RequestMapping(value = "/employees/{id}")
public ResponseEntity<EmployeeVO> getEmployeeById (@PathVariable("id") int id)
{
    if (id <= 3) {
        EmployeeVO employee = new EmployeeVO(1,"Lokesh","Gupta","[email protected]");
        return new ResponseEntity<EmployeeVO>(employee, HttpStatus.OK);
    }
    return new ResponseEntity(HttpStatus.NOT_FOUND);
}

I looked for some stackoverflow post regarding the merits of @ResponseBody and @ResponseEntity, post like this What is the difference between ResponseEntity<T> and @ResponseBody?

My question now is, since I'm fairly new in this area and going through sample codes make me confuse on what approach to take, which direction should I go? I believe the ModelAndView and Model while returning a String might be an old approach? Maybe the history or the transition from ModelAndView to @ResponseBody / @ResponseEntity might help? Is this because of spring versions?

To add context to my question, in my current work, we are using Spring 4, but in the codes I've seen a mix of all of these kinds of approaches in the code base(different developers worked on the code base for x number of years already).

I hope the mods won't close this and see it as opinion-based. I thought I can ask for direction from seasoned developers here in this site.

1

1 Answers

1
votes

ModelAndView as well as returning string (template name) is used in cases where you have web interface (eg. website), so you are using Spring MVC and you would normally use that with @Controller annotation.

@ResponseBody means that whatever you are returing will be the body of response (response has other parts as well like headers etc). Spring will also try to autoconvert it into proper form depending on what given method "produces" (and that is defined in @RequestMapping but not only there). For example using @RestController means that whatever you return in your methods, will be converted to JSON unless you specify otherwise (notice that @ResponseBody is attached to @RestController).

ResponseEntity<T> means whole response (with body of T), not only body like in @ResponseBody. You can specify headers, response code, response content (body) like file content, plain text etc. so basicly you can model every part of HTTP response.

What you will use is up to you, and depends only on your requirements.