「発見可能」が不可能なREST構造

Question

REST/HATEOASサービスを最適に定義する方法については、莫大な数のために利用可能なリソースオプションを徹底的にリストアップする可能性はありません。

特に、システムの一部は、大規模なコーパスのテキスト（GET http://mysite.org/word_statistics/foobarのようなもの）のインデックス付き単語使用統計のリソースとなり、foobarが使用されているドキュメントにfoobarとURIの情報を返します。

しかし、私はアプリは、実際のhttp://mysite.org/word_statistics/foobarリンクを発見する可能性のある合理的な方法を提供することはできません - 標準的なアプローチは、個々のURIのリストを返しますhttp://mysite.org/word_statisticsなどのリソースを提供することのようですが、私の場合は、そのリストはおよそ1ギガバイトであり、合理的に実用的ではありません。だから私はhttp://mysite.org/word_statistics/ {your_query_here}のようなものを要求するアプリケーションを与える必要があるだろうが、それを行うためのRESTfulな方法はないようだ。

これはどのように正しく行う必要がありますか？

Answer 1

多くの場所で使用されている古典的な検索パターンに従います。

• http://example.org/word_statistics - これはすべて、言葉やリンクを返しますが、あなたはすべてを返すようにしたくないので、あなたは何をすべきか、クエリオプションの、おそらく説明して適切なエラーコードを返さないで、代わりにんサポート。または、すべてを返すこともできますが、ページ（10,100,1000ワードずつ）で返すことができます。

• http://example.org/word_statistics/ {word} - 指定した単語の統計情報です。

• http://example.org/word_statistics?like=word - これは「似ている」という単語のリストを返します。これは、スペルミスやサマリーなどを処理できます。

• http://example.org/word_statistics?from_word=word1&to_word=word2 - from_wordでアルファベット順に開始し、to_wordに移動するが、元のリストと同じ制限とページングの制約の下にある単語のリストを返します。 - 彼らの統計情報へのリンクと、ちょうどその文書にある単語を返し

  • http://example.org/ {文書} /言葉：

  また、のような何かを行うことができます。

ここで行うことができるすべての種類。しかし、要点は、基本的な検索パターンは、ニーズを容易に満たす必要があるということです。