Spring @RestController & ResponseEntity<T>에 대해

• @RestController만 사용해도 DELETE와 PUT 요청을 처리할 수 있다.
• 하지만, 응답 상태 코드나 헤더를 제어하고 싶을 때는 ResponseEntity를 사용하는 것이 더 유리하다.
• ResponseEntity<T>는 특정 타입 T의 데이터를 HTTP 응답으로 감싸서 반환하기 위한 객체
• @RestController는 응답 바디를 자동으로 직렬화하여 반환해 주기 때문에, 간단한 응답을 처리할 때는 매우 유용하다.
• ResponseEntity는 응답 상태 코드와 헤더 등을 세밀하게 제어할 수 있기 때문에, 복잡한 응답 처리가 필요한 경우에 사용된다.

---

@RestController와 응답

 

• @RestController는 @Controller와 @ResponseBody를 결합한 어노테이션. 즉, 메서드의 반환값을 HTTP 응답 본문에 자동으로 매핑한다.
• 이 말은, 응답을 본문으로 반환할 때 자동으로 JSON 또는 XML 형식으로 변환된다는 것
• 따라서 @RestController만 사용한다고 해서 상태 코드나 헤더를 설정할 수 있는 것은 아니다.

 

ResponseEntity의 필요성

1) 상태 코드 제어

예를 들어, 리소스 생성이 완료되면 HTTP 상태 코드 201 Created를 반환하는 것이 좋습니다.

2) 에러 처리

클라이언트 요청에 문제가 있을 때, 예를 들어 잘못된 요청이나 리소스 미발견 등의 경우에도 상태 코드와 함께 적절한 응답을 보내는 것이 중요 (ex. 404 Not Found)

 

3) 헤더 제어

특수한 경우, 예를 들어 파일 다운로드와 같은 경우, 헤더를 추가하여 응답을 보낼 때 ResponseEntity가 필요

상황	설명	ResponseEntity가 적합한가?
✅ 상태코드를 바꾸고 싶을 때	예: 201 Created, 204 No Content, 404 Not Found 등	Yes
✅ 응답 헤더를 추가하고 싶을 때	예: 토큰, 쿠키, 캐시 제어 등	Yes
✅ 조건부 응답	예: 데이터 유무에 따라 다른 응답 반환	Yes
❌ 단순 JSON 반환	상태코드=200 OK, 헤더도 기본값이면	No, @ResponseBody로 충분
❌ REST API 기본 응답	@RestController 쓰면 자동 @ResponseBody 적용	굳이 필요 없음

 

---

헤더의 역할

헤더는 주로 다음과 같은 정보를 담고 있습니다:

• Content-Type: 전송되는 데이터의 형식을 지정 (ex. JSON)
• Authorization: 인증 정보를 담고 있는 헤더. 예를 들어, API에 접근할 때 Bearer 토큰을 담아서 인증을 거친다.
• Content-Length: 요청 본문(body)의 길이를 바이트 단위로 나타낸다.
• Accept: 클라이언트가 받아들일 수 있는 응답 데이터의 형식을 지정한다. 예를 들어, 클라이언트가 application/json 형식으로 응답을 받을 수 있음을 명시
• Cache-Control: 데이터가 캐시될 수 있는 방법이나 만료 시간을 설정
• Location: 리다이렉션(redirect) 응답에서, 클라이언트가 리다이렉트해야 하는 새로운 URL을 제공하는 헤더

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234
Cache-Control: no-cache

• Content-Type: 서버가 응답할 때 JSON 형식으로 데이터를 보내겠다고 알림
• Content-Length: 응답 본문(body)의 길이를 바이트 단위로 명시
• Cache-Control: 클라이언트가 캐시하지 않도록 설정

---