REST - リソースの収集とIf-MatchヘッダーへのPOSTのとき

Question

各ユーザーには宝石のコレクションがあります。これらの宝石は、REST APIを介してアクセスすることができます

GET /user/<user id>/gem    -> get all gems 
GET /user/<user id>/gem/<gem id>  -> get an existing gem 
POST /user/<user id>/gem    -> add a new gem 
PUT /user/<user id>/gem/<gem id>  -> edit an existing gem 
DELETE /user/<user id>/gem/<gem id>  -> delete an existing gem 

私はPOST HTTPメソッドを介して宝石を追加することができ、同時に実行して、いくつかのバックエンドプロセスを、持っています。 （PUT）や削除（DELETE）の宝石を削除することもできますが、それは私の質問では重要ではありません）

高度な見解から見ると、 ：

1. GET /user/<current user id>/gem 
2. some calculations, based on step 1 
3a. if (step 2 decided that a gem should be added) 
3b.  POST /user/<current user id>/gem 

このように、これらのプロセスは並行して実行されます。通常、2つのプロセスは同じユーザーの宝石を管理していませんが、発生する可能性があります。

したがって、その間に何か変更があった場合は、3bのPOSTを禁止する仕組みが必要です。 ETagsとオプティミスティックロックの使用について考えました：

1. GET /user/<current user id>/gem and remember the returned ETag 
2. some calculations, based on step 1 
3a. if (step 2 decided that a gem should be added) 
3b.  POST /user/<current user id>/gem with header 'If-Match=<ETag from step 1>' 
3c.  if (server returns 412 - precondition failed) 
3d.   start again at step 1 

私はETagsがこれを意図しているかどうかわかりません。 ETagのほとんどの例は約1つの単一リソース（/gem/23など）ですが、リソースの集合（/gemなど）についてのものではありません。つまり、ステップ3bでは、完全な宝石コレクションのETagを提供していますが、本質的に私は1つの宝石を追加して提供しています。

Answer 1

確かに、あなたの問題は、それがETagsの使用に非常によく似ているように聞こえます。それがコレクションであるという事実は本当に重要ではありません。重要なことは、ETagを一貫して生成できるという表現を持つリソースだということです。

あなたのAPIコンシューマに関係なく変更できるコレクションの表現について何かがあるかどうかについて考えることが1つあります。たとえば、コレクションをランダムまたは矛盾した順序で出力するとしますが、コレクションは順序付けされていないものとして意味的に定義されています。その場合、コレクション内のアイテムのセットに基づいてweak ETagを生成することができます。