PATCH와 PUT 요청의 주요 차이점은 무엇입니까?


187

PUTRails 애플리케이션에서 요청을 사용하고 있습니다. 이제 새로운 HTTP 동사 PATCH가 브라우저에 의해 구현되었습니다. 따라서 요청 PATCHPUT요청 의 주요 차이점이 무엇인지, 언제 사용해야하는지 알고 싶습니다 .

답변:


139

HTTP 동사는 아마도 HTTP 프로토콜에 대한 가장 비밀스러운 것들 중 하나 일 것입니다. 그것들이 존재하고 그들 중 많은 수가 있지만 왜 존재합니까?

Rails는 많은 동사를 지원하고 웹 브라우저에서 기본적으로 지원하지 않는 동사를 추가하려고합니다.

http 동사의 전체 목록은 다음과 같습니다. http://annevankesteren.nl/2007/10/http-methods

공식 RFC의 HTTP 패치는 다음과 같습니다. https://datatracker.ietf.org/doc/rfc5789/?include_text=1

패치 요청 엔티티에 기재된 사항의 세트는 요청 - URI에 의해 식별 된 자원에 적용되는 것이 요구 방법. 일련의 변경 사항은 미디어 유형으로 식별되는 "패치 문서"라는 형식으로 표시됩니다. 요청-URI가 기존 자원을 가리 키지 않는 경우, 서버는 수도 등 (논리적으로 널 자원을 수정할 수 있는지 여부) 패치 문서 유형에 따라 및 권한, 새로운 자원을 생성

PUT 요청 과 PATCH 요청 의 차이점 은 서버가 동봉 된 엔터티를 처리하여 Request-URI로 식별되는 리소스를 수정하는 방식에 반영됩니다. A의 PUT의 요청 동봉 엔티티 원 서버에 저장된 상기 자원의 수정 된 버전 인 것으로 간주되고, 클라이언트는 저장된 버전을 교환 할 것을 요구한다. 그러나 PATCH를 사용 하면 동봉 된 엔터티에 현재 원본 서버에있는 리소스를 수정하여 새 버전을 생성하는 방법을 설명하는 지침 세트가 포함됩니다. 패치 방법에 의해 식별 된 자원에 영향을 요청-URI를 , 또한 다른 자원에 부작용이있다. 즉, 새로운 리소스는 PATCH 의 응용 프로그램에 의해 생성되거나 기존 리소스가 수정 될 수 있습니다 .

내가 아는 한, PATCH 동사는 레일 응용 프로그램에서와 같이 사용되지 않습니다 ... 이것을 이해하면 RFC 패치 동사를 사용하여 두 파일간에 diff를 수행 할 때와 같은 패치 명령을 보내야합니다. 전체 엔터티를 다시 보내는 대신 전체 엔터티를 다시 보내는 것보다 훨씬 작은 패치를 보냅니다.

거대한 파일을 편집하고 싶다고 상상해보십시오. 3 줄을 편집합니다. 파일을 다시 보내는 대신 diff를 보내면됩니다. 긍정적 인 측면에서 패치 요청 전송은 파일을 비동기 적으로 병합하는 데 사용될 수 있습니다. 버전 제어 시스템은 PATCH 동사를 사용하여 코드를 원격으로 업데이트 할 수 있습니다.

다른 유스 케이스는 NoSQL 데이터베이스와 다소 관련이 있으며 문서를 저장할 수 있습니다. 서버에서 클라이언트로 데이터를주고받는 데 JSON 구조를 사용한다고 가정하겠습니다. 필드를 삭제하려면 mongodb의 구문과 비슷한 구문을 $ unset 사용할 수 있습니다 . 실제로 mongodb에서 문서를 업데이트하는 데 사용되는 방법은 아마도 json 패치를 처리하는 데 사용될 수 있습니다.

이 예제를 보자 :

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

우리는 다음과 같은 것을 가질 수 있습니다 :

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

마지막으로, 사람들은 HTTP 동사에 대해 원하는 것을 말할 수 있습니다. 진실은 단 하나 뿐이며 RFC에는 진실이 있습니다.


1
RFC 5789는 여전히 제안 단계에 있으며 공식적으로 승인되지 않았으며 현재는 '이라 타 존재'로 표시되어 있습니다. 이 '모범 사례'는 논란의 여지가 많으며 기술적으로 PATCH는 아직 HTTP 표준의 일부가 아닙니다. 여기서 유일한 사실은 RFC가 받아 들여지지 않기 때문에하지 말아야한다는 것입니다.
fishpen0

3
여전히 제안에 있어도 사용해서는 안된다는 의미는 아닙니다. 이 경우에도 여전히 제안에있는 웹 소켓 및 기타 많은 rfc를 사용할 수 없습니다. 제안을 구현하는 것은 다른 사람이 구현하지 않는 완전히 맞춤화 된 것을 구현하는 것보다 100 배 더 좋습니다.
Loïc Faure-Lacroix

BS. "제안 중"이 아니며 HTTP 표준의 일부입니다 (표준, RFC 7231은 메소드에 대한 IANA 레지스트리에 위임하고 PATCH가 여기에 나열 됨).
Julian Reschke

@JulianReschke이 RFC의 두 번째 줄을 읽으면 여전히 PROPOSED STANDARD 로 표시되어 있음을 알 수 있습니다 . 따라서 패치 방법은 아직 제안되지 않았습니다. rfc는 여기 btw입니다. tools.ietf.org/html/rfc5789 및 rfc7231도 표준으로 제안됩니다 . 예를 들어 RFC821을 보면 인터넷 표준으로
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... 제 말이 아닙니다. 제안 된 표준은 위에서 설명한대로 제대로 구현 할 수 없다는 것을 의미하지는 않습니다. 그것은 구현하기에 충분히 안정적이지 않다는 것을 의미하지는 않지만 인터넷 표준으로 표시되어 있지 않으면 여전히 제안 중입니다 ... 어떻게 논쟁하고 있는지 잘 모르겠습니다. '제안 표준'이라고하며 제안 이외의 다른 의미는 없습니다. 제안 된 표준을 사용할 수 있다고 주장하려는 경우. 내가 쓴 그대로입니다.
Loïc Faure-Lacroix

104

Google에서 몇 시간을 보냈고 여기 에서 답을 찾았습니다 .

PUT => 사용자가 레코드의 일부 또는 전부를 업데이트 할 수있는 경우 PUT을 사용하십시오 (사용자는 업데이트 대상을 제어 함)

PUT /users/123/email
new.email@example.org

PATCH => 사용자가 부분 레코드 만 업데이트 할 수있는 경우 ( 예 : 이메일 주소 만 (응용 프로그램이 업데이트 할 수있는 항목을 제어)) PATCH를 사용하십시오.

PATCH /users/123
[description of changes]

Patch

PUT이 방법은 더 많은 대역폭이 필요하거나 부분적으로 전체 리소스를 처리합니다. 그래서 PATCH대역폭을 줄이기 위해 도입되었다.

PATCH 에 대한 설명

PATCH 안전하지 않고 dem 등원이 아니며 다른 자원에 대한 전체 및 부분 업데이트 및 부작용을 허용하는 방법입니다.

PATCH 동봉 된 엔터티는 원본 서버에 현재 상주하는 리소스를 수정하여 새 버전을 생성하는 방법을 설명하는 일련의 지침을 포함하는 방법입니다.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

여기에 넣어 및 패치에 대한 자세한 내용은


7
이 패치가 왜 안전하지 않습니까?
Bishisht Bhatta

1
PATCHPOST, PUT그것은 당신의 데이터를 수정하기 때문에 등을하는 것은, "안전"아니다 (부작용이있다). 부작용없이 엔드 포인트를 여러 번 호출 할 수있는 등 (안전한 방법) GET과 비교합니다 OPTIONS.
emix

1
PATCH는 밴드로만 저장하기 위해 도입되지 않았습니다. RFC 5789는 다음과 같이 말합니다.> "상호 운용성을 개선하고 오류를 방지하려면 새로운 방법이 필요합니다." 다중 페이로드 환경에서 나머지 페이로드를 포함하는 PUT 만 있으면 자원의 다른 속성이 수정 될 위험이 높아집니다. PATCH는 이러한 문제를 해결합니다.
Tomasz Nazar

43

넣어
난 내 변경하려는 경우 first다음 이름을 보내 넣어 업데이트에 대한 요청을

{ "first": "Nazmul", "last": "hasan" } 

그러나 여기에서 문제가있다 put내가 보낼 때 요청 put요청을 내가 모두 두 개의 매개 변수를 전송해야 first하고 last
다시 모든 값을 전송하는 필수 있도록

패치 :
patch요청 말한다. data원하는 것을 보내면 update다른 데이터에 영향을 주거나 변경하지 않습니다.
따라서 모든 값을 다시 보낼 필요가 없습니다. 그냥 내 이름을 업데이트하고 싶기 때문에 업데이트 할 first이름 만 보내면됩니다 .


13

HTTP 프로토콜의 POST, PUT 및 PATCH 메소드의 차이점은 다음과 같습니다.

게시하다

HTTP.POST 메소드는 항상 서버에서 새 자원을 작성합니다. 비등 전성 요청입니다. 즉, 사용자가 동일한 요청을 두 번 누르면 제한이없는 경우 다른 새 리소스가 만들어집니다.

http post 메소드는 데이터베이스에 항상 새 레코드를 작성하는 SQL의 INSERT 쿼리와 같습니다.

예 : POST 메소드를 사용하여 백엔드 서버가 새 자원의 자원 ID를 결정하는 새 사용자, 순서 등을 저장하십시오.

놓다

HTTP.PUT 메소드에서 자원은 먼저 URL에서 식별되며 존재하는 경우 갱신되며 그렇지 않으면 새 자원이 작성됩니다. 대상 리소스가 존재하면 해당 리소스를 완전히 새로운 본문으로 덮어 씁니다. 즉, HTTP.PUT 메서드는 리소스를 만들거나 업데이트하는 데 사용됩니다.

http put 메소드는 주어진 레코드가 존재하는지 여부에 따라 레코드를 삽입하거나 업데이트하는 SQL의 MERGE 쿼리와 같습니다.

PUT 요청은 dem 등적입니다. 즉, 동일한 요청을 두 번 두드리면 기존 레코딩이 업데이트됩니다 (새 레코드가 작성되지 않음). PUT 방법에서 리소스 ID는 클라이언트에 의해 결정되고 요청 URL에 제공됩니다.

예 : PUT 방법을 사용하여 기존 사용자 또는 주문을 업데이트하십시오.

반점

HTTP.PATCH 메소드는 델타 업데이트와 같은 자원의 부분 수정에 사용됩니다.

http 패치 방법은 전체 행이 아니라 선택한 열만 설정하거나 업데이트하는 SQL의 UPDATE 쿼리와 같습니다.

예 : PATCH 방법을 사용하여 주문 상태를 업데이트 할 수 있습니다.

패치 / api / users / 40450236 / order / 10234557

요청 본문 : {status : 'Delivered'}


이것은 누구나 put and patch에 관해 읽을 수있는 최악의 설명입니다. 게다가, 이미 많은 좋은 답변을 게시 한 후, 여기에서 귀하의 답변이 다르다고 생각하는 이유는 무엇입니까?
CodeHunter

3

업데이트하는 동안 PUT over PATCH에는 제한이 있습니다. PUT을 사용하려면 하나의 속성 만 변경하더라도 모든 속성을 지정해야합니다. 그러나 PATCH 방법을 사용하면 필요한 필드 만 업데이트 할 수 있으며 모든 필드를 언급 할 필요는 없습니다. PATCH를 사용하면 배열의 값을 수정하거나 속성 또는 배열 항목을 제거 할 수 없습니다.


1

PUTPATCH 방법은 본질적으로 비슷하지만 중요한 차이점이 있습니다.

PUT - PUT 요청에서 동봉 된 엔터티는 서버에 상주하는 리소스의 수정 된 버전으로 간주되며이 수정 된 엔터티로 대체됩니다.

PATCH - PATCH 요청에서 동봉 된 엔터티에는 서버에있는 엔터티가 최신 버전을 생성하도록 수정되는 방법이 포함되어 있습니다.


1

HTTP 용어에 따르면 PUT요청은 데이터베이스 업데이트 문과 같습니다. PUT-기존 리소스를 수정하는 데 사용됩니다 (이전 POSTED). 반면에 PATCH요청은 기존 리소스의 일부를 업데이트하는 데 사용됩니다.

예를 들어 :

고객의 세부 사항:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

우리는 전체 기록으로 업데이트하고 싶습니까? 우리는 그것을 위해 사용해야 Http PUT verb합니다.

같은 :

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

반면에 전체 레코드가 아닌 레코드의 일부만 업데이트하려면 계속 진행하십시오 Http PATCH verb. 같은 :

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

PUT vs POST :

PUT요청을 사용할 때 firstName, lastName, email, phoneNumber와 같은 모든 매개 변수를 보내야합니다. patch요청에서 업데이트하려는 매개 변수 만 보내면 다른 데이터에 영향을 주거나 변경하지 않습니다.

자세한 내용은 https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/ 를 참조하십시오.


0

넣기 및 패치 방법은 비슷합니다. 그러나 레일마다 다른 방식을 사용합니다. 전체 레코드를 업데이트 / 교체하려면 Put 메소드를 사용해야합니다. 특정 레코드를 업데이트하려면 패치 방법을 사용하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.