Controller
@Operation(summary = "주문 취소")
@PatchMapping("/{order_id}")
public ResponseEntity<CommonResponse<OrderResponseDto>> cancelOrder(
@PathVariable("order_id") UUID orderId) {
OrderResponseDto responseDto = orderService.getOrderDetail(orderId);
return ResponseEntity.ok(new CommonResponse<>(SuccessCode.ORDER_CANCEL, responseDto));
}
취소 = 모든 사용자가 가능
삭제 = 매니저만 가능
주문이 들어오고 5분안에만 취소가 가능하다.
잘은 모르겠지만 스케쥴러를 사용해야 할 것 같다. 내일 찾아보도록!
Valid는 유효성 검사한다~ 이정도로만 알고있었다 무지 그 자체
우리 조는 @Validated를 사용하기로 했으므로 @Validated에 대해 알아보자
입력 파라미터의 유효성 검증은 컨트롤러에서 최대한 처리하고 넘겨주는 것이 좋다. 하지만 불가피하게 다른 곳에서 파라미터를 검증해야 할 수 있다. 스트링에서는 이를 위해 AOP 기반으로 메소드의 요청을 가로채서 유효성 검증을 진행해준다. 이것이 @Validated
@Service
@Validated
public class UserService {
public void addUser(@Valid AddUserRequest addUserRequest) {
...
}
}
해당 클래스의 메소드들이 호출될 때 AOP의 포인트 컷으로써 요청을 가로채서 유효성 검증을 한다.
그러므로 계층에 무관하게 스프링 빈이라면 유효성 검증 진행 가능하다.
메소드에 @Valid, 클래스에 @Validated
쉽게 말하자면 @Valid는 자바 표준 스펙이고 @Validated는 스프링에서 제공하는 어노테이션이다.
수정 대결이다.
간단하게 적자면
PUT - 전체 수정
PATCH - 부분 수정
이라고 생각하면 좋을듯하다.
조금 더 깊이있게 보자면
PUT 요청은 payload에 있는 자원으로 대체하는 HTTP 메서드이다. 즉, 상황에 따라 다르게 동작한다는 말씀
1. 자원이 존재x -> 새로운 자원 저장
2. 자원이 존재o -> 기존에 존재하는 자원을 지우고 새로운 자원으로 update
=> PUT은 payload에 필드 값이 다 있어야 한다.
PATCH요청은 기존 자원이 반드시 있어야 한다.
주문 수정하기 기능은 PATCH를 사용할 예정이다.
바보같은 ㅏㄴ의 모습..