하이퍼텍스트 전송 프로토콜 — 패치 방법!내가 잘못 생각했어!!!

사진작가Free To Use Sounds우Unsplash
나는 소프트웨어 공학에 종사한 지 이미 3년이 넘었다.나는 3년 동안 지금까지 어떤 패치 단점도 본 적이 없어서 매우 놀랐다.
그렇기 때문에, 나는 이전에 진정으로 패치 방법을 사용한 적이 없고, 그것을 개발한 적이 없다.3년 전, 내가 처음으로 상급 PUT와 PATCH 사이의 차이를 물었을 때, 변경된 값만 있었던 것을 기억한다.PUT는 전체 항목을 대체하고 지정된 필드 변경을 패치합니다.
그렇습니다!그러나 사실 내 인생에서 우리는 패치 방법을 사용한 적이 없다.왜냐하면 당시에 우리는 아직 그것을 필요로 하지 않았기 때문이다.그래서 나는 지금 이 신념 속에서 생활하고 있다. 내가 다른 사람과 이야기할 때마다 그들은 통상적으로 나의 뜻을 이해한다.

패치에 대한 나의 최초의 생각

HTTP 방법과 REST를 알고 있는 이상GET, DELETE, POST 및 PUT만 사용합니다.나는 지금까지 패치를 사용할 기회가 없었다.
우리는 PUT가 어떻게 작동하는지 똑똑히 알고 있다.나는 이미 PUT를 사용한 지 오래되었다.예를 들어, 나는 이 JSON을 가지고 있다.나는 PUT 수술을 하고 있다.

GET /user/bxcodec
{
  "name": "Iman",
  "username": "bxcodec"
}

HTTP PUT 적용

PUT /user/bxcodec
{
  "name": "Iman Tumorang",
  "username": "bxcodec"
}

최종 결과

GET /user/bxcodec
{
  "name": "Iman Tumorang",
  "username": "bxcodec"
}

"PATCH는 전체 항목을 대체하지 않고 지정된 항목만 대체합니다."
그래서 이 말에서 기본적으로 이것은 내가 패치가 어떻게 작동하는지 생각하는 것이다.예를 들어, 나는 이 JSON을 가지고 있다.

GET /user/bxcodec
{
  "name": "Iman",
  "username": "bxcodec"
}

HTTP 패치 적용

PATCH /user/bxcodec
{
  "name": "Iman Tumorang"
}

최종 결과

GET /user/bxcodec
{
  "name": "Iman Tumorang",
  "username": "bxcodec"
}

정당하다이것이 바로 내가 HTTP-PATCH가 어떻게 일을 해야 한다고 생각하는 것이다.나는 이 신념을 가지고 3년 넘게 살았다.

줄거리가 복잡하다.

그런데 아까 제가 이걸 썼을 때 여기 Golang 문서에서 이걸 발견했어요. https://golang.org/pkg/net/http/

궁금해서 다른 값을 발견했습니다. RFC 5789의 주석을 찾았습니다.왜 그것은 다른 RFC와 같지 않습니까?왜 달라요?
RFC 5789를 보고 이상한 것을 발견했습니다.설명에 의하면

RFC 5789

With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

따라서 RFC 문서에서 요청체에서 요청 URI의 현재 자원을 수정하기 위해 작업 또는 명령 세트를 지정해야 한다고 합니다.우리가 위의 예에서 본 바와 같다.그런데 요청체에 어떻게 조작을 설정합니까?나는 어떻게 그것을 포맷해야 합니까?

JSON 패치 소개

앞의 질문에 대답하기 위해서, 나는 어떻게 요청 본문에서 조작 목록의 형식을 설정해야 합니까?나는 재미있는 것을 발견했다. 이것은 또 다른 JSON 패치라는 RFC(RFC 6902)이다.이것은 JSON 패치를 사용하여 JSON 작업을 수행하는 방법을 설명하는 RFC입니다.
JSON-PATCH 작동 원리의 간단한 예는 다음과 같습니다.예를 들어, 여기에는 JSON이 있습니다.

{
  "name": "Iman",
  "username": "bxcodec"
}

JSON-PATCH 를 사용합니다.

[
  { "op": "replace", "path": "/name", "value": "Iman Tumorang" },
  { "op": "add", "path": "/likes", "value": ["go", "blogging"] }
]

수정 결과.

{
  "name": "Iman Tumorang",
  "username": "bxcodec",
  "likes": [
    "go",
    "blogging"
  ]
}

따라서 JSON-PATCH에서 리소스를 수정하는 작업, 경로 및 값을 정의해야 합니다.사용 가능한 모든 명령은 RFC6902 에서 볼 수 있습니다.
그래서 놀랍게도 이곳의 줄거리는 왜곡되었다. HTTP 패치와 JSON-PATCH는 관련성이 있다.RFC 6902를 열었을 때 이것을 얻었습니다.
RFC 6902

JSON Patch is a format (identified by the media type “application/ json-patch+json”) for expressing a sequence of operations to apply to a target JSON document; it is suitable for use with the HTTP PATCH method.

알았어!
따라서 간단하게 말하면 HTTP-PATCH의 경우 JSON-PATCH를 요청체로 사용할 수 있습니다.따라서 JSON-PATCH를 사용하여 요청체의 작업 목록을 정의할 수 있습니다.
그래서 HTTP-PATCH와 JSON-PATCH를 결합시켜야 합니다. 만약에 제가 그것을 하나의 예에 넣으면 아래와 같이 더욱 커질 것입니다.

GET /user/bxcodec
{
  "name": "Iman",
  "username": "bxcodec"
}

HTTP 패치 적용

PATCH /user/bxcodec
[
  { "op": "replace", "path": "/name", "value": "Iman Tumorang" }
]

최종 결과.

GET /user/bxcodec
{
  "name": "Iman Tumorang",
  "username": "bxcodec"
}

결론

오늘 잘못된 신념을 가지고 살아온 후에 나는 새로운 것을 배웠다.HTTP-PATCH에는 다양한 구현 방법이 있습니다.우리는 JSON-PATCH를 HTTP-PATCH 요청 방법의 요청 주체로 사용할 수 있습니다.
하지만, 나는 모르겠다. 솔직히 말하자면, 나는 여전히 이렇게 하는 것이 그리 불편하다고 생각한다.나의 과거의 생각에 비하면, 그것은 우리의 실현을 위해 추가적인 내용을 증가시켰다.다행히도 JSON-PATCH 라이브러리가 많이 있습니다. 예를 들어 Golang의 https://github.com/evanphx/json-patch, Typescript의 https://www.npmjs.com/package/fast-json-patch 등입니다.그래서 나는 나의 다음 프로젝트에서 그것을 실시하는 것이 결코 어렵지 않다고 생각한다.하지만 그래, 어디 보자. 하하.
하지만 그렇습니다. 패치의 값을 직접 변경해도 (JSON-PATCH를 사용하지 않고 RFC 5789를 따르지 않음) LOL이 더 편리합니다. 저는 다음 프로젝트에서 이 점을 따르려고 합니다.
https://medium.com/media/1f83e4a733ad3206f47e6dd38aa4fc6d/href