[json] REST API 실제 시나리오에서 PUT 및 PATCH 메소드 사용

참고 : REST에 대해 처음 읽었을 때, dem 등성은 혼란스러워하는 개념이었습니다. 추가 의견 (및 Jason Hoetger ‘s answer )이 보여 주었 듯이 여전히 원래의 대답에서 제대로 이해하지 못했습니다 . 한동안, 나는 Jason을 효과적으로 표절하는 것을 피하기 위해이 답변을 광범위하게 업데이트하는 것을 거부했지만, 나는 (의견에) 질문을 받았기 때문에 지금 편집하고 있습니다.

내 대답을 읽은 후에도이 질문에 대한 Jason Hoetger의 훌륭한 답변 을 읽을 것을 제안 하며 단순히 Jason을 훔치지 않고 더 나은 답변을 얻으려고 노력할 것입니다.

PUT이 dem 등원 인 이유는 무엇입니까?

RFC 2616 인용에서 언급했듯이 PUT은 dem 등원으로 간주됩니다. 리소스를 PUT하면 다음 두 가지 가정이 적용됩니다.

1. 컬렉션이 아닌 엔터티를 참조하고 있습니다.

2. 공급중인 법인이 완료되었습니다 ( 전체 법인).

예 중 하나를 봅시다.

{ "username": "skwee357", "email": "skwee357@domain.com" }

/users제안한대로이 문서를에 게시하면 다음과 같은 엔티티를 다시 얻을 수 있습니다.

## /users/1

{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}

나중에이 엔티티를 수정하려면 PUT과 PATCH 중에서 선택하십시오. PUT은 다음과 같습니다.

PUT /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // new email address
}

PATCH를 사용하여 동일한 작업을 수행 할 수 있습니다. 다음과 같이 보일 수 있습니다.

PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

이 둘 사이의 차이점을 바로 알 수 있습니다. PUT에는이 사용자의 모든 매개 변수가 포함되었지만 PATCH에는 수정중인 매개 변수 만 포함되었습니다 ( email).

PUT을 사용하는 경우 완전한 엔티티를 전송하는 것으로 가정하고 해당 완전한 엔티티 는 해당 URI의 기존 엔티티를 대체 합니다. 위의 예에서 PUT과 PATCH는 동일한 목표를 달성합니다. 둘 다이 사용자의 전자 메일 주소를 변경합니다. 그러나 PUT은 전체 엔터티를 교체하여 처리하지만 PATCH는 제공된 필드 만 업데이트하고 다른 필드는 그대로 둡니다.

PUT 요청에는 전체 엔터티가 포함되므로 동일한 요청을 반복적으로 발행하면 항상 동일한 결과를 가져야합니다 (보낸 데이터는 이제 엔터티의 전체 데이터 임). 따라서 PUT은 dem 등원입니다.

잘못된 PUT 사용

PUT 요청에서 위의 PATCH 데이터를 사용하면 어떻게됩니까?

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}
PUT /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

GET /users/1
{
    "email": "skwee357@gmail.com"      // new email address... and nothing else!
}

(이 질문의 목적 상 서버에는 특정 필수 필드가 없으며 이것이 가능할 것이라고 가정합니다. 실제로는 그렇지 않을 수도 있습니다.)

우리는 PUT을 사용했지만 공급 만 했으므로 email이제이 엔티티에서 유일한 것입니다. 이로 인해 데이터가 손실되었습니다.

이 예제는 설명을위한 것입니다. 실제로이 작업을 수행하지 마십시오. 이 PUT 요청은 기술적으로 dem 등 적이지만 끔찍한 아이디어가 아니라는 의미는 아닙니다.

패치는 어떻게 dem 등식이 될 수 있습니까?

위의 예에서 PATCH 는 dem 등원 이었습니다 . 변경했지만 동일한 변경을 계속 반복하면 항상 동일한 결과가 나타납니다. 전자 메일 주소를 새 값으로 변경했습니다.

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@domain.com"
}
PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address
}

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // email address was changed
}
PATCH /users/1
{
    "email": "skwee357@gmail.com"       // new email address... again
}

GET /users/1
{
    "username": "skwee357",
    "email": "skwee357@gmail.com"       // nothing changed since last GET
}

정확성을 위해 고정 된 나의 원래 예

나는 원래 비 등가성을 보여주고 있다고 생각한 예를 가지고 있었지만 오도하고 잘못되었습니다. 예제를 유지하되, 다른 것을 설명하기 위해 사용할 것입니다. 같은 엔티티에 대해 여러 개의 PATCH 문서가 다른 속성을 수정하더라도 PATCH가 비등 전성이되지는 않습니다.

과거에 사용자가 추가되었다고 가정 해 봅시다. 이것은 당신이 시작한 상태입니다.

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@olddomain.com",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

PATCH 후에 수정 된 엔티티가 있습니다.

PATCH /users/1
{"email": "skwee357@newdomain.com"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",    // the email changed, yay!
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

그런 다음 PATCH를 반복해서 적용하면 동일한 결과가 계속 나타납니다. 전자 메일이 새로운 값으로 변경되었습니다. A는 들어오고 A는 나옵니다. 그러므로 이것은 dem 등입니다.

한 시간 후에 커피를 마시고 휴식을 취한 후 다른 사람이 자신의 패치를 가지고옵니다. 우체국에서 약간의 변화가 있었을 것 같습니다.

PATCH /users/1
{"zip": "12345"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",  // still the new email you set
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"                      // and this change as well
}

이 우체국의 PATCH는 전자 우편과 관련이 없으며 우편 번호 만 반복 적용되는 경우 우편 번호 만 새로운 값으로 설정됩니다. A는 들어오고 A는 나옵니다. 따라서 이것은 또한 dem 등합니다.

다음 날, PATCH를 다시 ​​보내기로 결정했습니다.

PATCH /users/1
{"email": "skwee357@newdomain.com"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@newdomain.com",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"
}

패치는 어제와 동일한 효과를 나타냅니다. 전자 메일 주소를 설정합니다. A가 들어 왔고, A가 나왔으므로 이것 또한 dem 등합니다.

원래 답변에서 내가 잘못한 것

중요한 구별을 원합니다 (원래 답변에서 잘못된 점이 있음). 많은 서버가 수정 사항 (있는 경우)과 함께 새 엔티티 상태를 다시 보내 REST 요청에 응답합니다. 따라서이 응답을 다시 받으면 우편 번호가 지난 번에받은 것이 아니기 때문에 어제받은 것과 다릅니다 . 그러나 귀하의 요청은 우편 번호와 관련이 없으며 전자 메일과 관련이 있습니다. 따라서 PATCH 문서는 여전히 dem 등원입니다. PATCH로 보낸 이메일은 이제 엔티티의 이메일 주소입니다.

그렇다면 PATCH가 dem 등성이 아닌 때는 언제입니까?

이 질문을 완전히 처리하려면 Jason Hoetger의 답변 을 다시 참조하십시오 . 솔직히 말해서이 부분에 대해 그가 이미 가지고있는 것보다 더 잘 대답 할 수는 없다고 생각하기 때문입니다.

답변

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" }]

PATCH /users
[{ "op": "add", "username": "newuser", "email": "newuser@example.org" }]

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" }]

[{ "id": 1, "username": "firstuser", "email": "firstuser@example.org" },
 { "id": 2, "username": "newuser", "email": "newuser@example.org" },
 { "id": 3, "username": "newuser", "email": "newuser@example.org" }]

/users/1
PUT {id: 1, username: 'skwee357', email: 'newemail@domain.com'}

/users/1
PUT {id: 1, email: 'newemail@domain.com'}

{id: 1, username: null, email: 'newemail@domain.com'}

PATCH /users/123

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

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "skwee357@olddomain.com",
  "state": "NY",
  "zip": "10001"
}

PATCH /contacts/1
{
 [{"operation": "add", "field": "address", "value": "123 main street"},
  {"operation": "replace", "field": "email", "value": "abc@myemail.com"},
  {"operation": "delete", "field": "zip"}]
}

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "abc@myemail.com",
  "state": "NY",
  "address": "123 main street",
}

PATCH /contacts/1
{
  "address": "123 main street",
  "email": "abc@myemail.com",
  "zip":
}

PATCH /users/1
{"email": "skwee357@newdomain.com"}