HTTP PUT vs PATCH: 차이점은 무엇인가요?

HTTP 요청은 현대 웹 개발의 핵심입니다. 이것들은 우리가 API와 상호작용하고 서버에서 데이터를 검색할 수 있게 해줍니다. 가장 일반적으로 사용되는 HTTP 요청 두 가지는 PUT과 PATCH입니다. 이 블로그 글에서는 이 두 요청의 차이점과 사용할 때를 살펴보겠습니다.

💡

Apidog를 사용하여 HTTP 요청, 포함하여 PUT 및 PATCH를 쉽게 수행함으로써 API를 신속하게 테스트하고 디버그할 수 있습니다. 지금 무료로 다운로드하여 시작하세요!

버튼

API란 무엇인가?

PUT과 PATCH의 차이점에 대해 살펴보기 전에, 먼저 API가 무엇인지 정의해 봅시다. API는 응용 프로그램 프로그래밍 인터페이스를 의미합니다. 이는 서로 다른 응용 프로그램이 서로 통신할 수 있도록 하는 정의된 규칙의 집합입니다. API는 시스템 간 데이터 전송을 처리하는 중개 계층 역할을 하며, 기업이 외부 타사 개발자, 비즈니스 파트너 및 회사 내부 부서에 애플리케이션 데이터와 기능을 열 수 있게 합니다.

API 내의 정의와 프로토콜은 기업이 일상 운영에서 사용하는 다양한 응용 프로그램을 연결하는 데 도움이 되어 직원의 시간을 절약하고 협업과 혁신을 방해하는 장벽을 허물어 줍니다. 개발자에게 API 문서는 응용 프로그램 간의 통신을 위한 인터페이스를 제공하여 응용 프로그램 통합을 단순화합니다. API는 강력하고 탄력적이며 안전하고 사용자 요구를 충족할 수 있는 애플리케이션을 만들기 위해 작은 코드 조각 간의 간격을 연결하는 데 사용됩니다.

HTTP 메서드 개요

HTTP (하이퍼텍스트 전송 프로토콜)은 HTML과 같은 하이퍼미디어 문서를 인터넷을 통해 전송하는 데 사용되는 응용 프로그램 레이어 프로토콜입니다. 이는 웹 브라우저와 웹 서버 간의 통신을 촉진하지만 다른 용도로도 사용될 수 있습니다. HTTP는 클라이언트-서버 프로토콜로 작동하며 요청은 일반적으로 수신측인 웹 브라우저에 의해 시작됩니다. 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 포함하여 서로 다른 하위 문서에서 재구성됩니다.

클라이언트와 서버는 개별 메시지를 교환하여 통신합니다(지속적인 데이터 스트림이 아닌). 클라이언트(보통 웹 브라우저)에 의해 전송된 메시지는 요청이라고 하고, 서버에 의해 응답으로 전송된 메시지는 응답이라고 합니다. HTTP는 시간이 지남에 따라 발전한 확장 가능 프로토콜로, TCP를 통해 또는 TLS 암호화된 TCP 연결을 통해 전송됩니다. 확장 가능성 덕분에 HTML 문서 검색뿐만 아니라 이미지 및 비디오를 검색하거나 HTML 폼 결과와 같은 콘텐츠를 서버에 포스트하는 데도 사용됩니다. 또한, HTTP를 사용하여 문서의 일부를 가져와 웹 페이지를 필요에 따라 업데이트할 수 있습니다.

HTTP PUT 소개

HTTP PUT은 새로운 리소스를 생성하거나 클라이언트가 알고 있는 대상 리소스의 표현을 덮어쓰는 데 사용되는 HTTP 메서드입니다. 이는 서버에 리소스를 추가하는 데 사용되는 HTTP POST 메서드와 유사합니다.

그러나 POST와는 달리, PUT은 멱등성을 가지고 있으며, 이는 한 번 또는 연속적으로 여러 번 호출하더라도 같은 결과를 가지며(즉, 부작용이 없음) 의미합니다. 요청 URI가 이미 존재하는 리소스를 참조하는 경우, 포함된 엔티티는 원래 서버에 있는 것의 수정된 버전으로 간주되어야 합니다.

HTTP PATCH 이해하기

HTTP PATCH는 기존 리소스에 부분 수정을 할 때 사용되는 요청 메서드입니다. 이는 클라이언트가 알고 있는 대상 리소스의 표현을 생성하거나 덮어쓰는 HTTP PUT 메서드와 유사합니다. 그러나 PUT과는 달리, PATCH는 리소스의 일부만 수정하는 데 사용되며, PUT은 전체 리소스를 교체합니다.

PATCH 메서드는 요청된 리소스에 적용할 변경 사항 목록을 포함하는 엔티티를 제공합니다. 변경 사항 목록은 PATCH 문서의 형태로 제공됩니다. PATCH 메서드는 부분 JSON 데이터를 사용하여 리소스를 업데이트하는 데 사용됩니다.

HTTP PUT을 사용할 때

HTTP PUT은 새로운 리소스를 생성하거나 클라이언트가 알고 있는 대상 리소스의 표현을 덮어쓰는 데 사용됩니다. 이는 리소스 교체에 대해 완전한 제어가 필요한 경우에 적합합니다.

HTTP PUT과 HTTP POST의 차이점은 PUT은 멱등성을 가지며, 이는 한 번 또는 연속적으로 여러 번 호출하더라도 같은 결과를 가져오며(즉, 부작용이 없음) 의미합니다. 요청 URI가 이미 존재하는 리소스를 참조하는 경우, 포함된 엔티티는 원래 서버에 있는 것의 수정된 버전으로 간주되어야 합니다.

HTTP PUT은 기존 리소스를 새로운 데이터로 완전히 교체하고자 할 때 가장 효과적입니다. 예를 들어, 이름, 이메일, 전화번호 등의 여러 필드를 포함하는 사용자 프로필이 있고 이 모든 필드를 한 번에 업데이트하고자 한다면 PUT 요청을 사용해야 합니다.

다음은 서버에 있는 기존 파일의 내용을 업데이트하기 위해 HTTP PUT 요청을 사용하는 예입니다:

PUT /example.html HTTP/1.1
Host: sample.com
Content-Type: text/html
Content-Length: 20

<p>업데이트된 파일</p>

이 예에서 PUT 요청은 /example.html에 위치한 리소스로 전송됩니다. Content-Type 헤더는 요청 본문이 HTML 형식임을 지정합니다. Content-Length 헤더는 요청 본문의 크기를 나타내며, 이 경우 20바이트입니다. 요청 본문에는 파일에 대한 새 내용이 포함되어 있으며, 이는 '업데이트된 파일'이라는 텍스트가 포함된 간단한 HTML 단락 요소입니다. 파일이 존재하고 서버가 요청을 성공적으로 처리하면 example.html의 내용이 요청 본문에 제공된 새 내용으로 교체됩니다.

HTTP PATCH를 사용할 때

HTTP PATCH는 기존 리소스에 부분 수정을 하는 데 사용됩니다. 이는 리소스의 일부만 업데이트해야 하는 경우에 적합하며, PUT은 전체 리소스를 교체합니다.

예를 들어, 리소스의 특정 필드 하나를 업데이트할 때 전체 리소스를 보내는 것은 번거롭고 불필요한 대역폭을 사용하게 됩니다. PATCH 요청은 리소스를 수정하는 방법에 대한 지침 세트로 간주됩니다.

HTTP PATCH는 기존 리소스에서 단일 필드 또는 몇 개의 필드를 업데이트하고자 할 때 가장 잘 사용됩니다. 예를 들어, 이름, 이메일, 전화번호 등의 여러 필드를 포함하는 사용자 프로필이 있고, 이메일 필드만 업데이트하고자 한다면 PATCH 요청을 사용해야 합니다.

다음은 시스템에서 사용자의 이메일 주소를 업데이트하기 위해 HTTP PATCH 요청을 사용하는 예입니다:

PATCH /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
If-Match: "e0023aa4e"

{
  "email": "newemail@example.com"
}

이 예에서 PATCH 요청은 /api/users/123에 위치한 리소스로 전송됩니다. Content-Type 헤더는 요청 본문이 JSON 형식임을 지정합니다. If-Match 헤더는 업데이트가 제공된 eTag (리소스의 버전 식별자)와 일치할 때만 적용되도록 보장하는 데 사용됩니다. 요청 본문에는 적용할 변경 사항이 포함되며, 이 경우 사용자의 이메일 주소 업데이트입니다. 서버는 이 요청을 처리하고 사용자 정보를 업데이트합니다. 성공하면 서버는 200 OK 상태 코드로 응답하고, 경우에 따라 업데이트된 리소스를 응답 본문에 포함할 수 있습니다.

HTTP PUT과 PATCH의 차이점

HTTP PUT과 HTTP PATCH는 모두 HTTP 메서드로 리소스를 수정하는 데 사용되지만, 리소스를 업데이트하는 방법에서 차이가 있습니다.

HTTP PUT은 새로운 리소스를 생성하거나 클라이언트가 알고 있는 대상 리소스의 표현을 덮어쓰는 데 사용됩니다. 이는 리소스 교체에 대해 완전한 제어가 필요한 경우에 적합합니다. 요청 URI가 이미 존재하는 리소스를 참조하는 경우, 포함된 엔티티는 원래 서버에 있는 것의 수정된 버전으로 간주되어야 합니다.

HTTP PATCH는 기존 리소스에 부분 수정을 하는 데 사용됩니다. 이는 리소스의 일부만 업데이트해야 하는 경우에 적합하며, PUT은 전체 리소스를 교체합니다. PATCH 메서드는 요청된 리소스에 적용할 변경 사항 목록을 포함하는 엔티티를 제공하며, 변경 사항 목록은 PATCH 문서의 형태로 제공됩니다.

HTTP PUT과 PATCH의 주요 차이점은 요청에서 전송되는 데이터의 양입니다. PUT은 전체 리소스를 전송하는 반면, PATCH는 업데이트될 필드만 전송합니다. 이는 PUT 요청이 PATCH 요청보다 대역폭과 처리 능력 측면에서 더 비싸다는 것을 의미합니다.

HTTP PUT의 장점

HTTP PUT은 서버에서 기존 리소스를 업데이트하거나 교체하는 데 사용되는 요청 메서드입니다. HTTP PUT을 사용할 때의 이점 중 일부는 다음과 같습니다:

멱등성: HTTP PUT은 멱등성 메서드로, 동일한 요청을 여러 번 수행해도 부작용이 발생하지 않습니다.
원자성: HTTP PUT은 원자적 작업으로, 완전히 성공하거나 완전히 실패합니다. 이는 여러 필드를 가진 리소스를 업데이트할 때 유용합니다.
일관된 인터페이스: HTTP PUT은 RESTful 웹 서비스의 일관된 인터페이스 제약 조건을 따르므로 사용하기 쉽고 이해하기 쉽습니다.
캐싱: HTTP PUT 요청은 프록시와 같은 중개자에 의해 캐시될 수 있어, 네트워크 트래픽을 줄이고 성능을 향상시키는 데 도움이 됩니다.

HTTP PATCH의 장점

HTTP의 PATCH 메서드는 서버에서 리소스를 부분적으로 업데이트하는 데 사용됩니다. 이는 전체 리소스를 보내는 대신 업데이트해야 할 데이터만 보낼 수 있게 해줍니다. 이는 전체 리소스를 다시 전송하지 않고 리소스에 대한 작은, 특정 변경을 수행하고자 할 때 유리합니다.

HTTP PATCH 메서드를 사용할 때의 장점은 다음과 같습니다:

효율성: PATCH는 변경해야 할 사항만 보내므로 네트워크 자원을 보다 효율적으로 사용할 수 있으며, 전송되는 데이터 양을 줄입니다.
부분 업데이트: PATCH를 사용하면 리소스의 특정 부분만 업데이트할 수 있어, 나머지 리소스에는 영향을 주지 않으며, 업데이트에 대한 세분화된 제어를 제공합니다.
멱등성: 적절히 사용하면 PATCH 요청은 멱등성입니다. 즉, 여러 개의 동일한 요청이 단일 요청과 동일한 결과를 생성하여 의도치 않은 부작용의 위험을 줄입니다.

이러한 장점 덕분에 HTTP PATCH는 리소스 데이터의 하위 집합만 업데이트해야 하는 특정 사용 사례에 특히 유용합니다.

HTTP PUT 및 HTTP PATCH 요청을 보내기 위해 Apidog를 사용하는 방법

Apidog는 API 작업을 간소화하는 통합 협업 플랫폼입니다. Postman, Swagger, Mock 및 JMeter와 같은 도구의 기능을 결합하여 API 문서화, 디버깅, 모킹 및 자동화된 테스트를 위한 종합 솔루션을 제공합니다.

버튼

Apidog를 사용하면 이미 문서화된 API를 다시 정의할 필요 없이 HTTP 요청을 보내고 API를 테스트 및 디버깅할 수 있습니다. Apidog를 사용하여 PUT 및 PATCH 요청을 보내는 과정에는 몇 가지 단계가 포함됩니다.

Apidog를 사용하여 HTTP PUT 요청 보내기

Apidog로 HTTP PUT 요청을 보내려면 다음 단계를 따르십시오:

Apidog 열기: Apidog를 열고 새 요청을 생성합니다.

2. HTTP 메서드 지정: 요청의 HTTP 메서드로 PUT을 선택합니다.

3. URL 입력: 업데이트할 리소스의 URL을 입력하고 Content-Type 또는 Authorization과 같은 필요한 헤더를 포함시키고 요청 본문에 보낼 데이터 추가합니다. json 매개변수를 사용하여 JSON 데이터를 보내거나 data 매개변수를 사용하여 폼 인코딩 데이터를 보낼 수 있습니다.

4. 요청 보내기: 요청을 설정한 후 서버에 전송합니다.

PUT 요청에 대한 서버의 응답을 확인하고 이를 적절하게 처리합니다.

Apidog를 사용함으로써 서로 다른 시스템 간의 데이터 일관성을 유지하고 API 개발이 API 문서와 엄격히 일치하도록 하여 보다 효율적인 협업과 불일치 감소를 이끌 수 있습니다.

버튼

Apidog를 사용하여 HTTP PATCH 요청 보내기

Apidog 열기: Apidog 애플리케이션을 시작하고 애플리케이션 내에서 새 요청을 생성합니다.

2. HTTP 메서드 선택: HTTP 메서드 목록에서 PATCH를 선택합니다.

3. URL 입력: PATCH 요청을 보낼 엔드포인트 URL을 입력하고 필요할 경우 헤더를 추가하며 요청 본문에는 부분적으로 업데이트할 데이터를 포함합니다.

요청을 실행하고 서버의 응답을 기다립니다.

서버의 응답을 분석하여 PATCH 요청이 성공했는지 확인합니다.

버튼

HTTP PUT 및 HTTP PATCH 요청을 사용할 때의 모범 사례

PUT 및 PATCH와 같은 HTTP 메서드를 사용할 때 API가 신뢰할 수 있고 효율적이며 사용하기 쉽도록 보장하기 위해 모범 사례를 따르는 것이 중요합니다. PUT 및 PATCH 요청을 사용할 때의 모범 사례는 다음과 같습니다:

HTTP PUT 요청을 사용할 때의 모범 사례

전체 업데이트에는 PUT 사용: 리소스를 완전히 업데이트하고자 할 때 PUT을 사용해야 합니다. 이는 요청 본문에 제공된 페이로드로 전체 리소스를 교체합니다.
멱등성 보장: PUT 요청은 멱등성을 가져야 하며, 여러 개의 동일한 요청이 단일 요청과 동일한 효과를 가져야 합니다.
URL에 리소스 포함: URL에는 업데이트할 리소스의 식별자가 포함되어야 합니다.

HTTP PATCH 요청을 사용할 때의 모범 사례

부분 업데이트에는 PATCH 사용: PATCH는 부분 업데이트에 사용해야 하며, 즉 리소스의 특정 필드만 업데이트해야 할 때 사용해야 합니다.
비 멱등성 적절히 처리: PATCH 요청은 멱등성을 요구하지 않습니다. 구현이 멱등적이라면, 그에 따라 작동해야 합니다.
델타 형식 사용: 전체 리소스 대신 리소스에 적용하고자 하는 변경 사항(델타)만 전송합니다.

HTTP PUT 및 HTTP PATCH 사용을 위한 일반적인 모범 사례

입력 유효성 검사: PUT 및 PATCH 요청 모두의 입력 데이터를 항상 검증하여 잘못된 데이터 업데이트를 방지합니다.
동시성 제어를 위해 ETag 사용: 동시 업데이트를 처리하고 "잃어버린 업데이트" 문제를 피하기 위해 ETag를 구현합니다.
적절한 상태 코드 반환: 요청 결과를 나타내기 위해 HTTP 상태 코드를 올바르게 사용합니다(예: 200 OK, 204 No Content, 400 Bad Request).
API 문서화: PUT 및 PATCH 엔드포인트의 예상 동작을 명확하게 문서화하며, 필수 필드와 검증 규칙을 포함합니다.

결론

결론적으로, HTTP PUT 및 PATCH는 서버의 리소스를 업데이트하는 데 사용되는 중요한 HTTP 요청입니다. PUT은 기존 리소스를 새로운 데이터로 완전히 교체하고자 할 때 가장 효과적이며, PATCH는 기존 리소스에서 단일 필드 또는 몇 개의 필드를 업데이트하고자 할 때 가장 잘 사용됩니다. 두 요청은 각각 장점과 단점이 있으며, 선택은 특정 사용 사례에 따라 달라집니다.

Apidog를 사용하면 API를 테스트하고 디버그하기 위해 HTTP 요청을 쉽게 보낼 수 있습니다.

버튼