1

クライアント (UI) とサーバー間の通信に REST API を使用しています。たとえば、次のような 1 つのタイプのリソースのページ化された GET を実装しました。

GET http://../cars?page-size=10,start-index=3

car 21 から始まる最大 10 台の車 (つまり、10 台の車の 3 ページ目) が返されます。

関連エンティティを持つエンティティを返す可能性を追加したいと考えています。この場合、多数の関連エンティティ (場合によっては数十または数百) が 1 つのメイン エンティティに存在する可能性があります。現在、これは 2 つのリクエストを使用して行われます。たとえば、最初に車で GET を実行し、次に以前に取得した車の ID をパラメーターとして使用してドアで GET を実行します。

GET http://../doors?car-ids=1,2,5,7,...

ただし、リクエストの数を最小限に抑えるために、必要な情報を返すために 1 つのリクエストを使用したいと考えています。次の疑問が生じます。

  1. ページングをそのような機能とどのように統合する必要がありますか? 関連エンティティの数 (ドア) は、メイン エンティティ (車) のページ サイズに制限する必要がありますか? メイン エンティティと関連エンティティのページ サイズを分ける必要があるのではないでしょうか (例: 車 10 台、車ごとに最大 2 ドア)。
  2. メモリ使用量に関して、ソリューションがサーバー側でスケーラブルであることを確認するにはどうすればよいですか? 現在、エンティティを XML にシリアル化するために JAXB を使用しています。ストリーミング XML 手法 (STAX) を使用して、すべてのエンティティがメモリに読み込まれないようにすることを検討する必要がありますか?

どうもありがとう。

4

2 に答える 2

1

質問1に関して：

リソース エンティティ自体とすべての関連エンティティを返すスナップショット リソースを作成します。 GET /car/{car-id}/snapshot これにより、おそらく大きな応答エンティティを含むスナップショットが返されることがわかっているため、かなり大きな、ページ分割されていないサブエンティティのリストを返すことは問題ありません。 (つまり、ドア)。ただし、クライアントがこの非常にコストのかかるスナップショット リソースに対してディスパッチできる要求の数を調整することもできます。複数の車の ID を取得し、複数のスナップショットを一度に取得/cars/snapshotsできるなどのバッチ リクエスト用のリソースを提供することもできます (この場合、バッチ リクエストに含める ID の数も制限します)。POST

一方、サブエンティティGET /car/{car-id}/doors(303 から最初のページ) と GET /car/{car-id}/door/{door-id as cursor}各ページのページ分割されたリストを作成します。

これにより、クライアントは、リストされているすべてのドアを反復処理するか、クライアントが必要な場合は車の完全なスナップショットを取得するかのいずれかで、使用に最も適した表現を選択できます。

于 2011-07-07T14:51:08.903 に答える
1

ここでの REST の問題は、OO 分析ほど重要ではないと思います

ここでのリソースは Car です。ドアの数は属性であるため、クエリを表現する適切な方法を使用して、車のリソースを中心にシステムをモデル化します。

最も驚くことのない (そしておそらく最良の) アプローチは、車の既存のクエリに追加することです。あなたの例を取る：

GET http://../cars?doors=2+,page-size=10,start-index=3

REST の重要な側面は、すべてのリソースに URL があることです。REST は URL がどのように形成されるかについては何も述べていないため、RAIL スタイルのネストされたリソースについて心配する必要はありません。Fielding 自身の言葉では ...

重要なのは、すべての重要なリソースに URI があり、GET を使用してそのリソースの表現を取得できることです。

于 2011-07-07T14:51:28.607 に答える