RESTful API 디자인에서 PUT과 PATCH는 서버의 리소스를 업데이트하는 데 사용되는 두 가지 HTTP 메서드이지만, REST API에서 PUT과 PATCH의 차이점은 업데이트를 수행하는 방법과 각각이 가장 적합한 시나리오에 있습니다. 두 방법 모두 기존 데이터를 수정하도록 설계되었지만 REST API의 PUT 및 PATCH 차이점을 이해하면 개발자가 수행해야 하는 업데이트의 특성에 따라 최선의 선택을 하는 데 도움이 될 수 있습니다. 이 블로그 게시물에서는 PATCH와 업데이트 REST 논쟁에 초점을 맞춰 REST API의 PUT 및 PATCH 차이점을 살펴보고, 각각을 언제 사용해야 하는지 알아보고 다양한 사용 사례에 적합한 방법을 선택하는 데 대한 지침을 제공합니다.
REST API에서 PUT이란 무엇입니까?
REST API에서 PUT과 PATCH의 차이점을 이해하려면 먼저 PUT이 무엇인지 알아야 합니다. 기반 섹션 9.6 RFC 2616, REST API의 PUT 메소드는 동봉된 엔터티가 제공된 Request-URI에 저장되도록 요청합니다.
Request-URI가 이미 존재하는 리소스를 참조하는 경우 포함된 엔터티는 원서버에 있는 엔터티의 수정된 버전으로 간주되어야 합니다. 요청-URI가 기존 리소스를 가리키지 않고 해당 URI가 요청 사용자 에이전트에 의해 새 리소스로 정의될 수 있는 경우 원서버는 해당 URI를 사용하여 리소스를 생성할 수 있습니다.
즉, PUT 메소드는 서버의 전체 리소스를 업데이트하는 데 사용됩니다. 이로 인해 PUT는 리소스를 완전히 교체해야 할 때 자주 사용되는 보다 "완전한" 업데이트가 됩니다.
따라서 PUT은 다음 사용 사례에 가장 적합합니다.
- 전체 리소스 업데이트(예: 모든 새로운 정보로 사용자 프로필 업데이트)
- 전체 항목이나 기록을 교체합니다.
- 리소스의 ID가 명확하고 해당 데이터를 완전히 새로 고쳐야 하는 경우.
다음과 같은 시스템에서는 엘라스틱서치, 데이터 일관성을 보장하려면 멱등성 작업이 필요합니다. 예를 들어 PUT을 사용하여 Elasticsearch에서 문서를 업데이트하면 의도하지 않은 부작용 없이 동일한 요청이 반복될 수 있습니다.
REST API의 패치란 무엇입니까?
이제 REST API의 PUT을 다루었으므로 REST API의 PUT과 PATCH를 비교하기 전에 REST API의 PATCH가 무엇인지, 어떻게 작동하는지 살펴보겠습니다. 정의된 대로 RFC 5789, REST API의 PATCH 메소드는 요청 엔터티에 설명된 변경 사항 집합이 요청-URI로 식별되는 리소스에 적용되도록 요청합니다.
이는 수정해야 하는 데이터만 전송하고 서버는 전체 리소스를 변경하지 않고 해당 변경 사항을 기존 리소스에 적용하는 PUT 및 PATCH REST API 구별과 일치합니다. 개발자는 종종 이러한 증분 변경 사항을 나타내는 패치를 만들어 최소한의 데이터 전송과 효율적인 업데이트를 보장합니다.
이것이 REST API의 PATCH 메소드가 다음 사용 사례에 더 적합한 이유입니다.
- 리소스에서 필드의 하위 집합만 업데이트합니다(예: 사용자의 이메일 주소 또는 전화번호 변경). PATCH API 예제에는 새 이메일만 보내고 다른 필드는 그대로 남겨둘 수 있습니다.
- 데이터 페이로드를 최소화하여 성능을 향상시킵니다.
- 리소스를 완전히 교체하는 대신 점진적으로 업데이트하려는 경우.
- 관련 없는 데이터에 영향을 주지 않고 사용자 이메일 수정과 같은 특정 필드 변경 사항을 캡슐화하는 패치를 만듭니다.
다음과 같은 플랫폼의 경우 헤드리스 CMS 단일 필드 수정과 같은 소규모 업데이트에 PATCH를 사용하여 복잡한 콘텐츠 구조를 처리하는 경우가 많으므로 서버 부하를 줄이고 성능을 향상시킬 수 있습니다.
이 두 가지 방법을 다루면 REST API에 PUT과 PATCH가 무엇인지에 대한 적절한 아이디어가 있어야 합니다. 그러나 REST API의 PUT과 PATCH의 차이점을 알아보기 전에 이 두 가지 방법의 멱등성에 대해 이야기해야 합니다.
PUT의 멱등성과 REST API의 패치 비교
REST API에서 멱등성은 동일한 입력으로 여러 번 반복될 때 동일한 결과를 가져오는 작업의 속성을 나타냅니다. 이는 동일한 요청을 여러 번 실행하면 실행 횟수에 관계없이 서버에 동일한 효과가 있어야 함을 의미합니다. 이는 API의 안정성과 예측 가능성을 보장하는 데 중요합니다. 그러나 REST API의 PUT 및 PATCH 차이점과 어떤 관련이 있습니까?
PUT 방법 및 멱등성
REST API의 PUT 메서드는 지정된 URI의 전체 리소스를 요청에 제공된 데이터로 바꾸도록 설계되었기 때문에 항상 멱등성을 갖습니다. 즉, 동일한 리소스 데이터로 PUT 요청을 여러 번 수행하면 결과는 항상 동일합니다.
PUT이 멱등성이 있는 이유는 무엇입니까? PUT 요청을 하면 본질적으로 서버에 "이 리소스에 대해 내가 원하는 완전하고 정확한 상태입니다."라고 알리는 것입니다. PUT 요청을 한 번 실행하든 여러 번 실행하든 결과 리소스는 항상 동일합니다.
예를 들어 사용자의 이메일 주소를 업데이트하는 시나리오를 생각해 보세요. 동일한 PUT 요청을 여러 번 수행하면 리소스가 매번 동일한 데이터로 대체되므로 결과가 변경되지 않습니다.
예:
| PUT /users/1{“사용자 이름”: “john_doe”,”이메일”: “[email protected]”} |
이 요청을 여러 번 보내면 결과는 항상 동일합니다.
| {“사용자 이름”: “john_doe”,”이메일”: “[email protected]”} |
사용자의 데이터가 이미 이 데이터인 경우에도 요청을 다시 보내도 아무 것도 변경되지 않습니다. 데이터를 동일한 데이터로 대체하므로 요청이 반복되는 횟수에 관계없이 요청의 효과는 동일하게 유지됩니다. 이것이 PUT을 멱등성으로 만드는 이유입니다.
PATCH 방법 및 멱등성
반면 REST API의 PATCH 메서드는 일반적으로 멱등성을 갖지만 유연성이 더 높습니다. 패치를 생성할 때 반복되는 요청으로 인해 의도하지 않은 부작용이 발생하지 않도록 작업이 멱등성(예: 값 설정)인지 확인하세요. PATCH가 멱등성인지 여부는 작업과 수정되는 데이터에 따라 달라집니다.
패치가 멱등성이 있는 이유는 무엇입니까? PATCH 요청의 경우 멱등성은 동일한 패치를 여러 번 적용하면 동일한 결과가 발생함을 의미합니다. 패치 자체가 반복적으로 적용될 때 추가 부작용이나 변경을 일으키지 않는 한 이는 사실입니다. 동일한 데이터로 동일한 패치를 계속 적용하면 첫 번째 적용 이후 결과가 변경되지 않아야 합니다.
예를 들어 사용자의 이메일만 업데이트하는 경우 동일한 PATCH 요청을 반복적으로 보내면 요청이 여러 번 이루어지더라도 처음 이후에는 결과가 변경되지 않습니다. 사용자의 이메일은 동일하게 유지되며 리소스 상태는 변경되지 않습니다.
패치 API 예:
| 패치 /users/1{“이메일”: “[email protected]”} |
이메일이 이미 [email protected]인 경우 이 PATCH를 다시 적용하면 변경 사항이 발생하지 않아 멱등성이 있게 됩니다.
그러나 경우에 따라 PATCH는 멱등성이 아닐 수도 있습니다. 예를 들어, PATCH 작업이 카운터를 수정하거나 목록에 항목을 추가하는 경우(예: 숫자 증가 또는 배열에 추가) 동일한 PATCH를 반복적으로 적용하면 다른 결과가 발생할 수 있습니다. 이는 멱등성 속성을 위반하게 됩니다.
비멱등성 API REST 패치 예:
| 패치 /counter/1{“증분”: 1} |
이 PATCH를 반복적으로 적용하면 카운터가 계속 증가하여 매번 다른 값이 생성됩니다. 각 애플리케이션에 따라 결과가 변경되므로 이는 멱등성이 아닙니다.
이제 필수 사항을 알았으므로 REST API에서 PUT과 PATCH의 차이점을 더 잘 이해하기 위해 몇 가지 예제 시나리오를 살펴볼 수 있습니다.
예제 시나리오: REST API의 PUT 및 PATCH
이론은 제쳐두고 멱등성 작업과 비멱등성 작업을 모두 포함한 예제를 통해 PUT과 PATCH의 차이점을 살펴보겠습니다.
시나리오 1: PUT 요청 – 전체 리소스 교체
전자상거래 시스템에서 제품을 관리하기 위한 API 엔드포인트를 상상해 보세요. 이름, 가격, 설명을 포함하여 제품의 모든 세부정보를 업데이트해야 합니다. 이는 전체 제품 리소스를 대체하는 데 PUT이 사용되는 HTTP 메서드 PUT와 PATCH의 일반적인 예입니다.
초기 제품:
| GET /products/1001{“id”: 1001,”name”: “노트북”,”price”: 999.99,”description”: “강력한 노트북.”} |
제품 가격과 설명을 업데이트하고 싶습니다. 전체 리소스와 함께 PUT 요청을 보냅니다.
PUT 요청:
| PUT /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “할인된 강력한 노트북입니다.”} |
이 PUT 요청을 한 번 또는 여러 번 수행하면 결과는 항상 동일합니다. 제품 세부정보는 새로운 가격과 설명을 반영하여 업데이트되며 매번 동일한 결과가 발생합니다. 이는 PUT의 멱등성을 보장합니다.
결과(PUT 요청 후):
| {“id”: 1001,”name”: “노트북”,”price”: 899.99,”description”: “할인된 강력한 노트북입니다.”} |
시나리오 2: 패치 요청 – 리소스 일부 업데이트
이제 설명과 같은 제품 세부 정보 중 일부만 업데이트하는 PATCH 요청을 고려해 보겠습니다. PATCH API 예: 제품 설명만 변경하고 가격은 변경하지 않으려면 PATCH가 더 나은 선택입니다. 이를 구현하려면 이 API REST PATCH 예제의 설명과 같이 수정이 필요한 필드만 포함하는 패치를 생성합니다.
초기 제품:
| GET /products/1001{“id”: 1001,”name”: “노트북”,”price”: 999.99,”description”: “강력한 노트북.”} |
패치 요청:
| 패치 /products/1001{“description”: “가벼우면서도 강력한 노트북입니다.”} |
이 PATCH 요청을 보내면 설명 필드만 업데이트됩니다. 동일한 PATCH 요청을 여러 번 보내는 경우 첫 번째 업데이트 이후 설명이 변경되지 않고 유지되어 요청이 멱등성을 갖게 됩니다.
결과(패치 요청 후):
| {“id”: 1001,”name”: “노트북”,”price”: 999.99,”description”: “가벼우면서도 강력한 노트북입니다.”} |
동일한 PATCH를 다시 적용하시면 제품 설명은 첫 번째 PATCH 이후와 동일하게 유지됩니다. 결과는 일관성이 있으므로 이 시나리오에서는 PATCH가 멱등성을 갖습니다.
시나리오 3: 패치 요청 - 비멱등성 작업
멱등성이 아닌 PATCH 작업을 살펴보겠습니다. 사용자의 지갑 잔액에 대한 엔드포인트가 있고 잔액을 늘리고 싶다고 가정해 보겠습니다. PUT과 PATCH의 차이점 예시는 다음과 같습니다. PATCH는 매번 잔액에 값을 추가합니다.
초기 지갑:
| GET /users/1/wallet{“id”: 1,”balance”: 100.00} |
패치 요청:
| 패치 /users/1/wallet{“증분”: 50.00} |
이 PATCH 요청은 지갑 잔액을 $50만큼 증가시킵니다. 이 PATCH 요청을 여러 번 보내면 각 PATCH마다 잔액이 계속 증가하므로 매번 다른 결과가 발생합니다. 동일한 PATCH를 반복적으로 적용하면 다른 결과가 발생하므로 이는 멱등성이 아닙니다.
결과(첫 번째 패치 요청 후):
| {“id”: 1,”잔고”: 150.00} |
결과(두 번째 패치 요청 후):
| {“ID”: 1,”잔고”: 200.00} |
여기서 PATCH는 동일한 데이터에 대한 반복 요청이 다른 결과를 생성하므로 멱등성이 아닙니다.
요약: REST API에서 PUT과 PATCH의 주요 차이점
REST API에서 PUT과 PATCH의 주요 차이점은 업데이트를 처리하는 방법입니다. PUT은 전체 리소스를 대체하므로 누락된 필드가 모두 지워져 데이터 손실이 발생할 수 있습니다. 이것이 바로 개발자가 변경되지 않은 필드를 덮어쓰는 것을 방지하고 데이터 무결성을 유지하기 위해 부분 업데이트용 패치를 만드는 이유입니다.
이렇게 하면 부분 업데이트에 대해 PATCH가 더 효율적이 됩니다. PATCH API의 예는 전체 사용자 데이터가 필요한 PUT 요청과 달리 사용자의 이메일만 업데이트하려는 경우 패치를 생성하면 이메일 필드만 전송된다는 것입니다.
PUT을 사용하면 전체 데이터 페이로드가 필요합니다. 즉, 모든 필드를 전송해야 하며 누락된 필드는 모두 삭제됩니다. 그러나 PATCH는 업데이트해야 하는 필드만 전송하므로 특히 최소한의 변경으로 대규모 리소스의 경우 더욱 효율적입니다. REST API의 PATCH 메서드를 사용하면 더 집중적이고 작은 요청을 허용하여 데이터 전송을 줄일 수 있습니다.
PUT과 PATCH는 모두 멱등성을 갖습니다. 이는 동일한 요청을 반복하면 동일한 결과가 발생함을 의미합니다. 그러나 PUT은 전체 리소스를 대체하므로 예측 가능성이 더 높습니다. 지정된 필드만 수정하는 데 PATCH를 사용하는 경우 서버에서 업데이트를 처리하는 방법에 따라 다른 결과가 발생할 수 있습니다.
예를 들어 PATCH가 카운터를 증가시키는 경우 반복적인 요청으로 인해 다른 결과가 발생할 수 있습니다. 그럼에도 불구하고 PATCH API 작업은 멱등성을 갖도록 설계될 수도 있습니다.
결론적으로 REST API의 PUT과 PATCH 차이는 업데이트의 성격으로 귀결됩니다. PATCH는 부분 변경을 위한 것이고 PUT는 완전한 리소스 교체를 위한 것입니다. 둘 다 멱등성을 갖지만 PATCH는 더 복잡할 수 있습니다.
최종 생각
PUT과 PATCH는 모두 REST API 디자인의 기본 HTTP 메서드이지만 서로 다른 목적을 제공합니다. 이것이 REST API의 PUT과 PATCH 차이점의 핵심입니다. 이 문서의 앞부분에서 다룬 예시를 통해 PUT과 PATCH의 차이점을 이해하면 API의 효율성, 명확성, 기능을 크게 향상시킬 수 있습니다. 사용 사례에 따라 올바른 방법(PATCH 대 업데이트 REST)을 선택하면 API를 더 효율적이고 유지 관리가 용이하며 사용자 친화적으로 만들 수 있습니다. 성능 및 데이터 무결성에 미치는 영향과 함께 전체 또는 부분 업데이트의 특성을 항상 고려하고 요구 사항에 가장 적합한 방법을 선택하십시오.
