5

私の質問はいくつかの例でよりよく説明されると思います...

GET http：// myservice / myresource /？name = xxx＆country = xxxx＆_page = 3＆_page_len = 10＆_order = name asc

つまり、一方では条件（name = xxx＆country = xxxx）があり、他方ではクエリに影響を与えるパラメータがあります（_page = 3＆_page_len = 10＆_order = name asc）

ここで、条件とパラメーターの衝突を回避するために、特別なプレフィックス（この場合は「_」）を使用することについて考えました（リソースに「order」プロパティがある場合はどうなりますか？）

これらの状況を処理するための標準的な方法はありますか？

-

私はこの例を見つけました（1つを選ぶだけです） http://www.peej.co.uk/articles/restfully-delicious.html

GET http://del.icio.us/api/peej/bookmarks/?tag=mytag&dt=2009-05-30&start=1&end=2

ただし、この場合、条件フィールドはすでに定義されています（開始プロパティも終了プロパティもありません）

私はいくつかの一般的な解決策を探しています...

-編集、明確にするためのより詳細な例

各アイテムは互いに完全に独立しています...私のリソースが顧客であり、（幸運なことに）データベースに数百万のアイテムがあるとします。

したがって、URLは次のようになります。

http：// myservice / customers /？country = argentina、last_operation = 2009-01-01..2010-01-01

昨年何かを購入したアルゼンチンのすべての顧客を私に与えるはずです

たとえば、このサービスを使用して参照ページを作成したり、コンボをajaxで埋めたりしたいので、取得する情報を制御するためにメタダを追加するというアイデアがありました。

参照ページを作成するには、追加します

http：//...,_page=1,_page_len=10,_order=state,name

オートサジェストコンボをajaxで埋める

http：//...,_page=1,_page_len=100,_order=state,name,name=what_ever_type_the_user *

ユーザーが入力したものと一致する最初の100人の顧客でコンボを埋める...

私の質問は、この種のものをレストフルURL方式でエンコードする標準的な（書かれているかどうかにかかわらず）方法があるかどうかでした...

4

4 に答える 4

5

標準はありませんが、Web API Design (Apigee による) は、Web API を作成する際の優れたアドバイスです。私はそれを一種の標準として扱い、可能な限りその推奨事項に従います。

「ページネーションと部分的な応答」の下で、彼らは提案します（17ページ）：

制限とオフセットを使用

limit と offset をお勧めします。より一般的であり、主要なデータベースでよく理解されており、開発者にとっては簡単です。

/dogs?limit=25&offset=50
于 2013-11-12T10:02:34.100 に答える
2

これを行う方法を定義する標準や規則はありませんが、メタ情報を示すためにアンダースコア（1つまたは2つ）を使用することは悪い考えではありません。これは、一部の言語では慣例によりメンバー変数を指定するために使用されるものです。

于 2009-05-30T13:32:26.713 に答える
2

注：これは 、以前の回答へのコメントとして書き始めました。それから編集として追加するつもりでしたが、代わりに別の回答として属していると思います。これはまったく異なるアプローチであり、別のアプローチであるため、それ自体が別の答えです。

これについて考えれば考えるほど、対処しなければならないリソースが 2 つあります。

  1. リソースのページ
  2. ページに集められた各リソース

私は何かを見逃している可能性があります (おそらく... 私は誤解の罪を犯してきました)。ページはそれ自体がリソースであるため、ページングメタ情報は実際にはリソースの属性であるため、URL に配置することは必ずしも間違ったアプローチではありません。ページのダウンストリームに何がキャッシュされ、将来リソースとして参照されるかを検討する場合、リソースはページング属性とクエリ パラメータによって定義されるため、両方が URL に含まれている必要があります。あまりにも長すぎる回答を続けると、ページ リソースは次のようになります。

http://.../myresource/page-10/3?name=xxx&country=yyy&order=name&orderby=asc

これがあなたの元の質問の核心に達すると思います。ページ自体がリソースである場合、URI はページを記述する必要があるため、「10 項目のページ」のようなものpage-10で、ページの次の部分はページ番号です。クエリ部分にはフィルターが含まれています。

他のリソースは、ページに含まれる各アイテムに名前を付けます。アイテムの識別方法は、リソースが何であるかによって制御する必要があります。結果のリソースが独立しているかどうかが重要な問題だと思います。アイテムリソースの表現方法は、この概念に基づいて異なります。

アイテムの表現がページのコンテキスト内でのみ適切である場合は、表現をインラインで含めることが適切な場合があります。これを行う場合は、それらを個別に識別し、URI フラグメント構文または追加のパス要素を使用してそれらを取得できることを確認してください。次の URL では、10 項目の 3 ページ目の 5 番目の項目が表示されるはずです。

http://.../myresource/page-10/3?...#5
http://.../myresource/page-10/3/5?...

この 2 つを決定する最大の要因は、個々のアイテムがページとどの程度強く結びついているかです。フラグメント構文は、パス要素の IMHO よりもかなり拘束力があります。

ここで、アイテム リソースが独立しており、ページが単にクエリの結果である場合 (ここではその可能性が高いと思います)、ページ リソースは各アイテム リソースの URL の順序付けられたリストである必要があります。この場合、アイテム リソースはページ リソースから独立している必要があります。アイテム自体の識別属性に基づく URI を使用することができます。したがって、次のような結果になる可能性があります。

http://.../myresource/item/42
http://.../myresource/item/307E8599-AD9B-4B32-8612-F8EAF754DFDB

重要な決定要因は、項目が独立したリソースであるかどうかです。そうでない場合は、ページ URI から取得されます。それらが独立している場合、それらは独自のリソースによって定義されている必要があり、代わりにリンクとしてページリソースに含まれている必要があります。

于 2009-05-31T15:11:12.013 に答える
1

RESTful な人々は HTTP ヘッダーの使用を嫌う傾向があることは知っていますが、ページネーションを解決するためにHTTP 範囲を使用することを実際に検討した人はいますか。私は数年前に、ページネーション情報とその他の非プロパティ情報を URI に含めた ISAPI 拡張機能を作成しましたが、その感触があまり好きではありませんでした。私は次のようなことを考えていました：

GET http://...?name=xxx&country=xxxx&_orderby=name&_order=asc HTTP/1.1
Range: pageditems=20-29
...

これにより、結果セットのパラメーター (_orderbyおよび など_order) が URI に設定され、選択内容がRangeヘッダーとして設定されます。特に非バイト範囲のサポートはRFC2616の5月であるため、ほとんどのHTTP実装はこれを台無しにするだろうと感じています。RTSPで多くの作業を行った後、私はこれについてより真剣に考え始めました。RangeRTSPのヘッダーは、範囲を拡張して時間とバイトを処理する良い例です。

これを処理する別の方法は、ページ上の各アイテムを個別のリソースとして個別にリクエストすることだと思います。あなたの表現がこれを可能にするならば、あなたはそれを検討したいかもしれません。このアプローチでは、中間キャッシュが非常にうまく機能する可能性が高くなります。したがって、リソースは次のように定義されます。

myresource/name=xxx;country=xxx/orderby=name;order=asc/20/
myresource/name=xxx;country=xxx/orderby=name;order=asc/21/
myresource/name=xxx;country=xxx/orderby=name;order=asc/22/
myresource/name=xxx;country=xxx/orderby=name;order=asc/23/
myresource/name=xxx;country=xxx/orderby=name;order=asc/24/

誰かがこのようなことを試したかどうかはわかりません。これにより、常に有用なプロパティ IMHO である URI が構築可能になります。このアプローチの利点は、個々の応答をキャッシュできることと、サーバーがアイテムのページ収集の処理を最適化し、最も効率的な方法ではないことです。基本的な考え方は、URI でクエリを指定し、取得する項目のインデックスをクライアントに指定させることです。「ページ」のアイデアをリソースにプッシュしたり、表示する必要さえありません。クライアントは、ページがいっぱいになるか、404 を受け取るまで、繰り返しオブジェクトを取得できます。

もちろん欠点もあります... HTTP サーバーとインフラストラクチャがパイプラインをサポートする必要があるか、接続の作成/破棄のコストがアイデアを完全に台無しにする可能性があります。

于 2009-05-30T15:53:32.937 に答える