REST API | 데이터 수정 api 어떻게 구현할까? (PATCH와 @DynamicUpdate 차이점)

 

 

서론

myBatis 사용할 땐 쿼리를 직접 작성하기 때문에 CRUD 모두 데이터 넣는 부분에서 구현 고민은 별로 없었다.

이번에 고민하게 된 이유는 Spring Boot + JPA 환경에서 PATCH 메서드로 데이터 수정을 요청받아서 update 하려고 했는데
구현을 어떻게 할까.. 고민하다가 이전에는 Patch + @Dynamic 어노테이션을 사용했던 게 기억이 났다. 그런데 당시에는 팀원이 쓰길래 따라 썼던 거라 각각의 정확한 동작과 목적? (어떨 때 사용해야 적합한지..) 에 대해서 아주 한 발짝 더 나가보고 싶었다.

 

PATCH란? 

✅ 정의

PATCH HTTP 메서드는 리소스의 일부 필드만 변경할 때 사용하는 HTTP 메서드이다. 기존 데이터 중 일부만 수정해야 하는 경우, 모든 데이터를 다시 전송하는 PUT과 달리 PATCH를 사용하면 필요한 필드만 변경할 수 있다.

 

⚠️ 주의할 점

일부의 데이터가 들어오고, 들어오지 않은 값에 대해서는 null로 인식한다.
따라서 null 처리 방법을 별도로 고려해주어야 한다. ⭐

PATCH와 PUT 차이점이 굉장히 애매하고,,, 음...
PATCH가 리소스의 일부 필드만 변경하는 메서드라고 하긴해도 결국.. 그런 기능을 구현하는 건 개발자니까(null 처리 로직 추가 같은 것) 이건 뭐라해야하지 결국 그냥 이름의 차이일 뿐인거구나.

메서드가 PATCH면 null처리 해놨으니 필드 편하게 보내~ 인거고 PUT이면 모든 값을 포함해서 보내지 않으면 null로 업데이트 될테니 알아서 해라~~^-^ 이런 느낌인건가..

 

✅ Spring Boot 에서 PATCH 적용 예시

Controller

    @Operation(summary = "상품 수정", description = "상품 수정은 OWNER와 MANAGER만 가능")
    @PatchMapping("/{menu_id}")
    @PreAuthorize("hasAnyRole('OWNER', 'MANAGER')")
    public ResponseEntity<CommonResponse<MenuResponseDto>> modifyMenu(@PathVariable("menu_id") UUID menuId,
        @RequestBody @Validated UpdateMenuRequestDto requestDto,
        @AuthenticationPrincipal UserDetailsImpl userDetails) {
        MenuResponseDto responseDto = menuService.modifyMenu(menuId, requestDto, userDetails);
        return ResponseEntity.ok(new CommonResponse<>(SuccessCode.MENU_MODIFY, responseDto));
    }

 

requestDto

@Getter
@AllArgsConstructor
public class UpdateMenuRequestDto {

    @Length(min = 1, max = 100)
    private String rmName;
    @Min(value = 0)
    private BigDecimal rmPrice;
    private String rmImageUrl;
    @Length(max = 100)
    private String rmDescription;
    private Boolean isPublic;

}

 

요청 json 데이터 예시

{
  "rmPrice": 15000,
  "rmDescription": "Updated menu description"
}

 

requestDto에는 5가지의 필드가 있지만, 이 중에서 3개만 들어온다고 하면 요청에서 전달되지 않은 필드 2개는 requestDto에서 null로 인식된다.

따라서, 앞에서도 썼듯이 null로 들어온 값을 null로 업데이트 할 것인지 혹은 기존 값을 유지할 것인지 처리해주어야 한다.

 

@DynamicInsert와 @DynamicUpdate

✅ 정의

JPA의 어노테이션으로 JPA의 변경 감지(Dirty Checking) 기능으로, 객체의 변경된 필드만 포함된 Insert 쿼리 혹은 Update 쿼리를 생성한다.
null값이 전달되어도 JPA 레벨에서 null을 제외하기 때문에 null 체크 로직 처리를 해주지 않아도 된다.

 

⚠️ 주의할 점

매번 동적으로 쿼리를 생성하기 때문에 성능 오버헤드가 있을 수 있다.
왜 성능 이슈가 있는지 정확히 이해하지는 못했기 때문에 참고자료를 첨부한다. 언젠가.. 이해할 날이 오겠지 ㅎ

인프런| 업데이트 고견 구합니다. 김영한님 답변

 

✅ 적용 예시

@Entity
@DynamicUpdate
// 다른 어노테이션 생략
public class Menu extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.UUID)
    private UUID rmId;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "res_id")
    private Restaurant restaurant;
    @Column(length = 100, nullable = false)
    private String rmName;
    @Column(nullable = false)
    private BigDecimal rmPrice;
    private String rmImageUrl;
    @Column(length = 100)
    private String rmDescription;
    @ColumnDefault("true")
    private Boolean isPublic;

 

 

PATCH Method 와 @DynamicInsert, @DynamicUpdate 의 차이점

특징과 차이점을 정리하자면 아래와 같다. (feat. 정리의 신 gpt)

 

	PATCH (HTTP Method)	@DynamicUpdate (JPA Annotation)
기능	클라이언트가 일부 필드만 수정 가능하도록 지원	변경된 필드만 업데이트하도록 JPA가 쿼리 최적화
적용 대상	API 요청 수준	Entity 수준
업데이트 방식	JSON으로 전달된 필드만 변경	객체의 변경된 필드만 감지하여 SQL 생성
SQL 실행 방식	개발자가 필요한 필드만 수동으로 업데이트	Hibernate가 변경 감지하여 자동 최적화
DTO 활용	보통 UpdateDto를 사용	Entity 그대로 사용 가능
사용 기술	Controller → Service → Repository	JPA, Hibernate

 

 

결론

결국엔 필요에 따라 선택해서 사용하면 되겠다.
이전 프로젝트에서는 PATCH와 @DynamicInsert를 함께 사용하여
필요한 필드만 받아온 후 Entity에 변경 메서드를 구현하는 방식으로 코드를 작성했었다.

이번에는 PATCH로 필요한 필드만 받아온 후 null값이면 기존 값으로 대체해주는 방식으로 구현했다.

 

 

...그런데..... 음................... 두 방식의 차이를 이해하기는 한 것 같은데
구현에서는 차이가.. 안 나는 것 같은데...?
이번에도 Entity에 변경 메서드를 구현하고 그 내부에 null 체킹하는 방식이라서 갑자기 급 의문이 들었다.
Entity에 변경 메서드 구현하는 건 같은데 어노테이션 붙이고 안 붙이고 차이가 뭐지?
내가 잘못 이해하고 구현한걸까..
다음 TIL은 이거다........................