ドキュメントの検索 (Azure Cognitive Search REST API)

クエリ要求では、search サービスの単一インデックスのドキュメントコレクションが対象となります。 これには、一致条件を定義するパラメーターと、応答を形成するパラメーターが含まれます。

GET または POST を使用できます。 クエリパラメーター は、GET 要求の場合はクエリ文字列、POST 要求の場合は要求本文に指定されます。

GET https://[service name].search.windows.net/indexes/[index name]/docs?[query parameters] 
  Content-Type: application/json   
  api-key: [admin or query key]  
POST https://[service name].search.windows.net/indexes/[index name]/docs/search?api-version=[api-version]  
  Content-Type: application/json  
  api-key: [admin or query key]  

GET を使用して呼び出された場合、要求 URL の長さが 8 KB を超えることはできません。 この長さは通常、ほとんどのアプリケーションに対して十分です。 ただし、一部のアプリケーションでは、特に OData フィルター式が使用される場合に、非常に大きなクエリが生成されます。 これらのアプリケーションでは、GET よりも大きなフィルターが許可されるため、HTTP POST の方が適しています。

POST 要求のサイズ制限がほぼ 16 MB であるため、POST を使用する場合は、フィルター文字列のサイズそのものではなく、フィルターに含まれる句の数が制限要因になります。 POST 要求のサイズ制限が非常に大きいとはいえ、フィルター式を任意に複雑にすることはできません。 フィルターの複雑さの制限の詳細については、「 Azure Cognitive Search の OData 式の構文」を参照してください。

URI パラメーター

パラメーター 説明
[サービス名] 必須。 これを、検索サービスの一意のユーザー定義名に設定します。
[インデックス名]/ドキュメント 必須。 名前付きインデックスのドキュメントコレクションを指定します。
[クエリパラメーター] クエリパラメーターは、GET 要求の場合は URI で、POST 要求の場合は要求本文に指定されます。
api-version 必須。 現在の安定バージョンは api-version=2020-06-30 です。 詳細については、「 API バージョン 」を参照してください。 クエリの場合、api バージョンは常に GET と POST の両方の URI パラメーターとして指定されます。

URL エンコードに関する推奨事項

GET REST API を直接呼び出すときは、特定のクエリパラメーターを URL エンコード することを忘れないでください。 検索ドキュメント 操作の場合、次のクエリパラメーターには URL エンコードが必要になることがあります。

  • search
  • $filter
  • facet
  • highlightPreTag
  • highlightPostTag

URL エンコードは、個々のパラメーターに対してのみ推奨されます。 クエリ文字列全体 (? の後の全部) を気付かずに URL エンコードした場合、要求が壊れます。

また、URL エンコードは、GET を使用して REST API を直接呼び出すときにのみ必要です。 POST を使用する場合や、エンコードを処理する Azure Cognitive Search .net クライアントライブラリを使用する場合は、URL エンコードは必要ありません。

要求ヘッダー

次の表では、必須と省略可能の要求ヘッダーについて説明します。

フィールド 説明
Content-Type 必須。 これを "application/json" に設定します。
api-key 必須。 検索サービスへの要求を認証する、システムによって生成される一意の文字列。 Documents コレクションに対するクエリ要求では、管理者キーまたはクエリキーを API キーとして指定できます。 クエリキーは、ドキュメントコレクションに対する読み取り専用操作に使用されます。 API キーは、Azure portal の検索サービスダッシュボードで確認できます。

要求本文

GET の場合: なし。

POST の場合:

{  
     "count": true | false (default),  
     "facets": [ "facet_expression_1", "facet_expression_2", ... ],  
     "filter": "odata_filter_expression",  
     "highlight": "highlight_field_1, highlight_field_2, ...",  
     "highlightPreTag": "pre_tag",  
     "highlightPostTag": "post_tag",  
     "minimumCoverage": # (% of index that must be covered to declare query successful; default 100),  
     "orderby": "orderby_expression",  
     "queryType": "simple" (default) | "full",
     "scoringParameters": [ "scoring_parameter_1", "scoring_parameter_2", ... ],  
     "scoringProfile": "scoring_profile_name",  
     "scoringStatistics" : "local" | "global",
     "search": "simple_query_expression",  
     "searchFields": "field_name_1, field_name_2, ...",  
     "searchMode": "any" (default) | "all",  
     "select": "field_name_1, field_name_2, ...",  
     "sessionId" : "session_id",
     "skip": # (default 0),  
     "top": #  
   }  

部分的な検索応答の継続

Azure Cognitive Search は、要求されたすべての結果を単一の検索応答で返すことはできません。 これは、$top を指定しなかったり、大きすぎる $top の値を指定したりすることによって、クエリが大量のドキュメントを要求する場合など、さまざまな理由で発生する可能性があります。 このような場合、Azure Cognitive Search には、 @odata.nextLink 応答本文に注釈が含められ @search.nextPageParameters ます。また、POST 要求の場合も同様です。 これらの注釈の値を使用して別の Search 要求を作成して、検索応答の次の部分を取得できます。 これは元の Search 要求の 継続 と呼ばれ、注釈は一般に 継続トークン と呼ばれます。 これらの注釈の構文の詳細と、応答本文に表示される場所については、後述の「応答」の例を参照してください。

Azure Cognitive Search が継続トークンを返す理由は実装固有であり、変更される可能性があります。 堅牢なクライアントでは、返されたドキュメントが予想よりも少なく、ドキュメントの取得を継続するために継続トークンが含まれている場合を処理する準備が常にできている必要があります。 また、継続するためには、元の要求と同じ HTTP メソッドを使用する必要がある点にも注意してください。 たとえば、GET 要求を送信した場合、送信する継続の要求でも GET を使用する必要があります (POST の場合も同様です)。

注意

との目的は、 @odata.nextLink @search.nextPageParameters ページングのための一般的なメカニズムを提供するのではなく、多数の結果を要求するクエリからサービスを保護することです。 結果を表示するには、$top を使用し、$skip します。 たとえば、サイズが10のページが必要な場合、最初の要求には $top = 10 および $skip = 0、2番目の要求には $top = 1、$skip = 10、3番目の要求には $top = 10 および $skip = 20 を指定する必要があります。

クエリ パラメーター

クエリでは、GET で呼び出された場合は URL に対して複数のパラメーターを受け取り、POST で呼び出された場合は要求本文の JSON プロパティとしてを受け取ります。 いくつかのパラメーターの構文は、GET および POST の間で多少異なります。 これらの違いについては、以下で説明します。

Name 種類 説明
api-version string 必須。 要求に使用された REST API のバージョン。 サポートされているバージョンの一覧については、「 API バージョン」を参照してください。 この操作では、GET または POST を使用して 検索ドキュメント を呼び出すかどうかにかかわらず、api バージョンは URI パラメーターとして指定されます。
$count boolean 任意。 有効な値は true または false です。 既定値は "false" です。 POST で呼び出された場合、このパラメーターは $count ではなく、count という名前になります。 結果の合計数を取得するかどうかを指定します。 これは、検索パラメーターと $filter パラメーターに一致し、$top と $skip を無視するすべてのドキュメントの数です。 この値を "true" に設定すると、パフォーマンスが低下する可能性があります。 返されるカウントは概数です。 ドキュメントを含まない数のみを取得する場合は、$top = 0 を使用できます。
facet string 任意。 ファセットの対象となるフィールド。 文字列には、コンマ区切りの名前と値のペアとして表現されるファセットをカスタマイズするためのパラメーターを含めることができます。 POST で呼び出された場合、このパラメーターはファセットではなく、ファセットとして指定されます。

有効な値は、"count"、"sort"、"values"、"interval"、および "timeoffset" です。

"count" はファセット用語の最大数です。既定値は10です。 用語の数に上限はありませんが、値を大きくするとパフォーマンスが低下します。ファセットフィールドに一意の用語が多数含まれている場合は特にそうです。 たとえば、"facet = category, count: 5" は、ファセットの結果の上位5つのカテゴリを取得します。 Count パラメーターが一意の用語の数より小さい場合、結果が正確ではない可能性があります。 これは、ファセット クエリがシャード間に分散される方法のためです。 カウントを増やすと、一般に、用語の数の精度が向上しますが、パフォーマンスは低下します。

"sort" は "count"、"-count"、"value"、"-value" に設定できます。 カウントで降順に並べ替えるには、count を使用します。 カウントを使用して昇順で並べ替えるには、-count を使用します。 値で昇順に並べ替えるには、値を使用します。 値で降順に並べ替えるには-value を使用します (たとえば、"facet = category, count: 3, sort: count" は、ファセットの結果内の上位3つのカテゴリを、各都市名を持つドキュメントの数の降順で取得します)。 上位 3 つのカテゴリが「予算」、「ホテル」、および「高級」であり、「予算」のヒット数が 5、「ホテル」のヒット数が 6、「高級」のヒット数が 4 である場合、バケットは「ホテル」、「予算」、「高級」の順番に並べられます。 -Value、"facet = 格付け、sort:-value" は、すべての可能な評価のバケットを値で降順に生成します (たとえば、評価が 1 ~ 5 の場合、各評価が一致するドキュメントの数に関係なく、バケットは5、4、3、2、1の順に並べ替えられます)。

"値" は、パイプで区切られた数値または Edm に設定できます。ファセットエントリ値の動的セットを指定する DateTimeOffset 値 (たとえば、"facet = baseRate, values:10 | 20" は3つのバケットを生成します。1つは基本速度0、10を除く10、20以上、20以上) です。 文字列 "facet = Lastrrenovated Vationdate, values: 2010-02-01T00:00: 00Z" は2つのバケットを生成します。1つは2010年2月より前のホテル renovated、もう1つはホテル2月1日2010以降のバケットです。

"interval" は、数値、分、時、日、週、月、四半期、日付と時刻の値について、0より大きい整数間隔です。 たとえば、"facet = baseRate, interval: 100" は、サイズ100の基本料金範囲に基づいてバケットを生成します。 基本料金がすべて $60 と $600 の間にある場合は、0-100、100-200、200-300、300-400、400-500、および500-600 のバケットが存在します。 文字列 "facet = Lastrrenovated Vationdate, interval: year" は、ホテルがされた年ごとに1つのバケットを生成します。

"timeoffset" は、([+-] hh: mm、[+-] hhmm、または [+-] hh) に設定できます。 Timeoffset パラメーターを使用する場合は、interval オプションと組み合わせて使用する必要があります。これは、型のフィールドに適用されている場合のみです。 この値によって、時間の境界の設定における UTC 時刻のオフセットを指定します。 たとえば、"facet = Lastrの Vationdate, interval: day, timeoffset:-01:00" は、01:00:00 UTC (ターゲットタイムゾーンでは深夜 0) から始まる日の境界を使用します。

count と sort は同じファセットの仕様で組み合わせることができますが、間隔や値と組み合わせることはできません。また、間隔と値を一緒に組み合わせることはできません。

日付時刻の間隔ファセットは、timeoffset が指定されていない場合の UTC 時刻に基づいて計算されます。 例: "facet = Lastrの Vationdate, interval: day" の場合、日の境界は 00:00:00 UTC で開始されます。
$filter string 任意。 標準の OData 構文で構造化された検索式です。 フィルターで使用できるのは、フィルター可能なフィールドのみです。 POST を使用してを呼び出す場合、このパラメーターは $filter ではなく filter という名前になります。 Azure Cognitive Search でサポートされている OData 式の文法の詳細については、「 azure Cognitive Search の Odata 式の構文 」を参照してください。
highlight string 任意。 ヒット ハイライトに使用する一連のフィールド名で、コンマで区切ります。 検索可能なフィールドだけを、ヒットの強調表示に使用できます。 既定では、Azure Cognitive Search によって、フィールドごとに最大5個のハイライトが返されます。 この制限は、フィールド名の後に "-<max # of ハイライト>" を追加することで、フィールドごとに構成できます。 たとえば、"強調表示 = タイトル-3, 説明-10" は、[タイトル] フィールドから最大3個の強調表示されたヒットを返し、[説明] フィールドから最大10件のヒットを返します。 ハイライトの最大数は、1 ~ 1000 の範囲の整数である必要があります。
highlightPostTag string 任意。 既定値は "</em>" です。 強調表示された語句に追加する文字列タグ。 HighlightPreTag を使用して設定する必要があります。 URL の予約済みの文字は、パーセントでエンコードする必要があります (たとえば、# ではなく %23)。
highlightPreTag string 任意。 既定値は "</em>" です。 強調表示された語句の前に付加する文字列タグ。 HighlightPostTag を使用して設定する必要があります。 URL の予約済みの文字は、パーセントでエンコードする必要があります (たとえば、# ではなく %23)。
minimumCoverage 整数 (integer) 任意。 有効な値は、0から100までの数値です。これは、クエリを成功として報告するために必要なインデックスの割合を示します。 既定値は "100" です。

100% カバレッジは、すべてのシャードが要求に応答したことを意味します (サービス正常性の問題もメンテナンスアクティビティも対象外)。 既定の設定では、全カバレッジより小さい場合、HTTP 状態コード503が返されます。

MinimumCoverage を下げることは、503エラーが発生しており、クエリの成功率を上げる必要がある場合 (特に、1つのレプリカ用に構成されたサービスの場合) に役立ちます。 MinimumCoverage を設定して検索が成功した場合は、HTTP 200 が返され、 @search.coverage クエリに含まれていたインデックスの割合を示す値が応答に含まれます。 このシナリオでは、一致するすべてのドキュメントが検索結果に存在することが保証されるわけではありませんが、検索の可用性がリコールよりも重要な場合、カバレッジを減らすことは、実行可能な軽減策になります。
$orderby string 任意。 結果を並べ替える式の一覧で、コンマで区切ります。 POST で呼び出された場合、このパラメーターは $orderby ではなく orderby という名前になります。 各式には、フィールド名または geo. distance () 関数の呼び出しのいずれかを指定できます。 各式の後に "asc" を付けて昇順を示すことができ、"desc" を使用して降順を示すことができます。 並べ替えフィールドに null 値がある場合は、null 値が最初に昇順で、最後に降順で表示されます。 既定値は昇順です。 結び付きは、ドキュメントの一致スコアによって切り離されます。 $Orderby が指定されていない場合、既定の並べ替え順序はドキュメントの一致スコアによって降順になります。 $Orderby には、32の句の制限があります。
queryType string 任意。 有効な値は、"simple" または "full" です。 既定値は "simple" です。

"simple" は、、、などのシンボルを許可する 単純なクエリ構文 を使用して、クエリ文字列を解釈し + * "" ます。 クエリは、既定では、各ドキュメントの検索可能なフィールド (または searchFields に示されているフィールド) 全体で評価されます。

"full" は、フィールド固有の検索と重み付け検索を可能にする 完全な Lucene クエリ構文 を使用して、クエリ文字列を解釈します。 Lucene クエリ言語の範囲検索は、同様の機能を提供する $filter が用意されているため、サポートされません。
scoringParameter string 任意。 "Name-value1, value2,..." の形式を使用して、スコアリング関数 (referencePointParameter など) で定義されている各パラメーターの値を示します。POST で呼び出された場合、このパラメーターは scoringParameter ではなく scoringParameters という名前になります。 また、各文字列が個別の名前と値のペアである文字列の JSON 配列として指定します。

関数を含むスコアリングプロファイルの場合は、関数を入力リストから文字で区切り - ます。 たとえば、という関数は、 "mylocation" "&scoringParameter = mylocation--122.2, 44.8" になります。 最初のダッシュは、値リストから関数名を区切ります。2番目のダッシュは最初の値の一部です (この例では経度)。

タグ ブーストなどに使用するスコア パラメーターは、コンマを含む場合があります。その場合、リスト内では単一引用符を使用してこのような値をエスケープすることができます。 値自体に単一引用符が含まれる場合は、2 個入力することでエスケープできます。 タグブーストパラメーターが呼び出され、 "mytag" タグ値 "hello, O'Brien" および "Smith" でブーストする場合、クエリ文字列オプションは "&scoringParameter = mytag-' Hello, O ' ' Brien ', Smith" になります。 引用符は、コンマを含む値に対してのみ必要です。
scoringProfile string 任意。 結果を並び替えるために一致ドキュメントの一致スコアを評価するスコア付けプロファイルの名前。
scoringStatistics string 任意。 有効な値は、"local" または "global" です。 既定値は "local" です。 ドキュメントの頻度、グローバルに (すべてのシャードを対象)、より一貫性のあるスコアリングのために (または、現在のシャードで) ローカル (現在のシャードで) の待機時間の統計を計算するかどうかを指定します。 「 Azure Cognitive Search でのスコア付けの統計」を参照してください。 スコアリング統計は、あいまい検索を使用する用語 (' ~ ')に対して常にローカルで計算されます。
search string 任意。 検索するテキストです。 SearchFields が指定されていない限り、検索可能なすべてのフィールドが既定で検索されます。 インデックスでは、検索可能フィールド内のテキストがトークン化されるため、複数の用語を空白で区切ることができます (例: ' search = hello world ')。 任意の語句と一致させるには、 * を使用します (これはブール型フィルターのクエリに便利です)。 このパラメーターを省略することは、 *に設定するのと同じ効果を持ちます。 検索構文の詳細については、 簡単なクエリ構文 に関するページを参照してください。

検索可能なフィールドに対してクエリを実行すると、結果が意外になることがあります。 トークナイザには、アポストロフィや数字の中のコンマのように、英語のテキストによく使用されているケースを処理するロジックが含まれています。 たとえば、' search = 123456 ' は個別の用語 ' 123 ' および ' 456 ' ではなく、1つの用語 ' 123456 ' と一致します。これは、英語では、コンマが大きな数値の桁区切り記号として使用されるためです。 このため、検索パラメーターで用語を区切るには、句読点ではなく空白文字を使用することをお勧めします。
searchMode string 任意。 有効な値は "any" または "all" で、既定値は "any" です。 一致ドキュメントをカウントする上で、検索用語の一部が一致すればよいか、それともすべて一致する必要があるかを指定します。
searchFields string 任意。 指定したテキストを検索するフィールド名の一覧であり、コンマで区切ります。 ターゲットフィールドは、インデックススキーマで検索可能としてマークされている必要があります。
$select string 任意。 結果セットに含めるコンマ区切りのフィールドの一覧。 この句には、取得可能としてマークされているフィールドのみを含めることができます。 指定しない場合、または *に設定した場合は、スキーマで取得可能とマークされているすべてのフィールドが含まれます。 POST で呼び出された場合、このパラメーターは $select ではなく select という名前になります。
sessionID string 任意。 SessionId を使用すると、複数のレプリカを持つ検索サービスの関連性スコアの一貫性が向上します。 マルチレプリカ構成では、同じクエリに対して個々のドキュメントの関連性スコアがわずかに異なる場合があります。 セッション ID を指定すると、サービスは、そのセッションの同じレプリカに対して、指定された要求をルーティングするためのベストエフォートを行います。 同じセッション ID 値を繰り返し再利用すると、複数のレプリカ間で要求の負荷分散が妨げられ、search サービスのパフォーマンスに悪影響を及ぼす可能性があります。 sessionId として使用される値は、'_' 文字で始めることはできません。 サービスにレプリカがない場合、このパラメーターはパフォーマンスやスコアの一貫性に影響しません。
$skip 整数 (integer) 任意。 スキップする検索結果の数です。 POST で呼び出された場合、このパラメーターには $skip ではなく skip という名前が付けられます。 この値を10万より大きくすることはできません。 ドキュメントを順番にスキャンする必要があり、この制限のために $skip を使用できない場合は、インデックス内のすべてのドキュメントに対して一意の値を持つフィールド (たとえば、ドキュメントキーなど) に対して $orderby を使用することを検討してください。代わりに、範囲クエリを使用して $filter します。
$top 整数 (integer) 任意。 取得する検索結果の数です。 既定値は 50 です。 POST で呼び出された場合、このパラメーターの名前は $top ではなく、top になります。 1000より大きい値を指定し、1000を超える結果がある場合は、最初の1000の結果だけが結果の次のページへのリンクと共に返されます (次の例の「」を参照してください @odata.nextLink )。

Azure Cognitive Search では、 サーバー側のページング を使用して、クエリが大量のドキュメントを一度に取得するのを防ぐことができます。 既定のページサイズは50ですが、ページの最大サイズは1000です。 これは、$top を指定しない場合、既定では、 検索ドキュメント は最大50件の結果を返すことを意味します。 50件を超える結果がある場合、応答には、最大50件の結果の次のページを取得するための情報が含まれ @odata.nextLink @search.nextPageParameters ます (以下の では、「」および「」を参照してください)。 同様に、$top に1000より大きい値を指定し、1000以上の結果がある場合は、最初の1000の結果だけが返され、最大で1000の結果の次のページを取得するための情報も返されます。

Response

状態コード: 応答の成功に対して「200 OK」が返されます。

  {
    "@odata.count": # (if $count=true was provided in the query),
    "@search.coverage": # (if minimumCoverage was provided in the query),
    "@search.facets": { (if faceting was specified in the query)
      "facet_field": [
        {
          "value": facet_entry_value (for non-range facets),
          "from": facet_entry_value (for range facets),
          "to": facet_entry_value (for range facets),
          "count": number_of_documents
        }
      ],
      ...
    },
    "@search.nextPageParameters": { (request body to fetch the next page of results if not all results could be returned in this response and Search was called with POST)
      "count": ... (value from request body if present),
      "facets": ... (value from request body if present),
      "filter": ... (value from request body if present),
      "highlight": ... (value from request body if present),
      "highlightPreTag": ... (value from request body if present),
      "highlightPostTag": ... (value from request body if present),
      "minimumCoverage": ... (value from request body if present),
      "orderby": ... (value from request body if present),
      "scoringParameters": ... (value from request body if present),
      "scoringProfile": ... (value from request body if present),
      "scoringStatistics": ... (value from request body if present),
      "search": ... (value from request body if present),
      "searchFields": ... (value from request body if present),
      "searchMode": ... (value from request body if present),
      "select": ... (value from request body if present),
      "sessionId" : ... (value from request body if present),
      "skip": ... (page size plus value from request body if present),
      "top": ... (value from request body if present minus page size),
    },
    "value": [
      {
        "@search.score": document_score (if a text query was provided),
        "@search.highlights": {
          field_name: [ subset of text, ... ],
          ...
        },
        "@search.features": {
          "field_name": {
            "uniqueTokenMatches": feature_score,
            "similarityScore": feature_score,
            "termFrequency": feature_score,
          },
          ...
        },
        key_field_name: document_key,
        field_name: field_value (retrievable fields or specified projection),
        ...
      },
      ...
    ],
    "@odata.nextLink": (URL to fetch the next page of results if not all results could be returned in this response; Applies to both GET and POST)
  }

その他の例については、「 Azure Cognitive Search の OData 式の構文」を参照してください。

  1. 日付に基づいて降順で並べ替えられたインデックスを検索します。

    GET /indexes/hotels/docs?search=*&$orderby=LastRenovationDate desc&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "*",  
          "orderby": "LastRenovationDate desc"
        }  
    
  2. ファセット検索では、インデックスを検索し、カテゴリ、評価、タグ、および特定の範囲内の baseRate を持つ項目のファセットを取得します。

    GET /indexes/hotels/docs?search=*&facet=Category&facet=Rating&facet=Tags&facet=Rooms/BaseRate,values:80|150|220&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "test",  
          "facets": [ "Category", "Rating", "Tags", "Rooms/BaseRate,values:80|150|220" ]  
        }  
    

    最後のファセットがサブフィールドにあることに注意してください。 ファセットは、中間のサブドキュメント (部屋) ではなく、親ドキュメント (ホテル) をカウントするので、応答によって、各価格バケットにルームがあるホテルの数が決定されます。

  3. フィルターを使用して、ユーザーが評価3とカテゴリ "Motel" を選択した後に、前のファセットクエリの結果を絞り込みます。

    GET /indexes/hotels/docs?search=*&facet=tags&facet=Rooms/BaseRate,values:80|150|220&$filter=Rating eq 3 and Category eq 'Motel'&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "test",  
          "facets": [ "tags", "Rooms/BaseRate,values:80|150|220" ],  
          "filter": "Rating eq 3 and Category eq 'Motel'"  
        }  
    
  4. ファセット検索で、クエリで返される一意の語句に上限を設定します。 既定値は 10 ですが、ファセット属性でカウント パラメーターを使用することで、この値を増減できます。 この例では、5 に制限された、都市のファセットを返します。

    GET /indexes/hotels/docs?search=*&facet=Address/City,count:5&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "test",  
          "facets": [ "Address/City,count:5" ]  
        }  
    
  5. 特定のフィールド (たとえば、言語フィールド) 内のインデックスを検索します。

    GET /indexes/hotels/docs?search=hôtel&searchFields=Description_fr&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "hôtel",  
          "searchFields": "Description_fr"
        }  
    
  6. 複数のフィールドにまたがるインデックスを検索します。 たとえば、複数の言語の検索可能なフィールドをすべて同じインデックスに格納してクエリできます。 英語とフランス語の説明が同じドキュメントに共存している場合、いずれかまたはすべてをクエリ結果で返すことができます。

    GET /indexes/hotels/docs?search=hotel&searchFields=Description,Description_fr&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "hotel",  
          "searchFields": "Description, Description_fr"
        }  
    

    インデックスのクエリを実行できるのは一度に1つだけです。 一度に 1 つをクエリするのでない限り、言語ごとに複数のインデックスを作成しないでください。

  7. ページング-項目の最初のページを取得します (ページサイズは 10)。

    GET /indexes/hotels/docs?search=*&$skip=0&$top=10&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "*",  
          "skip": 0,  
          "top": 10  
        }  
    
  8. ページング-項目の2番目のページを取得します (ページサイズは 10)。

    GET /indexes/hotels/docs?search=*&$skip=10&$top=10&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "*",  
          "skip": 10,  
          "top": 10  
        }  
    
  9. 特定のフィールドのセットを取得します。

    GET /indexes/hotels/docs?search=*&$select=HotelName,Description&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "*",  
          "select": "HotelName, Description"
        }  
    
  10. 特定のフィルター式に一致するドキュメントを取得します。

    GET /indexes/hotels/docs?$filter=(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "filter": "(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'"  
        }  
    
  11. インデックスを検索し、ヒット ハイライトでフラグメントを返します。

    GET /indexes/hotels/docs?search=something&highlight=Description&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "something",  
          "highlight": "Description"  
        }  
    
  12. インデックスを検索し、参照場所に近いものから順番に並べられたドキュメントを返します。

    GET /indexes/hotels/docs?search=something&$orderby=geo.distance(Location, geography'POINT(-122.12315 47.88121)')&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "something",  
          "orderby": "geo.distance(Location, geography'POINT(-122.12315 47.88121)')"
        }  
    
  13. 2 つの distance スコア付け関数 (1 つは "currentLocation" というパラメーターを定義し、もう 1 つは "lastLocation" というパラメーターを定義している) を使用した "geo" と呼ばれるスコア付けプロファイルがあると仮定して、インデックを検索します。

    GET /indexes/hotels/docs?search=something&scoringProfile=geo&scoringParameter=currentLocation--122.123,44.77233&scoringParameter=lastLocation--121.499,44.2113&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "something",  
          "scoringProfile": "geo",  
          "scoringParameters": [ "currentLocation--122.123,44.77233", "lastLocation--121.499,44.2113" ]  
        }  
    
  14. 簡単なクエリ構文を使用して、インデックス内のドキュメントを検索します。 このクエリは、検索可能なフィールドに語句 "comfort" および "location" が含まれていて "motel" が含まれないホテルを返します。

    Get /indexes/hotels/docs?search=comfort +location –motel&searchMode=all&api-version=22020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "comfort +location -motel",  
          "searchMode": "all"  
        }  
    

    ヒント

    searchMode=all を使用すると、既定の searchMode=any がオーバーライドされ、-motel が「OR NOT」ではなく「AND NOT」を意味します。 searchMode=allを指定しないと、検索結果を制限するのではなく拡大する "OR NOT" になり、一部のユーザーにとっては直感に反している可能性があります。

  15. Lucene クエリ構文 を使用して、 インデックス内のドキュメントを検索します。 このクエリは、カテゴリ フィールドに "budget" (低料金) が含まれ、すべての検索可能なフィールドに "recently renovated" (最近改修済み) というフレーズが含まれるホテルを返します。 "recently renovated" というフレーズを含むドキュメントは、用語のブースト値 (3) の結果、高いランクになります。

    GET /indexes/hotels/docs?search=Category:budget AND \"recently renovated\"^3&searchMode=all&api-version=2020-06-30&querytype=full` 
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
         "search": "Category:budget AND \"recently renovated\"^3",  
          "queryType": "full",  
          "searchMode": "all"  
    }  
    
  16. インデックス内のドキュメントを検索し、待機時間を短くして一貫したスコアリングを行います。 このクエリでは、インデックス全体のドキュメントの頻度を計算し、同じ "セッション" 内のすべてのクエリに対して同じレプリカをターゲットにするための最善の努力を行います。これは、安定した再現可能なランク付けを生成するのに役立ちます。

    GET /indexes/hotels/docs?search=hotel&sessionId=mySessionId&scoringStatistics=global&api-version=2020-06-30
    
    POST /indexes/hotels/docs/search?api-version=2020-06-30
        {  
          "search": "hotel",  
          "sessionId": "mySessionId",
          "scoringStatistics" :"global"
        }  
    

関連項目