SpringBoot Basic Weekly Mission 3

🔖 소감

타임리프

한 달 동안 타임리프와 살 부딪히면서 씨름한 결과,
득보다 실이 더 많은 라이브러리라는 판단이 들었다.

경험한 단점으로는

1. 원시값 포장하는 경우 코드량이 그닥 줄지 않는다.
2. 문자열 기반으로 매핑하므로, IDE의 자동수정 기능을 활용할 수 없다.
3. mock 테스트 시 mapper에 대한 테스트 코드가 추가로 필요한 상황 발생한다.
4. 런타임에 바이트코드로 변환하는 코드량이 증가하므로, 성능에 미세한 하락이 발생한다.

REST API

꽤 많은 규칙이 있었다.
컨벤션이라고 해야하나.

암튼 생각보다 고려할 점이 많았지만,

결론은
1. url에 동사를 사용하지 말고, 자원을 명시할 것.
2. 응답만을 보고 클라이언트가 행위를 알 수 있도록 필요한 많은 정보를 제공할 것.
3. http 상태코드를 적절히 사용해서, 응답에 대해서 빠르게 알 수 있도록 할 것.
4. http 메소드를 적절하게 활용해서 url 변칙이 크지 않도록 할 것.

이 정도가 기억난다.

경험을 통해 더 rest 한 api 개발이 가능하도록 해야겠다.

ExceptionHandler

컨트롤러에서 발생하는 예외는 핸들러를 따로 만들어 매핑해줘야 한다.
커스텀 예외를 만들어야 하는 이유가 하나 더 늘었다.

다음번에는 글로벌 예외가 아니라,
예외 상황을 이름만으로 알 수 있는 예외를 만들어 체계적으로 분화하는 과정이 필요할 것 같다.

---

📌 과제 설명

흐름도

클래스 다이어그램

✅ PR 포인트 & 궁금한 점

• nullable 컬럼

  • 테이블에 null 값이 가능한 컬럼은 도메인 클래스에서 어떻게 관리하는지 궁금합니다.
  • 생각해본 해법입니다.
    1. 로직에서는 Optinal로 처리, 컨트롤러 단에서 Optional.get() 으로 직렬화
    2. null 상태를 가리키는 무의미한 인스턴스 객체를 생성해서 사용

• 컨트롤러 인터페이스

  • rest 컨트롤러, view 컨트롤러 모두 리턴 타입만 다를 뿐 나머지 시그니처는 같은 것 같습니다.
  • 만약 두 가지 컨트롤러를 모두 구현해야 하는 경우 리턴타입이 Object인 인터페이스를 만들어도 되는지 궁급합니다.

  interface Controller {
    Object allList();
  }
  
  @RestController
  class RestController implements Controller {
    @GetMapping("/all")
    public ResponseEntity<Response> allList() {
        return ResponseEntity.ok(...);
    }
  }
  
  @Controller
  class ViewController implements Controller {
    @GetMapping("/all")
    public String allList() {
        return "뷰이름";
    }
  }

• PathVariable 이 좀 더 REST 한 api 설계방식이라고 들었습니다.

  • 잘못된 지식을 습득한 것인지 궁금합니다.

• 버저닝

  • 버저닝을 사용하는 경우, 버그가 있는 것이 아니라면 기존 버저닝은 유지하는 편이 좋은지 궁금합니다.

👩‍💻 요구 사항과 구현 내용

• 타임리프
• REST api

✅ 피드백 반영사항

• url mapping 정리
• 컬렉션 응답 wrapper 클래스
• exception handler 보강
• url 버저닝
• 발생 예외 분화
• Response 결과 명확히 알도록 응답 수정