ソフトウェアのほとんどのものと同様、主にユーザーの要件に左右されます。いずれかが矛盾している場合は、どちらが優先されますか。
"/ api/items/list"エンドポイント検索は、 "/ api/items"とは違うものです。これは別の表現、おそらく特定のフィールドのみなどです。これは問題ありませんが、ソートのためのものであれば、フィールドによる単純な並べ替えをクライアントサイドの問題とみなし、そこでソートを実装します。
これは、/ api/items/listのキャッシュでパフォーマンスが向上する可能性があるためです。そのリソースを使用しているユーザーは、ソート方法に関係なく、ルートに沿って他のユーザーのキャッシュを温めます。もちろん、キャッシュの間隔を適切な値に設定します。
アイテムリソースに新しいフィールドを追加するという観点から考えると、クライアントの更新もなく、新しいフィールドに「ソート」を実装できますか？しかし、単にクライアントがデータの並べ替えを制御できるようにするよりもむしろ難しくなります。
リストの同時更新を認識しているかどうかは、ミリ秒の更新が必要かどうか（おそらくこれが本当の必要条件である場合はHTTPを使用すべきではない）、または数秒で十分でしょうか。システムが単にリストをチェックできるようにしたい場合は、5秒間更新してください。コレクションが更新されたかどうかを確認するためにポーリングできるエンドポイントを実装してください。また、キャッシュが実装されている場合は、マルチユーザー環境で他のユーザーが同じコレクションを見ている可能性があり、キャッシュを暖めてサーバーへの往復を防ぐことができます。
アイテムリソースに「最後に変更された」フィールドがある場合は、[GET] "/ api/items/modifiedTimes/latest"のようなリソースを実装するのは簡単でしょう最新のリソースとみなします。正確に同じタイムスタンプで2つの更新が発生することを心配している場合は、同じ概念を使用して別の方法で解決してください。
要約すれば、キャッシュのようなすべての利点を持つHTTPを使用している場合は、2回の往復のオーバーヘッドをサーバに対する心配は考慮する価値がありません。レイテンシとパフォーマンスが実際に問題になる場合は、サーバー側の並べ替えの要件と直接競合し、妥協する必要があります。
アイテムをコレクションにPOSTします。サーバは返されます。ボディは作成されません。クライアントでアイテムをコレクションに追加し、並べ替えを再適用します。並行して最新のエンドポイントをポーリングしてコレクションが変更されているかどうかを確認し、もしあればリストを取得します。
パフォーマンスを本当に心配していた場合、最新のエンドポイントを時間とともにポーリングする代わりに、イベントのエンドポイントをポーリングしてコレクションで発生したイベントのリストを返すこともできます必要に応じて各イベントのペイロードと一緒に（挿入、更新、削除）できます。 「/ api/items/events？since = 2017082215005959」 この結果を使用して、必要に応じてクライアントリストを更新することができます。