PATCH 방법이 i 등성이 아닌 이유는 무엇입니까?

나는 이것에 대해 궁금했다.

에 및 필드 가있는 user리소스 가 있다고 가정 합니다. 필드를 업데이트하려면 다음과 같이 리소스에 PATCH 요청을 할 수 있습니다.idname

PATCH /users/42
{"name": "john doe"} 

그런 다음 응용 프로그램은 사용자 42 이름을 업데이트합니다.

그러나 왜이 요청을 반복하면 결과가 달라 집니까?

RFC 5789 에 따르면

패치는 안전하거나 dem 등하 지 않습니다

PATCH 요청 은 dem 등원 일 수 있지만 반드시 그럴 필요는 없습니다. 이것이 비등 전성으로 특징 지워지는 이유입니다.

PATCH가 dem 등원 일 수 있는지의 여부는 필요한 변경 사항을 전달하는 방법에 따라 다릅니다.
예를 들어, 패치 형식이의 형식 인 {change: 'Name' from: 'benjamin franklin' to: 'john doe'}경우 첫 번째 요청 이후의 PATCH 요청은 첫 번째 요청과 다른 영향 (실패 응답)을 갖습니다.
비 등가성에 대한 또 다른 이유는 원래 자원 이외의 다른 것에 수정을 적용하면 자원이 유효하지 않게 될 수 있기 때문입니다. 변경 사항을 여러 번 적용하는 경우에도 마찬가지입니다.

나는 i 등성이 아닌 PATCH가 RFC 5789 의이 단락 일 때 명확한 대답을 생각합니다.

패치 형식이 알려진 기준점 (예 : 텍스트 파일을 로그 파일에 추가하거나 충돌하지 않는 행을 데이터베이스 테이블에 추가)에서 작동 할 필요가없는 경우도 있습니다.이 경우 클라이언트 요청에서 동일한주의가 필요하지 않습니다. .

RFC는 패치에 리소스에 대한 "일반적인 변경 사항"이 포함되어 있다고 명시 했으므로 일반적인 필드 교체 이상의 것을 고려해야합니다. 만약 리소스가 카운터를위한 것이라면, patch는 증가를 요청할 수 있으며, 이는 분명히 idempotet이 아닙니다.

PATCH요청은 리소스에 적용 할 작업 집합을 설명합니다. 동일한 작업 집합을 동일한 리소스에 두 번 적용하면 결과가 동일하지 않을 수 있습니다. 작업 정의는 사용자에게 달려 있기 때문입니다. 다시 말해서 병합 규칙 을 정의해야합니다 .

기억 PATCH요청은 다양한 형식뿐 아니라 JSON 자원을 패치에 사용될 수 있습니다.

따라서 병합 규칙을 dem 등원으로 정의하면PATCH 요청이 dem 등원 일 수 있습니다 .

dem 등한 예 :

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  age: 33
}

// New resource
{
  name: 'Tito',
  age: 33
}

비등 전성 예 :

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  $increment: 'age'
}

// New resource
{
  name: 'Tito',
  age: 33
}

두 번째 예에서는 속성을 증가시키기 위해 만든 "Mongo like"구문을 사용했습니다. 동일한 요청을 여러 번 보내면 매번 다른 결과가 나올 것이기 때문에 이것은 분명히 dem 등성이 아닙니다.

이제 이러한 구성 구문을 사용할 수 있는지 궁금 할 것입니다. 표준 에 따르면 다음과 같습니다.

PUT 요청과 PATCH 요청의 차이점은 서버가 동봉 된 엔터티를 처리하여 Request-URI로 식별되는 리소스를 수정하는 방식에 반영됩니다. PUT 요청에서 동봉 된 엔터티는 원본 서버에 저장된 수정 된 버전의 리소스로 간주되며 클라이언트는 저장된 버전의 교체를 요청합니다. 그러나 PATCH를 사용하면 동봉 된 엔터티에 현재 원본 서버에있는 리소스를 수정하여 새 버전을 생성하는 방법을 설명하는 지침 세트가 포함됩니다.

또한 이 방법으로 요청 을 사용 하는 것이 편안한 지 궁금 할 수도 있습니다. PATCH많은 사람들은 그렇지 않다고 생각 합니다.이 문제에 대한 많은 의견을 가진 좋은 대답 이 있습니다.