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

Question

利用可能なリソースオプションの数が非常に多いため、利用可能なリソースオプションを網羅的にリストすることが不可能な場合に、REST/HATEOASサービスを最適に定義する方法についてのオプションを見つけるのに苦労しています。

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

ただし、アプリが実際のhttp://mysite.org/word_statistics/foobarリンクを検出する合理的な方法を提供することはできません。標準的なアプローチはhttp://mysite.org/word_statisticsのようなリソースを提供することのようです。これは個々のURIのリストを返しますが、私の場合、そのリストは約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-これは、「like」単語である単語のリストを返します。これは、スペルミスやsoundalikesなどを処理できます。

• http://example.org/word_statistics?from_word=word1&to_word=word2-アルファベット順にfrom_wordで始まり、to_wordに進む単語のリストを返しますが、元のリストと同じ制限とページングの制約があります。 。

次のようなこともできます。

• http://example.org/ {document} / words-統計へのリンクとともに、そのドキュメントに含まれている単語を返します。

ここでできるあらゆる種類のこと。ただし、要点は、基本的な検索パターンでニーズを簡単に満たす必要があるということです。