8월 12일 (월)

참여자: 고동훤, 김준기, 김현수, 김현욱

회의 안건

• Discussion 내용 논의
• 비즈니스 요구사항 구체화

Discussion 내용 논의

Exception 컨벤션 정하기

https://github.com/woowa-techcamp-2024/Team1-3K1K/discussions/14

• Custom Exception
• Error Code
• Exception Handling

Unchecked VS Checked

• Unchecked Exception

  • 글로벌 핸들러에서 누락 실수 등 놓칠 수 있지 않을까

• Checked Exception

• 기본적으로는 RuntimeException을 가져가자.

• • ControllerAdvice (컨트롤러 단위의 예외 핸들러)
• • 서비스 클래스의 public 메서드에 @throws javadocs 간단히 주석으로 명시

도메인 Validation

https://github.com/woowa-techcamp-2024/Team1-3K1K/discussions/17

• @Phone 검증 ?
• requestDTO , Domain 더블 체킹
• Domain 객체는 DomainValidator 에서 절차지향으로 검증
• 핸드폰 번호 같이 애매한 부분은 각자 스타일에 맞게 구현하고, PR에서 토의
  • @Phone 검증

API 응답 모델

https://github.com/woowa-techcamp-2024/Team1-3K1K/discussions/13

1. 컨트롤러 반환 타입

• 결제 중복 따닥 요청을 방지하기 위해, 만료되어 있는 경우 등 던지는 코드가 따로 있는 것으로 알고 있음

• 415 code 등등, 컨트롤러에서 ResponseEntity를 던지는게 더 명확하겠다.

• 성공에 대한 상태 코드를 세분화하는게 클라이언트 측이 조금 더 명시적일 것

  → 컨트롤러에서 ResponseEntity를 반환하도록 하자

1. POST

• restController → 201 OK + Location Header
• Controller → PRG
• 요청 시점 URL을 갖고있어도 괜찮을 것 같다?

1. CSR vs SSR 기준이 모호함

• 현재는 모두다 restController로 구현되어 있음. 이렇게 되면 결국 CSR로 될 것 같다는 고민

  → 일단 rest하게 구현해놓고, 뷰는 나중에 고민하자.

1. API 공통 응답

• 실패 케이스:

  ProblemDetail 를 활용하고, 해당 명세를 따른다. + errorCode 필드 하나 추가

  {
  	"type" : "type을 명시",
  	"title" : "title을 명시",
  	"status" : "error status code를 명시",
  	"instance" : "instance? 를 명시",
  	"errorCode" : "custom error code를 명시",
  	"message" : "error에 대한 구체적인 메세지 명시"
  }

• 성공 케이스:

  {
  	"status": "성공 상태 코드(숫자)",
  	"data" : {
  		응답 데이터
  	}
  }

  response : class ( id , password)
  
  ~~{
  status : "status",
  "id" : "id value",
  "pw" :"pw value"
  }
  
  vs~~
  
  {
  status : "status",
  "data": {
  		"id" : "id values",
  		"pw" : "pw values"
  	}
  }

→ 실패 케이스, 성공 케이스에 대해 명확하게 분리하기 어렵다고 판단.

→ 각각의 상황에 대해 세부적으로 분리하기 시작하면, 너무 디테일해지고 언젠간 컨벤션이 깨지기 쉬움

→ 간단하고 관리하기 용이한 구조로 가져가자.

→ 성공: 2xx, 실패: 4xx + error code로 세부 명시