3

効率的な方法で多次元データにアクセスするには、REST をどのように使用すればよいでしょうか? 選択肢は、hi-REST、lo-REST、または OpenSearch のようです (これは、lo-REST の特殊化のようです)。

4

2 に答える 2

2

システムをRESTfulにするための要件の1つは、クライアントがURIの構造について事前に何も知らないことです。これは、ほとんどのTwitterクライアントのように特定の方法でURIを構築するコードを記述できないことを意味します。従来の知識では、リソースを見つけるには、別の場所でそのURIを検出する必要があります。

ただし、システム内で無数のリソースを処理している場合があり、それぞれへのリンクを提供することはまったく愚かです。多次元データはこのカテゴリに当てはまります。このような場合、実行時にこれらのルールが検出される限り、URI構築のルールをクライアントに提供することは完全に有効です。

OpenSearchは、この問題に対するRESTfulなソリューションであり、プログラマーにとっても使いやすいものです。OpenSearchの使用の多くは、人間が読める形式のHTML検索結果に限定されていますが、実際には、純粋に機械可読（アトムなど）の検索結果にも使用できます。

<Url type="application/atom+xml"
     template="...search/?q={searchTerms}"/>

このテンプレートは、アトム表現が必要な場合はここに移動できることをクライアントに指示します。しかし、これは多次元データにどのように適合しますか？ここで、OpenSearchの拡張性が発揮されます。OpenSearch時間拡張機能は、特定の時間範囲に制限された検索を表すURLを作成するようにクライアントに指示する方法を説明します（xmlns:time正しくバインドされていると仮定します。

<Url type="application/atom+xml"
     template="...search/?after={time:start}&amp;before={time:end}"/>

クライアントがこのテンプレートを見ると、時間の制約しか許されていないことがテンプレートからわかります。自分で拡張してみましょう。

OpenSearchを拡張するには、名前空間とその名前空間内のいくつかの要素を指定して、特定の何かを意味する必要があります。他の人がドキュメントにアクセスして独自のサーバーとクライアントを実装できるように、これはどこかに公開する必要があります。顧客を姓で検索したいとします。姓はかなり一般的な用語ですが、標準化されているほど普遍的ではありません。名前空間を定義nameし、OpenSearchの説明のプレフィックスにバインドして、次のテンプレートを公開するとします。

<Url type="application/atom+xml"
     template="...search?lastName={name:last}"/>

このテンプレートは、私の名前空間を理解しているすべてのクライアントにname、テンプレートに入力することで姓の検索を実行できることを指示します。

これはまだ多次元ではありませんが、別の次元を追加しましょう。地理。幸い、地理のOpenSearchドラフト拡張機能があり、バウンディングボックスまたは円内で検索できます。

<Url type="application/atom+xml"
     template="...search/?latitude={geo:lat?}&amp;
                          longitude={geo:lon?}&amp;
                          metres={geo:radius?}"/>

テンプレートを分割して読みやすくしています。

テンプレートは、1つの次元（地理空間）内でのみ検索できるため、依然として多次元ではありません。では、どのように多次元検索を行いますか？多次元検索を行う方法を示すテンプレートを提供します。これは、組み合わせるのが理にかなっています。

たとえば、次のテンプレートを使用すると、別の地域（2次元）で特定の名前の人を見つけることができます。

<Url type="application/atom+xml"
     template="combo-find?customerLastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          radius={geo:radius?}"/>

これは、時間の制約とともに、名前と地理空間を制約できるテンプレートです（ただし、OpenSearch Time拡張機能は、探している時刻については何も表示しません）。

<Url type="application/atom+xml"
     template="...search/?lastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          r={geo:radius?}&amp;
                          after={time:start}&amp;
                          before={time:end}"/>

これらの例では、クライアントはURIテンプレートを自由に調べて、入力するURIテンプレートパラメーターを把握できます。したがって、クライアントは、各URIテンプレートがサポートするディメンションを認識し、いつでもどのURIが最適であるかを判断できます。

これらすべてのRESTfulnessは、すべてのREST制約が尊重されるためです。ステートレスであり、ハイパーメディアはエンジンであり、階層化されています。OpenSearchは単なる別のハイパーメディア形式であり、非常に優れています。

于 2010-08-19T10:52:22.527 に答える
0

hi-REST と lo_REST という用語を Google で検索した結果、どちらを選択しても効率に大きな影響はないと思います。むしろ、どれだけ「正しく」なりたいかという問題です。

Hi-REST の方が間違いなく「正しい」と言えますが、Hi-REST の使用が効率に大きな影響を与えるとは思えません。データを転送するために選択したデータ表現 (つまり、XML、バイナリ XML、JSON など) は、データ パフォーマンスにはるかに大きな影響を与えます。

于 2010-08-18T23:03:28.360 に答える