[🚀 사이클2 - 미션 (예약 변경/취소와 에러 처리)] 우디 미션 제출합니다.

[armd482]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

베이스 코드 선택 체크

• 이전 미션의 내 코드에서 시작
• 이전 미션의 페어의 코드에서 시작

배포 주소

https://reservation-front-eta.vercel.app/
https://reservation-front-eta.vercel.app/admin

어떤 부분에 집중하여 리뷰해야 할까요?

1. 업데이트 method 방식
   이번 예약 업데이트의 경우 어떤 메서드가 적절할까 고민했습니다.
   post의 경우 RFS 9110에 따르면, 단순히 추가가 아닌 데이터에 대한 요청으로 넓게 바라보고 있고,
   put의 경우 전체 데이터를 수정, 추가의 역할로,
   patch는 부분 데이터를 수정할 때 사용하는 것으로 알고 있습니다.

근데, patch의 경우 일반적으로 클라이언트에서 전체 데이터를 알지 못하거나, body로 전달해야 하는 데이터가 큰 경우 효율적으로 전달하기 위해 등장한 걸로 알고 있으며 현재의 경우, 이미 클라이언트에서 예약 데이터 전체를 알고 있으며, body로 전달하는 데이터가 아니므로 patch는 판단해 후보에서 제외했습니다.

남은 PUT과 POST 사이에서 고민한 결과, PUT은 요청한 ID가 서버에 없을 경우 신규 리소스를 생성(Create)하는 동작을 포함하기 때문에, 기존 예약 건에 대해서만 엄격하게 수정을 처리해야 하는 본 비즈니스 로직에는 적절하지 않다고 결론지었습니다. 따라서 리소스 처리에 대한 유연성이 높고 의도치 않은 생성을 방지할 수 있는 POST 방식을 최종적으로 선택하게 되었습니다.

이러한 결정 방향에 대해 어떻게 생각하시는지 의견을 듣고 싶습니다.

2. global handler 범위
   현재의 경우 CustomException과, dto valid 관련 MethodArgumentNotValidException, runtimeException만 걸고 있는데, 이 이유는 이미 도메인/서비스단에서, 전달 받은 값이 유효한 값들인지, 해당 데이터가 존재하는지, 참조되고 있는 데이터인지 등을 검증하고 있습니다. 그래서, repository에서 발생하는 sql exception에 대해서는 handler를 등록할 필요가 없지 않을까 생각하는데(이걸 handling해서 클라이언트에 전달해도 해결할 수 없는 문제 아닌가 생각합니다.), 이에 대해서 의견을 듣고 싶습니다