[Spring Boot] HTTP Method 중 PUT vs PATCH에 대한 고민과 해결

🚀 서론

프로젝트 진행 중
데이터 수정 시 PUT, PATCH, DELETE를

어느 상황에서 사용해야 되는지 잘 모르고 API를 구현했습니다.

덕분에 프론트엔드님들이 헷갈리신다고 😂😂

(왜냐하면 우린 삭제도 논리적으로 상태만 삭제로 변경하기 때문입니다. 물리 삭제는 일부만 구현한 상황입니다.)

 

그래서 다시 전체적으로 수정과 삭제 API들을 건드리게 되었습니다.

 

작업하면서 공부한 내용을 소개하겠습니다.

 

⭐ PUT과 PATCH 구분하기

PUT, PATCH를 수정 용도로 사용한다고만 알고있어서

차이를 잘 모르고 혼용해서 막 쓰는 경우가 종종 있습니다.

 

결론부터 말하면 둘은 엄연히 다릅니다.

개쪽이: PUT 요청이든 PATCH 요청이든 결과가 같은데요?????

개쪽아.

그것은 결과만 그렇게 보일 뿐

둘은 대체재 관계가 아닙니다.

 

✅ PUT Method

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
- by RFC

PUT 요청은 요청 payload(ex. RequestBody)에 있는 자원으로 대체하는 HTTP 메서드입니다.

여기서 대체하는 메서드라는 것은 대상을 저장하기도, 변경한다는 것을 의미합니다.

즉, PUT 메서드는 상황에 따라 다르게 동작합니다.

 

1. 자원이 존재하지 않는 경우 -> 새로운 자원을 저장합니다.

2. 자원이 존재하는 경우 -> 기존에 존재하는 자원을 새로운 자원으로 대체합니다.

 

따라서 PUT은 요청 payload에 자원의 전체 상태가 있어야 합니다.

Entity를 생각해 보면

payload에 필드 값들이 다 있어야 합니다.

만약 payload에 일부 필드 값이 누락된 채로 요청이 오면

누락된 필드 값들은 Null로 대체됩니다.당연히 좋지 않겠죠?

 

예시로 들어보자면

상품 엔티티에 상품 번호, 이름, 가격 필드가 있다고 가정하겠습니다.

상품 정보 수정을 위한 PUT 요청 시 상품 번호, 수정할 이름만 payload에 담아 보내면

기존 상품 데이터에서 이름은 잘 수정이 되지만 가격은 Null로 들어갑니다.

기존에 없는 상품이라면 가격이 Null인 채로 새로 생성이 됩니다.

개쪽이: 아니 그럼 PUT은 언제 쓰는데요???

좋은 예시가 바로 좋아요/싫어요 기능입니다.

상품 엔티티에 상품 번호, 상품 이름, 가격

회원 엔티티에 회원 번호, 회원 이름

따봉 엔티티에 복합키로 상품 번호, 회원 번호를, 그리고 좋아요/싫어요 상태를 필드로 가진다고 가정합시다.

 

맘에 드는 상품을 좋아요/싫어요 한다면

따봉 엔티티에 회원이 해당 상품을 좋아요/싫어요 한다는 데이터가 들어가야겠지요.

그럼 어떻게 서버로 요청해야 될까요?

이럴때!!!

PUT 요청으로 payload에 상품 번호, 회원 번호, 좋아요 상태를 담아 보내는 겁니다.

그렇다면

기존에 따봉 엔티티가 있다면 -> 좋아요/싫어요 상태만 변경되고

기존에 따봉 엔티티가 없다면 -> 새로 생성됩니다.

개쪽이: 엔티티가 있든, 없든 POST 쓰면 되는 거 아닙니까?????

그래도 잘 와닿지 않으신다구요.

그럴 수 있습니다. 저도 많은 글을 봤지만 그래도 많이 헷갈렸어요.

이럴 땐 도메인 관점으로 생각해 보면 좋습니다.

회원이 좋아요를 누른다면 프론트에선 백엔드로 어떤 메소드를 사용해 보내야 할까요?

 

POST는 보통 생성할 때 사용합니다.

수정할 때도 POST로 하는 것이 맞을까요 흠.

목적에 맞게 적절한 Method를 쓰는 것이 중요하다고 생각합니다.

생성 - POST

그럼 수정은 PUT or PATCH 일텐데

이런 경우면 따봉 엔티티랑 잘 안 어울립니다.

따봉 엔티티는 회원이 좋아요를 누르는 순간에 엔티티가 있고 없고를 판단해야 돼요.

현실에서 먼저 생성되는 이벤트가 없다는 뜻입니다.

상품 엔티티는 먼저 생성되는 이벤트가 있죠. (상품등록)

회원 엔티티는 먼저 생성되는 이벤트가 있죠. (회원가입)

그러므로 따봉 엔티티는 누르는 순간에 PUT으로 두 가지 상황을 모두 케어하는 것이 어울립니다.

 

슬슬 감이 오실 것이라고 믿습니다ㅠㅠ 생각보다 어려워요

 

✅ PATCH Method

This specification defines the new HTTP/1.1 [RFC2616] method, PATCH, which is used to apply partial modifications to a resource.
- by RFC

PATCH 요청은 자원에 대한 부분적인 수정을 적용하기 위한 HTTP 메서드입니다.

기존 자원이 반드시 있어야 합니다.

 

이제 바로 위에 예시로 실컷 들어놓은 것을 잠깐 얘기하자면.

상품 엔티티와 회원 엔티티는 생성에 POST를 사용하는 것이 자연스럽습니다.

그러면 처음 들었던 예시인 상품 수정이나 회원 수정은 어떡하나요?

보통 일부분을 수정합니다.

상품 가격을 바꾸는 데 굳이 다른 필드 값을 추가로 보내서 엔티티를 새로 바꿀 필요가 있을까요.

회원 이름을 바꾸는 데 굳이 다른 필드 값을 추가로 보내서 엔티티를 새로 바꿀 필요가 있을까요.

 

그래서 이럴 땐 PUT보단 PATCH가 어울립니다.

나머지는 건들지 않고 일부만 수정하는 상황.

 

🚀 PUT 사용하기

@Entity
public class ZZim {

    private Long id;

    private Long boardId;

    private Long memberId;

    private ZZimType zzimType; // y or n
    
  ...
}

만약 찜하기 엔티티가 있다고 가정합시다.

필드엔 찜 id, 게시판 id, 회원 id, 태그 타입이 있습니다.

어떤 게시판에 대해

누군가가 처음으로 찜을 한다면 생성이 되어야 하고,

생성 이후에 찜을 취소하거나 다시 찜을 한다면 상태가 변해야 합니다.

 

이때 PUT Method가 생성과 수정을 할 수 있으므로 어울립니다.

@PutMapping
public ResponseEntity<Void> update(
        @RequestParam Long boardId,
        @LoginUser User user,
        @RequestBody ZzimRequest request
) {
    zzimService.update(id, user.getId(), request);
    return ResponseEntity.noContent().build();
}
...

게시판 id와 회원 id, 그리고 body에서 찜 타입을 받습니다.

@Transactional
public void update(Long boardId, Long userId, ZzimType zzimType) {
    Zzim zzim = zzimRepository.findByBoardIdAndUserId(boardId, userId)
            .map(z -> z.updateType(zzimType))
            .orElse(new Zzim(zzimId, userId, zzimType));

    zzimRepository.save(zzim);
}

게시판 id와 회원 id로 해당 찜 엔티티가 있는 지 확인 후

있으면 body로 받아온 찜 타입으로 수정합니다.

없으면 새로운 인스턴스를 생성해 받아온 데이터들로 새로운 엔티티를 저장합니다.

 

이렇게 PUT을 적절히 활용하면서 도메인 요구사항에 맞는 API를 만들 수 있습니다.

 

🚀 PATCH 사용하기

제 프로젝트의 일부를 예시로 들겠습니다.

출처: fakerdeft

기업 일부분을 수정하기 위해

프론트에서는 PATCH로 일부분만 payload에 담아 보내게 되고

백엔드에서 보낸 RequestBody를 DTO로 받습니다.

 

출처: fakerdeft

출처: fakerdeft

 

Service에서 id값으로 해당 엔티티를 찾고

DTO를 엔티티에 다시 전달해 엔티티 안에서 변경을 합니다.

없으면 새로 엔티티를 생성하는 그런 과정이 필요하지 않고

이러한 상황은 오로지 수정만 하기 때문에 PATCH가 적절합니다.

 

🚀 결론

제가 말한 것들은

절대 100% 정답은 아닙니다.

왜냐하면 PUT, PATCH뿐만 아니라 다른 HTTP 메서드 역시

특정 행동을 물리적으로 강제할 순 없어요.

하지만 표준이기 때문에 클라이언트와 서버 간 통신 시

혼란이 오지 않도록 정의를 숙지하고 지킬 필요가 있습니다.

 

멱등성 얘기를 하지 않는 이유는

제가 아직 어렵기도 하고 양이 많아서 아래 자료로 대체하겠습니다.

 

다른 레퍼런스들도 꼭 참고하시고 비교해서 정보를 받아들이길 바랍니다.

 

🚀 Reference

• CS 관점에서 멱등성
• PUT & PATCH 멱등성