341

これは、この質問のより一般的な再定式化です(Rails 固有の部分を削除して)

RESTful Web アプリケーションのリソースにページネーションを実装する方法がわかりません。私が というリソースを持っていると仮定するとproducts、次のうちどれが最良のアプローチだと思いますか? その理由は次のとおりです:

1.クエリ文字列のみを使用する

例えば。http://application/products?page=2&sort_by=date&sort_how=asc
ここでの問題は、ページ全体のキャッシュを使用できないことと、URL がきれいではなく覚えにくいことです。

2.ページをリソースとして使用し、並べ替えのためのクエリ文字列を使用する

例えば。http://application/products/page/2?sort_by=date&sort_how=asc
この場合、見られる問題は、使用するとまったく異なる結果が得られる可能性があり、ページキャッシュをまだ使用できないためhttp://application/products/pages/1、一意のリソースではないことです。sort_by=price

3. ページをリソースとして使用し、URL セグメントを並べ替えに使用する

例えば。http://application/products/by-date/page/2
私は個人的にこの方法を使用しても問題ないと思いますが、誰かがこれは良い方法ではないと私に警告しました (彼は理由を教えてくれなかったので、なぜそれが推奨されないのか知っているなら、私に知らせてください)

提案、意見、批評は大歓迎です。ありがとう。

4

13 に答える 13

112

Fionn に同意しますが、さらに一歩進んで、ページはリソースではなく、リクエストのプロパティであると言います。そのため、オプション 1 のクエリ文字列のみを選択しました。ちょうどいい感じです。Twitter APIの構造が落ち着いていてとても気に入っています。単純すぎず、複雑すぎず、十分に文書化されています。良くも悪くも、ある方法と別の方法で何かを行うことについてフェンスにいるとき、それは私の「行く」デザインです。

于 2009-04-22T11:14:14.620 に答える
69

バージョン3の問題は、より「視点」の問題だと思います。ページは、ページ上のリソースまたは製品として表示されますか。

ページをリソースとして表示する場合、ページ2のクエリは常にページ2を生成するため、これは完全に優れたソリューションです。

ただし、ページ上の商品がリソースとして表示されている場合は、2ページ目の商品が変更される（古い商品が削除されるなど）可能性があるという問題があります。この場合、URIは常に同じリソースを返すとは限りません。

たとえば、顧客が商品リストページXへのリンクを保存している場合、次にリンクを開いたときに、問題の商品がページXに表示されなくなる可能性があります。

于 2009-04-22T10:15:59.360 に答える
38

HTTP には、ページネーションにも適した優れた Range ヘッダーがあります。あなたは送信することができます

Range: pages=1

最初のページだけにする。そのため、ページとは何かを考え直す必要があるかもしれません。たぶん、クライアントは別の範囲のアイテムを望んでいます。範囲ヘッダーは、注文を宣言するためにも機能します。

Range: products-by-date=2009_03_27-

その日付より新しいすべての製品を取得するには、または

Range: products-by-date=0-2009_11_30

その日付より古いすべての製品を取得します。「0」はおそらく最善の解決策ではありませんが、RFC は範囲の開始に何かを求めているようです。units=-range_end を解析しない HTTP パーサーがデプロイされている可能性があります。

ヘッダーが（受け入れられる）オプションではない場合、最初の解決策（すべてクエリ文字列内）がページを処理する方法だと思います。ただし、クエリ文字列を正規化してください ((key=value) ペアをアルファベット順に並べ替えます)。これで「?a=1&b=x」と「?b=x&a=1」の微分問題が解けます。

于 2009-12-04T19:55:40.320 に答える
26

オプション 1 は、アプリケーションがページネーションを同じリソースの別のビューを生成するための手法と見なす限り、最良のようです。

そうは言っても、URL スキームは比較的重要ではありません。アプリケーションをハイパーテキスト駆動になるように設計している場合(すべての REST アプリケーションは定義上そうでなければならないため)、クライアントはそれ自体で URI を構築することはありません。代わりに、アプリケーションはクライアントにリンクを提供し、クライアントはそれらをたどります。

クライアントが提供できるリンクの 1 つは、ページネーション リンクです。

これらすべての嬉しい副作用は、ページネーションの URI 構造について気が変わって、来週まったく違うものを実装したとしても、クライアントはまったく変更せずに作業を続けることができるということです。

于 2009-07-26T17:54:19.257 に答える
12

私は常にオプション 1 のスタイルを使用してきました。私の場合、とにかくデータが頻繁に変更されるため、キャッシングは問題ではありませんでした。ページのサイズを構成可能にすると、データをキャッシュできなくなります。

URLが覚えにくい、または汚れているとは思いません。私にとって、これはクエリ パラメータの優れた使い方です。リソースは明らかに製品のリストであり、クエリ パラメーターは、リストを表示する方法 (並べ替えとページ) を指定するだけです。

于 2009-05-04T17:09:22.593 に答える
10

オプション 3 に特定の順序でパラメーターがあることを誰も指摘していないのは奇妙です。 http://application/products/Date/Descending/Name/Ascending/page/2 および http//application/products/Name/Ascending/Date/Descending/page/2

同じリソースを指していますが、完全に異なる URL を持っています。

私にとっては、オプション 1 が最も受け入れられるように思えます。これは、「私が望むもの」と「どのように私が望むか」を明確に分離しているためです(それらの間に疑問符さえあります 笑)。完全な URL を使用してページ全体のキャッシュを実装できます (いずれにせよ、すべてのオプションで同じ問題が発生します)。

Parameters-in-URL アプローチの唯一の利点は、クリーンな URL です。ただし、パラメーターをエンコードし、無損失でデコードする方法を考え出す必要があります。もちろん、URLencode/decode を使用することもできますが、URL が再び醜くなります :)

于 2010-03-16T23:26:07.623 に答える
8

このサイトに出くわしたベストプラクティスを探しています：

http://www.restapitutorial.com

リソース ページには、著者が提案する完全な REST ベスト プラクティスを含む .pdf をダウンロードするためのリンクがあります。とりわけ、ページネーションに関するセクションがあります。

著者は、Range ヘッダーの使用とクエリ文字列パラメーターの使用の両方にサポートを追加することを提案しています。

リクエスト

HTTP ヘッダーの例:

Range: items=0-24

クエリ文字列パラメーターの例:

GET http://api.example.com/resources?offset=0&limit=25

ここで、 offsetはアイテムの開始番号で、limitは返されるアイテムの最大数です。

応答

応答には、返されたアイテムの数と、まだ取得されていない合計アイテム数を示す Content-Range ヘッダーが含まれている必要があります。

HTTP ヘッダーの例:

Content-Range: items 0-24/66

Content-Range: items 40-65/*

.pdf には、より具体的なケースに対するその他の提案がいくつかあります。

于 2016-03-08T16:54:13.517 に答える
7

クエリ パラメータのオフセットと制限を使用することをお勧めします。

offset : コレクション内のアイテムのインデックス。

limit : アイテムの数。

クライアントは、次のようにオフセットを更新し続けることができます。

offset = offset + limit

次のページのために。

パスはリソース識別子と見なされます。また、ページはリソースではなく、リソース コレクションのサブセットです。ページネーションは一般に GET リクエストであるため、クエリ パラメータはヘッダーではなくページネーションに最適です。

参考：https ://metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page

于 2015-07-23T09:05:53.397 に答える
5

現在、ASP.NETMVCアプリでこれと同様のスキームを使用しています。

例えばhttp://application/products/by-date/page/2

具体的には：http://application/products/Date/Ascending/3

ただし、この方法でルートに情報のページングと並べ替えを含めることにはあまり満足していません。

アイテム（この場合は製品）のリストは変更可能です。つまり、次に誰かがページングと並べ替えのパラメータを含むURLに戻ったときに、取得する結果が変更されている可能性があります。したがって、http://application/products/Date/Ascending/3定義された不変の製品セットを指す一意のURLとしての概念は失われます。

于 2009-04-22T10:16:49.890 に答える
1

私は、「ページ」は実際にはリソースではないというslfに同意する傾向があります。一方、オプション3は、よりクリーンで読みやすく、ユーザーが簡単に推測でき、必要に応じて入力することもできます。オプション1と3の間で引き裂かれましたが、オプション3を使用しない理由はわかりません。

また、見た目は良いですが、誰かが言ったように、クエリ文字列やURLセグメントではなく、非表示のパラメータを使用することの1つの欠点は、ユーザーが特定のページをブックマークしたり直接リンクしたりできないことです。これは、アプリケーションによっては問題になる場合とそうでない場合がありますが、注意が必要なことです。

于 2009-04-22T14:05:42.773 に答える
0

私は自分のプロジェクトで次の URL を使用しています。

http://application/products?page=2&sort=+field1-field2

つまり、「フィールド 1 で昇順、フィールド 2 で降順に並べられた 2 番目のページを表示してください」という意味です。または、さらに柔軟性が必要な場合は、次を使用します。

http://application/products?skip=20&limit=20&sort=+field1-field2
于 2014-07-13T23:59:22.633 に答える
0

以前にソリューション 3 を使用したことがあります (私はたくさんの django アプリを作成しています)。そして、私はそれが間違っているとは思いません。他の 2 つと同じように生成可能で (マス スクレイピングなどを行う必要がある場合)、見た目もきれいです。さらに、ユーザーは URL を推測することができ (公開アプリの場合)、ユーザーは目的の場所に直接移動できることを好み、URL 推測は力を与えてくれます。

于 2009-04-22T11:41:57.470 に答える