私はまだ、REST のやり方に慣れようとしているところです。
私の状況では、クライアント ソフトウェアは RESTful サービスと対話します。まれに、クライアントがエンティティのデータベース全体をアップロードします (各エンティティは、約 5kb の xml チャンクにシリアル化されます)。
おそらく私は間違っていますが、適切な RESTful 戦略は、各エンティティを循環し、それぞれを個別に POST することのようです。ただし、これらのエンティティは何万もある可能性があり、どういうわけか、非常に多くの急速な POST が適切とは思えません。
この状況では、すべてのエンティティを 1 つの大きな xml 表現にパッケージ化することは、RESTful なやり方に違反するように感じますが、何千もの POST の必要性も回避できます。
これを達成するための標準的な方法はありますか? 前もって感謝します！
「エンティティのパケット」がリソースと見なされない理由がわかりません。トランザクション書き込みは、確かにデータベース トランザクションをリソースと見なすことができます。Fielding の論文を読んでいないことは認めますが、複数のリソースを 1 つの表現にラップすることが REST を無効にする方法がわかりません。
データベース トランザクションは、このようなことを行います。それらは、トランザクション リソース内の小さなリソースをラップします。通常、彼らがこれを行うのは、まだ大きい可能性がある小さなリソースを個別に投稿できるようにするためです. しかし、トランザクション自体はリソースと見なされるため、1 つの POST 要求として投稿できる表現を考え出すことで、この設計が RESTful でなくなるとは思えません。
他の方向にも使用されます。クライアントがサーバーから検索結果を取得すると、サーバーはこれらを結果リソース内にラップして、クライアントが複数の個別のリソースではなくこの 1 つのリソースを取得できるようにする場合があります。
したがって、これらの小さな 5kb リソースをより大きなコレクション リソース内にラップすることは、RESTful と見なすことができ、おそらくあなたが進むべき方法だと思います。
大きなラッパーが有効なメディアタイプを持っている限り、それを単一のリソースとして扱うことは問題ありません。そのメディアタイプがどうなるかを理解するのは難しい部分です。
ここには、RESTful になることを妨げる少なくとも 2 つの問題があります。
各リソースは URI で識別する必要があります。リソースを操作するということは、HTTP 呼び出しを使用して URI を呼び出す必要があることを意味します。したがって、1 回の HTTP 呼び出しだけで複数のリソースの複数のアクションを呼び出すことはできません。
リソースは名詞で識別され、エンティティを表します。これは、Employee と Car を挿入するには、それぞれのエンティティに対して 2 つの異なるリソースを呼び出す必要があることを意味します。
つまり、ここで純粋に RESTful なアプローチを取ることはできません。ただし、REST は慣習として役立つように設計されており、ユーザーを拘束するものではありません。ここでの最善の解決策は、必要なことを行うカスタム アクションを作成することです。
または、INSERT、UPDATE、および XML として異種データの BLOB を取り込むその他のアクションを使用して、汎用ラッパー エンティティを作成することもできます。/Car/ただし、汎用ラッパーとURIを介して Car レコードを挿入できるようになったため、これにより他のエンドポイントが弱体化します。
実際の要件についてよくわからない場合は、特に REST を介してこの機能を公開しないことをお勧めします。異なるオブジェクトの場合、着信コレクションを分割すると、さまざまなコントローラー内で INSERT アクションメソッドを呼び出すことができます。