2
REST Complex / Composite / Nested Resources [終了]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 2年前休業。 この質問を改善する RESTベースのAPIで概念に対処するための最良の方法に頭を抱えようとしています。他のリソースを含まないフラットリソースは問題ありません。問題が発生しているのは複雑なリソースです。 たとえば、漫画のリソースがあります。ComicBookその上のプロパティのすべての種類などを有しているauthor、issue number、date、など 漫画本にも1..nカバーのリストがあります。これらのカバーは複雑なオブジェクトです。これらには、カバーに関する多くの情報が含まれています。アーティスト、日付、さらにはBase 64でエンコードされたカバーの画像です。 以下のためGETにComicBook私は漫画を返し、そのbase64'ed画像を含むカバーのすべての可能性があります。それはおそらく単一の漫画を得るために大したことではありません。しかし、システム内のすべてのコミックを表にリストしたいクライアントアプリを作成しているとします。 テーブルにはComicBookリソースのいくつかのプロパティが含まれますが、テーブル内のすべてのカバーを表示する必要はありません。1000冊のコミックを返し、それぞれに複数のカバーがあると、回線上に途方もなく大量のデータが送られてきます。この場合、エンドユーザーには不要なデータです。 私の本能はCover、リソースを作成し、ComicBookカバーを含めることです。これCoverがURIです。GETコミック本では今では機能しますが、巨大なCoverリソースの代わりに、各カバーのURIを返信し、クライアントは必要に応じてカバーリソースを取得できます。 今、私は新しい漫画を作ることに問題があります。確かに、を作成するときに少なくとも1つのカバーを作成する必要がありますComic。実際、これはおそらくビジネスルールです。 だから私は行き詰まっています、私は最初にを送信してCoverそのカバーのURIを取得し、次にリストにそのURIを付けてを送信することによってクライアントにビジネスルールを適用するよう強制POSTするComicBookか、またはPOSTon ComicBookはそれが吐き出すのとは異なる見た目のリソースを受け取りますでる。着信リソースPOSTとはGET、発信深いコピー、あるGETsが依存リソースへの参照が含まれています。 Cover私はいくつかのケースでは、アドレスカバー方向にしたいと思いクライアントとして確信しているので、リソースがどのような場合には、おそらく必要があります。そのため、依存するリソースのサイズに関係なく、問題は一般的な形で存在します。一般に、クライアントにそれらのリソースがどのように構成されているかを「知る」ことを強制せずに、複雑なリソースをどのように処理しますか？