これに対する私の見解は次のとおりです。やむを得ない場合を除き、サーバーでのソートは避け、クライアントで実行してください。その方がはるかに反応が良いです。20 個のアイテムがあり、名前 (昇順または降順)、在庫の数量 (昇順または降順)、または価格 (同じこと) で並べ替えたい場合は、クライアントで実行する方がはるかに優れています。
しなければならないときは、アイテムが 1,000 個あるときです。1 回の呼び出しで 1,000 個のアイテムを読み込んで並べ替えることはありません。各アイテムのサイズにもよりますが、おそらく一度に約 30 ~ 50 個を取得します。したがって、サーバーに「次の 30 個のアイテムをください」、より正確には「X 点から始まる 30 個のアイテムをください」と伝える方法が必要です。
REST 内であっても、それを行う方法はたくさんあります。一般に、開始点とカウントをクエリ パラメータを介して渡すのが最善です。したがって、ウィジェットを取得していて、API が
GET /widget
次に、いくつかのクエリ フィールドがあります: field
(ソートするフィールド)、order
( または のasc
いずれかdes
)、count
(整数)、およびstart
(レコード ID またはインデックスのいずれかを開始するポイント)。
それは以下を与える:
GET /widget?field=name&count=30&start=100&order=asc // get widgets sorted by field in ascending order, starting with the 100th widget and going for 30 widgets
GET /widget?field=price&count=20&start=225&order=desc // get widgets sorted by price from highest to lowest (descending order), starting with the 100th widget and going for 20 widgets
これにはバリエーションがあります。たとえば、 and の代わりにandstart
をcount
実行できます。と呼ばれるのを見たことがあります。しかし、考え方は同じです。これらの 4 つのフィールドは、定義されたアイテムのセットを取得するためにサーバーが知る必要があるすべての情報を提供します。start
end
order
sort