resultCode 타입

resultCode의 타입을 String으로 설정할지, HttpStatus로 설정할지에 따라 장단점과 사용 목적이 달라집니다. 아래에서 두 가지 방식의 차이점과 각각의 장단점을 설명하겠습니다.

---

1. resultCode를 String으로 사용하는 경우

특징

• String 타입으로 설정하면 상태 코드를 더 자유롭게 정의할 수 있습니다.
• HTTP 상태 코드에 얽매이지 않고, 프로젝트에서 사용되는 고유의 코드(예: SUCCESS, ERR001, NOT_FOUND)를 사용할 수 있습니다.

장점

1. 유연성:

   • HTTP 상태 코드 외에도 비즈니스 로직에 맞는 커스텀 코드(예: ERR001, USER_BLOCKED)를 정의할 수 있습니다.
   • 프로젝트 전반에서 명확한 의미를 가진 상태 코드를 일관되게 사용할 수 있습니다.

2. 의미 부여:

   • 숫자 상태 코드보다 사람이 읽기 쉽고, 코드의 의도를 더 명확히 전달할 수 있습니다.

3. 독립성:

   • HTTP 상태 코드와 무관하게, 특정 도메인 로직에 특화된 상태 코드를 만들 수 있습니다.

단점

1. 추가 작업 필요:

   • 클라이언트가 String 상태 코드를 올바르게 처리하려면 추가적인 문서화 및 매핑이 필요합니다.
   • HTTP 상태 코드와 String 상태 코드를 동기화하려면 별도의 관리가 필요합니다.

2. 표준화 부족:

   • API 사용자가 표준 HTTP 상태 코드에 의존하려고 할 경우, 익숙하지 않을 수 있습니다.

---

2. resultCode를 HttpStatus로 사용하는 경우

특징

• Spring의 HttpStatus 타입을 사용하면 HTTP 상태 코드를 명시적으로 나타낼 수 있습니다.
• 상태 코드는 Spring이 제공하는 표준 값(HttpStatus.OK, HttpStatus.BAD_REQUEST 등)을 사용합니다.

장점

1. 표준 준수:

   • HTTP 상태 코드라는 표준을 따르므로 API 사용자(클라이언트)가 쉽게 이해할 수 있습니다.
   • 클라이언트는 응답의 상태를 HTTP 규격에 따라 즉시 해석할 수 있습니다.

2. 타입 안정성:

   • 컴파일 시점에 유효하지 않은 상태 코드를 방지할 수 있습니다.
   • 상태 코드 값이 잘못 정의될 가능성이 줄어듭니다.

3. 일관성:

   • API가 HTTP 상태 코드 표준을 따름으로써 RESTful 원칙을 준수하는 구조로 작성됩니다.

단점

1. 유연성 부족:

   • HTTP 상태 코드에 정의되지 않은 커스텀 상태 코드를 추가하기 어렵습니다.
   • 비즈니스 로직에 특화된 세부적인 상태 코드(예: USER_BLOCKED, ERR001)를 표현하기 어렵습니다.

2. 의미 제한:

   • HTTP 상태 코드만으로 응답의 의미를 세부적으로 표현하는 데 한계가 있을 수 있습니다. 예를 들어, 404는 "리소스 없음"만 나타내며, 리소스가 없는 이유(권한 부족, 잘못된 요청 등)를 세부적으로 표현하지 못합니다.

---

선택 기준

1. String 타입을 선택할 때

• 프로젝트에서 비즈니스 로직에 특화된 상태 코드를 세분화해서 사용하고 싶을 때.
• 응답의 상태 코드에 대해 HTTP 표준 이외의 의미를 부여하고 싶을 때.
• API 사용자에게 상태 코드와 함께 읽기 쉬운 문자열 상태를 제공하고 싶을 때.

예:

{
  "resultCode": "USER_BLOCKED",
  "message": "The user is blocked.",
  "data": null
}

2. HttpStatus 타입을 선택할 때

• 프로젝트가 RESTful API 표준을 따르고자 할 때.
• 상태 코드가 HTTP 클라이언트와의 직관적 상호작용을 위해 중요할 때.
• 응답 상태를 HTTP 표준으로 간결하고 명확하게 표현하고 싶을 때.

예:

{
  "resultCode": 403,
  "message": "Access is denied.",
  "data": null
}

---

결론

• 비즈니스 중심 API라면 String이 적합합니다. 예를 들어, 서비스에 특화된 에러 상태 코드가 많고, 클라이언트가 이를 해석해야 할 경우.
• RESTful 표준을 강조한다면 HttpStatus를 사용하는 것이 좋습니다. HTTP 프로토콜의 표준 상태 코드만으로도 충분히 의미를 전달할 수 있는 경우.

두 가지를 혼합하려면 resultCode를 String으로 설정하고, 추가적으로 HttpStatus를 필드로 포함하거나, 상태 코드를 문자열과 HTTP 상태 코드를 매핑하는 방식도 가능합니다.