What is the best practice for RestController?

南笙酒味 提交于 2021-02-07 12:39:23

问题


Code convention says no logic in the controllers. All should be handled in the service layer. My question is especially about returning ResponseEntity.

Should it be handled in RestController or in Service layer?

I tried both ways. I think RestController is the suitable place to return ResponseEntity. Because we are using mappings in the RestController.

On the other hand, we know the controllers should not include any logic.

@GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(@PathVariable Long id) {
    return ResponseEntity.ok(employeeService.findEmployeeById(id);
}

or

@GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(@PathVariable Long id) {
    return employeeService.findEmployeeById(id);
}

ControllerAdvice for exception handling is my another concern. Which way is the best to use?

Thanks for your advance.


回答1:


Code convention says no logic in the controllers.

Not really. Code convention says each layer has to perform itself logic which it is responsible of.
Computing the result, retrieving data requested/needed by the request is clearly not the rest controller job but sending an http response, what returning ResponseEntity does is its job. So this looks the correct way :

@GetMapping("/{id}")
public ResponseEntity<Employee> getEmployee(@PathVariable Long id) {
    return ResponseEntity.ok(employeeService.findEmployeeById(id);
}

If the ResponseEntity was produced by your service, your service would be coupled with the Http layer. Not desirable and make it less reusable as a service.




回答2:


Status Code, Response Body, Headers are one of the core parts for REST

The controller should be concerned with accepting the request, asking the correct domain service to process the request, and handing off the response to the correct place.

It's right that controllers should not perform all business logic here but sending the HTTP response should be done in Controller instead of service.

Although Status code can be sent using @ResponseStatus(HttpStatus.XXX) which might not be helpful for in scenarios where we have to send Status Code according to the conditions. You can create custom ResponseDTO which generally have body, message and status code.

public ResponseEntity<ResponseDTO> method() {
    return new ResponseEntity<ResponseDTO>(response,response.getStatus()); 
}



回答3:


First. The business logic should be handled in the service layer where you are able to abstract the data access with repository. This aides modular programming, reusable pieces of codes decoupled from each other. This is the idea behind Model, View, Controller(MVC), the underlying design. In terms of testing, it will be easier to have these parts of the application do their part of the job and testing independent of one another. Abstracting your logic in the service method also helps when we are dealing with security access to specific methods not URL which the controller gives us the ability. Therefore, your RestController should call your service layer and return appropriate response.

Second. For your (Rest) ControllerAdvice, having your exception handler aids in returning custom errors. Here is an example below inside the exception handler class.

     @ExceptionHandler(CustomerExistException.class)
         public final ResponseEntity<ApiErrorResponse> handleCustomerExistException(
            CustomerExistException ex) {


         ApiErrorResponse errorResponse = new ApiErrorResponse("USR_04", "The email     already exists."
            + "Email", String.valueOf(HttpStatus.BAD_REQUEST));

             return new ResponseEntity<ApiErrorResponse>(errorResponse, HttpStatus.BAD_REQUEST);
}`


来源:https://stackoverflow.com/questions/57284058/what-is-the-best-practice-for-restcontroller

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!