패치(HTTP)

PATCH (HTTP)
HTTP
HTTP logo.svg
요구 방식
헤더 필드
응답 상태 코드
보안 접근 제어 방법
보안 취약성

컴퓨팅에서 PATCH 메서드는 기존 [1]리소스를 부분적으로 변경하기 위한 HTTP 요청 메서드입니다.PATCH 메서드는 HTTP Uniform Resource Identifier(URI)[1]를 사용하여 요청된 리소스에 적용되는 변경 목록을 포함하는 엔티티를 제공합니다.변경 목록은 패치 [1]문서 형식으로 제공됩니다.요청된 리소스가 없는 경우 서버는 패치 문서 미디어 유형 및 사용 [1]권한에 따라 리소스를 생성할 수 있습니다.패치 문서에 설명된 변경은 의미론적으로 잘 정의되어야 하지만 [2]패치되는 리소스와 다른 미디어 유형을 가질 수 있습니다.XML, JSON 등의 언어를 사용하여 패치 문서의 변경 내용을 설명할 수 있습니다.

패치 이력

HTTP 프로토콜에 정의된 의미론에 따라 GET, PUT 및 POST 메서드는 리소스의 완전한 표현을 사용해야 합니다.리소스 생성 또는 교체에 사용할 수 있는 PUT 방법은 유용하지 않으며 전체 업데이트에만 사용할 수 있습니다.기존 Ruby on Rails 응용 프로그램에서 사용되는 편집 양식에서는 상위 리소스에 부분 업데이트를 적용하여 새로운 리소스를 생성해야 합니다.이 요건에 따라 [3][4]2010년에 HTTP 프로토콜에 PATCH 메서드가 추가되었습니다.

PUT vs 패치 vs POST

HTTP는 World Wide Web의 데이터 통신 기반입니다.이는 사용자가 CRUD 작업을 수행하기 위해 서버와 통신할 수 있도록 도와주는 요청-응답 프로토콜입니다.HTTP는 자원을 [5]작성 또는 갱신하기 위한 PUT, POST, PATCH 등의 다양한 요청 방법을 정의합니다.

PUT 방식과 PATCH 방식의 주요 차이점은 PUT 방식은 요청된 리소스의 원래 버전을 대체하는 수정된 버전을 제공하기 위해 요청 URI를 사용하는 반면 PATCH 방식은 리소스를 수정하기 위한 일련의 명령을 제공한다는 것입니다.PATTCH 문서가 PUT 메서드에 의해 전송된 리소스의 새 버전 크기보다 큰 경우 PUT 메서드가 [1]선호됩니다.

POST 메서드는 리소스에 부분 업데이트를 보내는 데 사용할 수 있습니다.POST 메서드와 Patch 메서드의 주된 차이점은 POST 메서드는 어플리케이션을 지원하도록 기술되어 있거나 어플리케이션이 그 시멘틱스를 지원하는 경우에만 사용할 수 있는 반면 Patch 메서드는 일반적인 방법으로 사용할 수 있으며 어플리케이션 지원이 필요하지 않습니다.PATCH 방식을 사용한 결과를 알 수 없는 경우 POST 방식을 사용하는 것이 좋습니다.[1][6]

리소스 패치 적용

PATCH 메서드는 [1]atomic입니다.PATCH 메서드로 지정된 모든 변경이 적용되거나 서버에 [1]의해 변경된 내용이 적용되지 않습니다.패치가 정상적으로 적용되었는지 여부를 확인하는 방법은 여러 가지가 있습니다.예를 들어 'diff' 유틸리티를 파일의 이전 버전과 최신 버전에 적용하여 차이점을 찾을 수 있습니다.[1]

캐시된 패치 응답은 오래된 것으로 간주됩니다.PATCH [1]요구에 이은 GET 요구와 HEAD 요구에만 사용할 수 있습니다.

패치 문서의 엔티티 헤더는 패치 문서에만 적용 가능하며 요청된 [1]리소스에는 적용할 수 없습니다.

패치 문서의 표준 형식은 없으며 리소스 유형에 따라 다릅니다.서버는 수신된 패치 문서가 요청된 [1]리소스에 적합한지 확인해야 합니다.

JSON 패치 문서는 다음과 같습니다.

[   { "op": 「추가", "패스": "/카운트", "값": 1 } ]

"op"은 리소스에서 수행된 작업을 나타냅니다."path"는 수정되는 리소스를 나타냅니다."value"는 기존 [7]리소스에 추가되는 양을 나타냅니다.패치 문서의 변경사항을 적용하기 전에 서버는 수신된 패치 문서가 요청된 리소스에 적합한지 확인해야 합니다.PATCH 요구가 성공하면 204 [8]응답이 반환됩니다.

XML 패치 문서는 다음과 같습니다.

<add sel="doc/user[@email='xyz@abc.com']" type="@address"> ABC Road </add>

요소 <user>는 'email' 속성을 사용하여 검색됩니다.값이 "ABC Road"인 새로운 속성 "address"가 <user> [9]요소에 추가됩니다.

예

단순한 패치 요청 예시

  PATCH /example.txt HTTP/1.1호스트: www.example.com Content-Type: application/private If-Match: "c0b42b66e" Content-Length: 120 [변경사항: 리소스 예에서 수행해야 하는 모든 변경을 포함하는 패치 문서]txt]

기존 텍스트 파일에 대한 패치 응답 성공:

  HTTP/1.1 204 No ContentContent-Location: /example.txt ETag: "c0b42b66f"

응답 204는 요청이 정상적으로 [10]처리되었음을 의미합니다.

PUT와 PATCH의 트레이드오프

PUT 방식을 사용하면 리소스에 [citation needed]몇 가지 변경만 적용하면 되는 경우 PACH 방식에 비해 대역폭이 더 많이 소비됩니다.단, PATCH 방식을 사용할 경우 보통 서버에서 리소스를 가져오고 원본 파일과 새 파일을 비교하며 다른 파일을 만들고 보냅니다.서버 측에서는 서버가 diff 파일을 읽고 변경해야 합니다.이것은 PUT 방식에 [11]비해 많은 오버헤드를 수반합니다.한편, PUT 방식에서는 PUT 전에 GET을 실행해야 하며, GET 요구와 PUT 요구 간에 리소스가 변경되지 않도록 하는 것은 어렵습니다.

주의.

패치 방식은 RFC 2616의 의미에서는 '안전'하지 않습니다.리소스를 변경할 수 있습니다.[1]URI에 기재되어 있는 것에 한정되는 것은 아닙니다.

PATCH 메서드는 무의미합니다.조건부 [1]요청을 사용하여 유휴 상태로 만들 수 있습니다.클라이언트가 리소스에 조건부 요청을 하는 경우 해당 리소스에 마지막으로 액세스한 이후 리소스가 업데이트되지 않은 경우에만 요청이 성공합니다.또한 리소스에 대한 일부 업데이트는 특정 [1]기준점에서만 수행할 수 있으므로 리소스 손상을 방지하는 데도 도움이 됩니다.

에러 처리

다음 오류 중 하나가 발생하면 패치 요청이 실패할 수 있습니다.

잘못된 형식의 패치 문서

패치 문서의 [1]형식이 필요에 따라 지정되지 않은 경우 서버는 400(잘못된 요청) 응답을 반환합니다.

지원되지 않는 패치 문서

서버는 클라이언트가 서버에 의해 구현되지 않은 형식으로 패치 문서를 보낼 때 지원되는 미디어 유형을 포함하는 Accept-Patch 응답 헤더와 함께 415(지원되지 않는 미디어 유형) 응답을 반환합니다.그러면 클라이언트가 보낸 패치 문서를 요청된 [1]리소스에 적용할 수 없음을 클라이언트에 알립니다.

처리할 수 없는 요청

서버는 서버가 패치 문서를 이해하지만 요청된 리소스를 수정할 수 없는 경우 422(처리할 수 없는 도면요소) 응답을 반환합니다. 이 응답으로 인해 리소스가 비활성화되거나 다른 오류 [1]상태가 발생합니다.

리소스를 찾을 수 없습니다.

서버는 존재하지 않는 [1]리소스에 패치 문서를 적용할 수 없는 경우 404(찾을 수 없음) 응답을 반환합니다.

경합 상태

서버가 리소스의 [1]현재 상태에 패치를 적용할 수 없는 경우 서버는 409(Conflict) 응답을 반환합니다.

경합하는 수정

If-Match 헤더 또는 If-Unmodified-Since 헤더를 사용하여 클라이언트가 제공한 사전 조건이 실패하면 서버는 412(Precondition Failed) 응답을 반환합니다.전제조건을 지정하지 않고 경합하는 변경이 있는 경우 서버는 409([1]Conflict) 응답을 반환합니다.

동시 수정

특정 리소스에 대한 패치 요청을 특정 순서로 적용해야 하며 서버가 동시 패치 [1]요청을 처리할 수 없는 경우 서버는 409(Conflict) 응답을 반환합니다.

보안에 관한 고려 사항

패치 요구는 패치 [1]적용 중에 데이터가 손상되지 않도록 하기 위해 Etags를 사용한 조건부 요구 및 If-Match 요구 헤더 등의 메커니즘을 사용해야 합니다.패치 요구 장애, 채널 장애 또는 타임아웃 시 클라이언트는 GET 요구를 사용하여 [1]리소스 상태를 확인할 수 있습니다.서버는 악의적인 클라이언트가 과도한 서버 [1]리소스를 사용하기 위해 패치 방식을 사용하지 않도록 해야 합니다.

레퍼런스

  1. ^ a b c d e f g h i j k l m n o p q r s t u v w x y "PATCH Method for HTTP". Retrieved 2015-09-12.
  2. ^ "Don't Patch Like An Idiot". Don't Patch Like An Idiot. Retrieved 16 September 2015.
  3. ^ RFC 5789
  4. ^ "History of PATCH". weblog.rubyonrails.org. Retrieved 25 September 2015.
  5. ^ "Hypertext Transfer Protocol -- HTTP/1.1". Retrieved 13 September 2015.
  6. ^ "Why PATCH is Good for Your HTTP API". Why PATCH is Good for Your HTTP API. Retrieved 16 September 2015.
  7. ^ "JSON Patch - draft-ietf-appsawg-json-patch-08". Retrieved 13 September 2015.
  8. ^ "PATCH". MDN Web Docs. Retrieved 2018-10-11.
  9. ^ "XML RFC". tools.ietf.org. Retrieved 25 September 2015.
  10. ^ "PATCH". MDN Web Docs. Retrieved 2018-10-12.
  11. ^ Darren. "REST API Best Practices 3: Partial Updates - PATCH vs PUT". www.blogger.com. Retrieved 13 September 2015.