What is the best practice for RestController? - spring

Question

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.

Answer 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.

Answer 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());
}

Answer 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);
}`