web-dev-qa-db-ja.com

PATCHメソッドは、応答本文でリソースのすべてのフィールドを返す必要がありますか？

PATCHメソッドは、応答本文でリソースのすべてのフィールドを返す必要がありますか？
それとも、更新されたフィールドのみを返す必要がありますか？

私は読んでいます this

たとえば、更新されたフィールドのみを返す場合、ユーザーは一部のフィールドを更新しながら、サーバーで更新されたフィールドを知ることができます。

**Users resource representations**
name: string
age: number
createdon: date
modifiedon: date



PATCH /users/{userId}
Request body
{
  name: 'changedname',
}



Response body Case1
{
  name: 'changedname',
  age: 20,
  createdon: 2016-01-01,
  modifiedon: 2016-06-09
}



Response body Case2
{
  name: 'changedname',
  modifiedon: 2016-06-09
}
resthttphttprequestrestful-architecturehttpverbs
17
Nigiri

通常、これは コンテンツネゴシエーション によって処理されます。言い換えれば、クライアントは、特定の表現が必要な場合にそれを要求します。リクエストは次のようになります。

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.user+json
...

この場合、クライアントは完全なuser表現が回答として必要であることを表明します。またはそれは行うことができます：

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.object-fragment+json
...

あるオブジェクトの一般的なフラグメント表現を要求します。

必要がない場合は両方を実装する必要はありません。その場合は、ユースケースを実行し、406 Not Acceptableからmedia-typesで応答するだけで、現時点ではサポートされません。

16
Robert Bräutigam

PATCHの仕様はこれを義務付けていません。

これを制御したい場合は、インスピレーションを得るために https://greenbytes.de/tech/webdav/rfc7240.html#return を確認することをお勧めします。

5
Julian Reschke

REST仕様（これについては RFC 6902 を参照する必要があると思います）は、これに関する強力なルールを適用するとは思わないクライアントが必要な方法でリソースを使用できるように、リソース全体を返します。理論的には、クライアント自体がパッチされたもの（少なくとも要求が何であったか）を知っています。サーバーからの確認が得られない可能性があります些細なこと（特にPATCHがコレクションに使用されることを考えると特に）、または少なくとも価値がない。

1
Alexandru Marculescu