REST スタイルの Web サービス内のリソースに対するバッチ操作には、どのような実証済みの設計パターンがありますか?
私は、パフォーマンスと安定性の面で理想と現実のバランスを取ろうとしています。現在、すべての操作がリスト リソースから取得される (つまり、GET /user) か、単一インスタンスで取得される (PUT /user/1、DELETE /user/22 など) API があります。
オブジェクトのセット全体の 1 つのフィールドを更新したい場合があります。 1 つのフィールドを更新するために各オブジェクトの表現全体を何度も送信するのは非常に無駄なようです。
RPC スタイルの API では、次のメソッドを使用できます。
/mail.do?method=markAsRead&messageIds=1,2,3,4... etc.
ここでの REST に相当するものは何ですか? または、時々妥協しても大丈夫ですか。パフォーマンスなどを実際に向上させる特定の操作をいくつか追加すると、設計が台無しになりますか? 現時点では、すべてのケースでクライアントは Web ブラウザー (クライアント側の JavaScript アプリケーション) です。
ベストアンサー1
バッチ処理のシンプルな RESTful パターンは、コレクション リソースを利用することです。たとえば、複数のメッセージを一度に削除する場合などです。
DELETE /mail?&id=0&id=1&id=2
部分的なリソース、つまりリソース属性をバッチ更新するのは、もう少し複雑です。つまり、markedAsRead 属性をそれぞれ更新します。基本的に、属性を各リソースの一部として扱うのではなく、リソースを入れるバケットとして扱います。1 つの例がすでに投稿されています。少し調整しました。
POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]
基本的には、既読としてマークされたメールのリストを更新します。
複数のアイテムを同じカテゴリに割り当てる場合にも使用できます。
POST /mail?category=junk
POSTDATA: ids=[0,1,2]
iTunes スタイルのバッチ部分更新 (例: アーティスト + アルバムタイトル、トラックタイトルはなし) を実行するのは明らかにはるかに複雑です。バケットのアナロジーが崩れ始めます。
POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]
長期的には、単一の部分的なリソースまたはリソース属性を更新する方がはるかに簡単です。サブリソースを使用するだけです。
POST /mail/0/markAsRead
POSTDATA: true
あるいは、パラメータ化されたリソースを使用することもできます。これは REST パターンではあまり一般的ではありませんが、URI および HTTP 仕様では許可されています。セミコロンは、リソース内の関連するパラメータを水平に分割します。
いくつかの属性、いくつかのリソースを更新します。
POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk
複数のリソースを 1 つの属性だけ更新します。
POST /mail/0;1;2/markAsRead
POSTDATA: true
1 つのリソースのみで複数の属性を更新します。
POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk
RESTful な創造性が溢れています。