私は、プライマリ/唯一のコンシューマーがスマート/非Webブラウザークライアントになる新しいRESTフルAPIに取り組んでいます。クライアント自体ではなく、バックグラウンドプロセスによって維持/更新されるコレクションリソースがあります。最初の反復に必要な唯一のコンテンツタイプはJSONです。URIは次のようなものです。
/items/-アイテムのコレクションを表すリソース。/items/123-IDを持つ個々のアイテムを表すリソース123。
クライアントは新しいアイテムを作成したり、コレクションを更新してアイテムを追加/削除したりすることはありませんが、個々のアイテムの値の一部を更新します。私の計画は、HTTP PATCHを使用して、独自のJSONパッチ形式を使用してアイテムリソースを更新することです。
多くの同時クライアントがアイテムを読み取り、異なるアイテムへの同時更新があり、同じアイテムへの同時更新が時折あります。ある程度の「結果整合性」は許可されますが、これを「キャッシュフレンドリー」として設計したいと思います。 「可能な限りの方法。PATCHのRFCを読むと、PATCHへの応答が成功すると、Request-URIのキャッシュが応答で更新される必要があることがわかります（応答がある場合）。問題は次のようになります。
私は：
/items/A）コレクションリソースのJSON表現に個々のアイテムの完全な表現を含め、PATCHを/items/URIに送信し、更新するアイテムをパッチ形式で含めますか？
長所：
- これにより、クライアント
Nはリソースのリストを表示するためだけに多くのリクエストを行う必要がなくなります。 itemsクライアントがアイテムを更新するときに、のキャッシュを無効にします。
短所：
- 私は実際にコレクションを更新しているのではなく、個々のアイテムを更新しているので、これは私にとって「クリーン」ではありません。
- これにより、変更された単一のアイテムのキャッシュではなく、コレクション全体のキャッシュが無効になります。
また
B）リソースコレクションのJSON表現には、含まれているアイテムへのリンクのみを含め、コレクションに含まれているアイテムを検出した後、クライアントに個々のアイテムを要求させます。HTTP PATCHは個々のアイテムのURIに送信されます（例/items/123）
長所：
- コレクションとアイテムのリソースを個別にキャッシュします。個々のアイテムのPATCHは、そのアイテムだけのキャッシュを適切に無効にすることができます。
- 更新する特定のアイテムに対してHTTPPATCHを発行するため、APIはより明確になります。
短所：
- アイテムのバッチ更新は許可されません。これは現在のところまったく要件ではなく、将来的には予測していませんが、後知恵は20〜20です。
N+1アイテムの完全なリストを表示する要求を発行するようにクライアントに要求します。