@ResponseStatus 와 ResponseEntity 차이점

프로젝트를 진행하면서 처음에는 ResponseEntity 로 전부 깔고 시작했다.

현 프로젝트에서는 "복잡성을 굳이 가져갈 필요 없다, 대중적으로 사용하지만 사용하지 않는(어울리지 않는) 것은 단순화 할 필요가 있다" 라는 생각이 들어 @ResponseStatus 로 리팩토링했다.

 

추상화 VS 커스터마이징  이 둘중에 하나를 사용해야 한다고 하면 그 상황에 맞는 선택이 필요하고 생각한다.

간편하게 빠르게 사용할 수 있는 추상화를 사용하고, 이후 리팩토링을 진행하거나 필요에 맞게 커스터마이징 할 수 있는 레벨로 변경하는 것이 좋은 방법이 아니지 않을까 생각한다.

정답은 없으니 프로젝트에 맞는 유연한 대처가 필요하다.

---

@ResponseStatus 어노테이션은 HttpStatus 를 표현하는 방식 중 하나이다.

Controller 클래스에서 원하는 메서드 위에 어노테이션 방식으로 작성하며 코드 복잡성 없이 간단하게 구현할 수 있다.

 

ResponseEntity 는 HTTP Request , Response 를 나타내기 위해 HttpEntity 라는 클래스가 존재하는데,

사용자의 HttpRequest에 대한 응답 데이터를 포함하는 클래스이다. 따라서 HttpStatus, HttpHeaders, HttpBody를 포함한다. 

 

 

각 장단점에 대해 알아보자.

먼저 코드로 보면 아래와 같다.

@GetMapping("/categories/responseStatus")
@ResponseStatus(HttpStatus.OK)
@ApiOperation(value = "카테고리 조회")
public List<CategoryResponse> categoryFindAll() {
    return categoryService.categoryFindAll();
}

@GetMapping("/categories/responseEntity")
@ApiOperation(value = "카테고리 조회")
public ResponseEntity<List<CategoryResponse>> categoryFindAllTest() {
    List<CategoryResponse> categoryResponses = categoryService.categoryFindAll();
    return new ResponseEntity<>(categoryResponses, HttpStatus.OK);
}

두 가지모두 카테고리를 조회하는 기능으로 결과값 또한 같다.

 

@ResponseStatus의 장점은 코드량이 짧고, 심플하게 도입할 수 있다는 점이다. 또한 추상화로써 자동으로 작동한다.

단점으로는 ResponseEntity 와 다르게 디테일하게 제어할 수 없다 ( 커스터마이징 불가 )

 

ResponseEntity는 유연하게 동작할 수 있는 것이 장점이다. Header 를 정의 등 커스터마이징이 필요할 때 사용한다.

단점으로는 코드의 복잡성이 있다.