Sök efter dokument (Azure Cognitive Search REST API)

Artikel
08/24/2021
18 minuter för att läsa

En frågebegäran riktar sig till dokumentsamlingen för ett enda index i en söktjänst. Den innehåller parametrar som definierar matchningskriterierna och parametrar som formar svaret.

Du kan använda GET eller POST. Frågeparametrar anges i frågesträngen för GET-begäranden och i begärandetexten för POST-begäranden.

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]

När den anropas med GET får längden på begärande-URL:en inte överskrida 8 kB. Den här längden räcker vanligtvis för de flesta program. Vissa program producerar dock mycket stora frågor, särskilt när OData-filteruttryck används. För dessa program är HTTP POST ett bättre alternativ eftersom det tillåter större filter än GET.

Med POST är antalet satser i ett filter den begränsande faktorn, inte storleken på råfiltersträngen eftersom storleksgränsen för begäran för POST är cirka 16 MB. Även om storleksgränsen för POST-begäran är mycket stor kan filteruttryck inte vara godtyckligt komplexa. Mer information om begränsningar för filterkomplexitet finns i OData-uttryckssyntax för Azure Cognitive Search.

URI-parametrar

Parameter	Beskrivning
[tjänstnamn]	Krävs. Ange det unika, användardefinierade namnet för söktjänsten.
[indexnamn]/dokument	Krävs. Anger dokumentsamlingen för ett namngivet index.
[frågeparametrar]	Frågeparametrar anges i URI:en för GET-begäranden och i begärandetexten för POST-begäranden.
api-version	Krävs. Den aktuella stabila versionen är `api-version=2020-06-30` . Se API-versioner för fler versioner. För frågor anges api-versionen alltid som en URI-parameter för både GET och POST.

Rekommendationer för URL-kodning

Kom ihåg att URL-koda specifika frågeparametrar när du anropar GET-REST API direkt. För en sökdokumentåtgärd kan URL-kodning vara nödvändig för följande frågeparametrar:

sök
$filter
Aspekt
highlightPreTag
highlightPostTag

URL-kodning rekommenderas endast för enskilda parametrar. Om du oavsiktligt URL-kodar hela frågesträngen (allt efter ? ), kommer begäranden att brytas.

URL-kodning krävs bara när du anropar REST API direkt med get. Ingen URL-kodning krävs när du använder POST, eller när du använder Azure Cognitive Search .NET-klientbiblioteket, som hanterar kodning åt dig.

Rubriker för begäran

I följande tabell beskrivs de obligatoriska och valfria begärandehuvudena.

Fält	Beskrivning
Content-Type	Krävs. Ställ in det här på "application/json"
API-nyckel	Krävs. En unik systemgenererad sträng som autentiserar begäran till din söktjänst. Frågebegäranden mot dokumentsamlingen kan ange antingen en administratörsnyckel eller en frågenyckel som API-nyckel. Frågenyckeln används för skrivskyddade åtgärder mot dokumentsamlingen. Du hittar API-nyckeln på instrumentpanelen för söktjänsten i Azure Portal.

Begärandetext

För GET: Ingen.

För 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": #  
   }

Fortsättning på partiella söksvar

Ibland Azure Cognitive Search inte returnera alla begärda resultat i ett enda Sök-svar. Detta kan inträffa av olika orsaker, till exempel när frågan begär för många dokument genom att inte ange $top eller ange ett värde för $top som är för stort. I sådana fall Azure Cognitive Search inkluderas anteckningen i svarstexten och även @odata.nextLink om det var en @search.nextPageParameters POST-begäran. Du kan använda värdena för dessa anteckningar för att formulera en annan Sök-begäran för att hämta nästa del av söksvaret. Detta kallas en fortsättning på den ursprungliga sökbegäran, och anteckningarna kallas vanligtvis fortsättningstoken. Se exemplet i Svar nedan för information om syntaxen för dessa anteckningar och var de visas i svarstexten.

Orsakerna till Azure Cognitive Search kan returnera fortsättningstoken är implementeringsspecifika och kan komma att ändras. Robusta klienter bör alltid vara redo att hantera fall där färre dokument än förväntat returneras och en fortsättningstoken ingår för att fortsätta att hämta dokument. Observera också att du måste använda samma HTTP-metod som den ursprungliga begäran för att kunna fortsätta. Om du till exempel har skickat en GET-begäran måste alla fortsättningsbegäranden som du skickar också använda GET (och på samma sätt för POST).

Anteckning

Syftet med och är att skydda tjänsten från frågor som begär för många resultat, inte att tillhandahålla @odata.nextLink en allmän mekanism för @search.nextPageParameters växling. Om du vill bläddra igenom resultaten använder du $top och $skip tillsammans. Om du till exempel vill ha sidor med storleken 10 bör din första begäran ha $top=10 och $skip=0. Den andra begäran ska ha $top =1' och $skip=10. Den tredje begäran ska ha $top=10 och $skip=20 och så vidare.

Frågeparametrar

En fråga accepterar flera parametrar på URL:en när den anropas med GET och som JSON-egenskaper i begärandetexten när den anropas med POST. Syntaxen för vissa parametrar skiljer sig något mellan GET och POST. Dessa skillnader anges enligt vad som är tillämpligt nedan.

Namn	Typ	Beskrivning
api-version	sträng	Krävs. Versionen av REST API används för begäran. En lista över versioner som stöds finns i API-versioner. För den här åtgärden anges API-versionen som en URI-parameter oavsett om du anropar Sökdokument med GET eller POST.
$count	boolean	Valfritt. Giltiga värden är "true" eller "false". Standardvärdet är "false". När den anropas med POST heter den här parametern count i stället för $count. Anger om det totala antalet resultat ska hämtas. Det här är antalet dokument som matchar sök- och $filter parametrarna, och ignorerar $top och $skip. Om det här värdet är "true" kan prestanda försämras. Det returnerade antalet är en uppskattning. Om du bara vill hämta antalet utan dokument kan du använda $top=0.
Aspekt	sträng	Valfritt. Ett fält som ska fasettas av. Strängen kan innehålla parametrar för att anpassa fasningen, uttryckt som kommaavgränsade namn/värde-par. När den anropas med POST heter den här parametern fasetter i stället för fasett. Giltiga är "count", "sort", "values", "interval" och "timeoffset". "count" är det maximala antalet fasettvillkor; standardvärdet är 10. Det finns ingen övre gräns för antalet termer, men högre värden försämrar prestandan, särskilt om det fasetterade fältet innehåller ett stort antal unika termer. Till exempel hämtar "facet=category,count:5" de fem översta kategorierna i fasettresultat. Om count-parametern är mindre än antalet unika termer kanske resultatet inte är korrekt. Det beror på hur fas fas fasningen av frågor fördelas mellan shards. Att öka antalet ökar vanligtvis precisionen för termantal, men till en prestandakostnad. "sort" kan anges till "count", "-count", "value", "-value". Använd antal för att sortera fallande efter antal. Använd -count för att sortera stigande efter antal. Använd värdet för att sortera stigande efter värde. Använd -value för att sortera fallande efter värde (till exempel "facet=category,count:3,sort:count" hämtar de tre främsta kategorierna i fasettresultat i fallande ordning efter antalet dokument med varje ortnamn). Om de tre översta kategorierna är Budget, Hotel och Luxury, och Budget har 5 träffar, Har Hits 6 och Lyx har 4, kommer bucketarna att finnas i ordern Budget, Budget, Lyx. För -value skapar "facet=rating,sort:-value" buckets för alla möjliga klassificeringar, i fallande ordning efter värde (om omdömena till exempel är från 1 till 5 sorteras bucketarna 5, 4, 3, 2, 1, oavsett hur många dokument som matchar varje klassificering). "values" kan ställas in på pipe-avgränsade numeriska värden eller Edm.DateTimeOffset-värden som anger en dynamisk uppsättning fasettinmatningsvärden (till exempel "facet=baseRate,values:10 20" ger tre buckets: en för bashastigheten 0 upp till men inte 10, en för 10 upp till men inte 20 och en för \| 20 och högre). Strängen "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" skapar två buckets: en för hotell före februari 2010 och en för hotell som börjar 1 februari 2010 eller senare. "interval" är ett heltalsintervall som är större än 0 för tal, eller minut, timme, dag, vecka, månad, kvartal, år för datum/tid-värden. Till exempel skapar "facet=baseRate,interval:100" buckets baserat på bashastighetsintervall med storleken 100. Om baspriserna är mellan 60 och 600 USD kommer det att finnas bucketar för 0-100, 100-200, 200-300, 300-400, 400-500 och 500-600. Strängen "facet=lastRenovationDate,interval:year" genererar en bucket för varje år när hotellen var billigare. "timeoffset" kan anges till ([+-]hh:mm, [+-]hhmm eller [+-]hh). Om den används måste timeoffset-parametern kombineras med intervallalternativet och endast när den tillämpas på ett fält av typen Edm.DateTimeOffset. Värdet anger den UTC-tidsförskjutning som ska tas med i beräkningen vid inställningen av tidsgränser. Exempel: "facet=lastRenovationDate,interval:day,timeoffset:-01:00" använder daggränsen som börjar vid 01:00:00 UTC (midnatt i måltidszonen). count och sort kan kombineras i samma fasettspecifikation, men de kan inte kombineras med intervall eller värden, och intervall och värden kan inte kombineras tillsammans. Intervall fasetter för datum/tid beräknas baserat på UTC-tid om timeoffset inte har angetts. Exempel: för "facet=lastRenovationDate,interval:day" börjar daggränsen vid 00:00:00 UTC.
$filter	sträng	Valfritt. Ett strukturerat sökuttryck i OData-standardsyntax. Endast filtrerbara fält kan användas i ett filter. När du anropar med POST namnges den här parametern filter i stället för $filter. Se OData-uttryckssyntax Azure Cognitive Search mer information om delmängden av OData-uttryckets grammatik som Azure Cognitive Search stöder.
Markera	sträng	Valfritt. En uppsättning kommaavgränsade fältnamn som används för träffhöjdpunkter. Endast sökbara fält kan användas för träffmarkering. Som standard Azure Cognitive Search upp till 5 markeringar per fält. Gränsen kan konfigureras per fält genom att "-" efter fältnamnet. Till exempel returnerar "highlight=title-3,description-10" upp till 3 markerade träffar från rubrikfältet och upp till 10 träffar från beskrivningsfältet. Det maximala antalet markeringar måste vara ett heltal mellan 1 och 1 000.
highlightPostTag	sträng	Valfritt. Standardvärdet är `"</em>"` . En strängtagg som läggs till i den markerade termen.. Måste anges med highlightPreTag. Reserverade tecken i URL måste vara procentkodade (till exempel %23 i stället för #).
highlightPreTag	sträng	Valfritt. Standardvärdet är `"</em>"` . En strängtagg som förbereder den markerade termen. Måste anges med highlightPostTag. Reserverade tecken i URL måste vara procentkodade (till exempel %23 i stället för #).
minimumCoverage	heltal	Valfritt. Giltiga värden är ett tal mellan 0 och 100 som anger procentandelen av indexet som måste vara tillgängligt för att sera frågan innan den kan rapporteras som lyckad. Standardvärdet är "100". En hundra procents täckning innebär att alla shards besvarade begäran (varken problem med tjänstens hälsotillstånd eller underhållsaktiviteter minskade täckningen). Under standardinställningen returnerar mindre än fullständig täckning HTTP-statuskod 503. Att sänka minimumCoverage kan vara användbart om 503 fel inträffar och du vill öka sannolikheten för att frågan lyckas, särskilt för tjänster som har konfigurerats för en replik. Om du anger minimumCoverage och Sökningen lyckas returnerar den HTTP 200 och inkluderar ett värde i svaret som anger procentandelen av indexet som inkluderades @search.coverage i frågan. I det här scenariot är det inte säkert att alla matchande dokument finns i sökresultaten, men om söktillgänglighet är viktigare än återkallning kan en minskning av täckningen vara en genomförbar minskningsstrategi.
$orderby	sträng	Valfritt. En lista med kommaavgränsade uttryck som resultatet ska sorteras efter. När den anropas med POST får den här parametern namnet orderby i stället för $orderby. Varje uttryck kan vara antingen ett fältnamn eller ett anrop till funktionen geo.distance(). Varje uttryck kan följas av "asc" för att ange stigande och "desc" för att indikera fallande. Om det finns nullvärden i sorteringsfältet visas nullvärden först i stigande ordning och sist i fallande ordning. Standardvärdet är stigande ordning. Oavgjort bryts av matchningspoängen för dokument. Om ingen $orderby har angetts är standardordningen fallande efter dokumentmatchningspoäng. Det finns en gräns på 32 satser för $orderby.
queryType	sträng	Valfritt. Giltiga värden är "enkla" eller "fullständiga". Standardvärdet är "simple". "simple" tolkar frågesträngar med hjälp av den enkla frågesyntax som tillåter symboler som `+` och `*` `""` . Frågor utvärderas som standard i alla sökbara fält (eller fält som anges i searchFields) i varje dokument. "full" tolkar frågesträngar med hjälp av den fullständiga Lucene-frågesyntaxen som tillåter fältspecifika och viktade sökningar. Intervallsökning i Lucene-frågespråket stöds inte till förmån för $filter som erbjuder liknande funktioner.
scoringParameter	sträng	Valfritt. Anger värdena för varje parameter som definierats i en bedömningsfunktion (till exempel referencePointParameter) med formatet "name-value1,value2,..." När den anropas med POST heter den här parametern scoringParameters i stället för scoringParameter. Dessutom anger du den som en JSON-matris med strängar där varje sträng är ett separat namn-värdepar. För bedömningsprofiler som innehåller en funktion avgränsar du funktionen från dess indatalista med ett `-` tecken. En funktion med namnet skulle `"mylocation"` till exempel vara "&scoringParameter=mylocation--122.2,44.8". Det första bindestrecket separerar funktionsnamnet från värdelistan, medan det andra bindestrecket är en del av det första värdet (longitud i det här exemplet). För bedömningsparametrar, till exempel för taggförstärering som kan innehålla kommatecken, kan du undvika sådana värden i listan med enkla citattecken. Om själva värdena innehåller enkla citattecken kan du undvika dem genom att dubbla. Anta att du har en taggförstärkningsparameter som heter och du vill öka taggvärdena "Hello, O'Brien" och "Smith". Frågesträngsalternativet skulle då vara `"mytag"` "&scoringParameter=mytag-'Hello, O''Brien',Smith". Citattecken krävs bara för värden som innehåller kommatecken.
scoringProfile	sträng	Valfritt. Namnet på en bedömningsprofil för att utvärdera matchningspoäng för matchande dokument för att sortera resultaten.
scoringStatistics	sträng	Valfritt. Giltiga värden är "lokala" eller "globala". Standardvärdet är "local". Ange om bedömningsstatistik ska beräknas, till exempel dokumentfrekvens, globalt (över alla shards) för mer konsekvent bedömning eller lokalt (på den aktuella sharden) för kortare svarstider. Se Bedömningsstatistik i Azure Cognitive Search. Bedömningsstatistik beräknas alltid lokalt för termer som använder fuzzy-sökning (~).
sök	sträng	Valfritt. Texten som ska sökas efter. Alla sökbara fält genomsöks som standard om inte searchFields har angetts. I indexet tokeniseras text i ett sökbart fält, så flera termer kan avgränsas med blanksteg (till exempel: 'search=hello world'). Om du vill matcha en term använder `` du (detta kan vara användbart för booleska filterfrågor). Om du utesluter den här parametern får du samma effekt som när du anger den till `` . Mer information om söksyntaxen finns i Enkel frågesyntax. Resultaten kan ibland vara överraskande när du frågar över sökbara fält. Tokeniseraren innehåller logik för att hantera fall som är vanliga för engelsk text som apostrofer, kommatecken i siffror och så vidare. Till exempel matchar 'search=123,456' en enda term '123,456' i stället för de enskilda termerna '123' och '456', eftersom kommatecken används som tusentalsavgränsare för stora tal på engelska. Därför rekommenderar vi att du använder tomt utrymme i stället för skiljetecken för att avgränsa termer i sökparametern.
searchMode	sträng	Valfritt. Giltiga värden är "any" (alla) eller "all" (alla) som standard "any". Anger om några eller alla söktermer måste matchas för att räkna dokumentet som en matchning.
searchFields	sträng	Valfritt. Listan med kommaavgränsade fältnamn för att söka efter den angivna texten. Målfält måste markeras som sökbara i indexschemat.
$select	sträng	Valfritt. En lista med kommaavgränsade fält som ska ingå i resultatuppsättningen. Endast fält som markerats som hämtningsbara kan ingå i den här satsen. Om du inte anger eller anger till `*` tas alla fält som markerats som hämtningsbara i schemat med i projektionen. När den anropas med POST heter den här parametern select i stället för $select.
Sessionid	sträng	Valfritt. Med sessionId kan du förbättra konsekvensen för relevanspoäng för söktjänster med flera repliker. I konfigurationer med flera repliker kan det finnas små skillnader mellan relevanspoängen för enskilda dokument för samma fråga. När ett sessions-ID anges gör tjänsten bästa möjliga försök att dirigera en viss begäran till samma replik för den sessionen. Var försiktig så att återanvändning av samma sessions-ID-värden upprepade gånger kan störa belastningsutjämningen av begäranden mellan repliker och påverka söktjänstens prestanda negativt. Värdet som används som sessionId kan inte börja med ett _-tecken. Om en tjänst inte har några repliker har den här parametern ingen effekt på prestanda- eller poängkonsekvens.
$skip	heltal	Valfritt. Antalet sökresultat som ska hoppas över. När den anropas med POST heter den här parametern skip i stället för $skip. Det här värdet får inte vara större än 100 000. Om du behöver genomsöka dokument i följd, men inte kan använda $skip på grund av den här begränsningen, kan du överväga att använda $orderby i ett fält som har unika värden för varje dokument i indexet (till exempel dokumentnyckeln) och $filter med en intervallfråga i stället.
$top	heltal	Valfritt. Antalet sökresultat som ska hämtas. Standardvärdet är 50. När den anropas med POST namnges den här parametern överst i stället för $top. Om du anger ett värde som är större än 1 000 och det finns fler än 1 000 resultat returneras bara de första 1 000 resultaten, tillsammans med en länk till nästa sida med resultat (se i @odata.nextLink exemplet nedan). Azure Cognitive Search använder sidinnumrering på serversidan för att förhindra att frågor hämtar för många dokument samtidigt. Standardstorleken för sidan är 50, medan den maximala sidstorleken är 1 000. Det innebär att som standard returnerar Sök dokument högst 50 resultat om du inte anger $top. Om det finns fler än 50 resultat innehåller svaret information för att hämta nästa sida med högst 50 resultat (se " " och @odata.nextLink @search.nextPageParameters " " i exemplen nedan. Om du anger ett värde större än 1 000 för $top och det finns fler än 1 000 resultat returneras bara de första 1 000 resultaten, tillsammans med information för att hämta nästa sida med högst 1 000 resultat.

Svarsåtgärder

Statuskod: 200 OK returneras för ett lyckat svar.

  {
    "@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)
  }

Exempel

Ytterligare exempel finns i OData-uttryckssyntax för Azure Cognitive Search.

Sök i Index sorterad fallande efter datum:

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"
    }

I en fasetterad sökning söker du i indexet och hämtar fasetter efter kategorier, klassificeringar, taggar samt objekt med baseRate i specifika intervall.
```
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" ]  
    }  
```
Observera att den sista fasetten finns i ett underfält. Fasetter räknar det överordnade dokumentet (Hotels) och inte mellanliggande underdokument (Rum), så svaret avgör antalet hotell som har några rum i varje pris bucket.

Med hjälp av ett filter begränsar du det tidigare fasetterade frågeresultatet när användaren har valt Klassificering 3 och kategorin "Hotel".

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'"  
    }

I en fasetterad sökning anger du en övre gräns för unika termer som returneras i en fråga. Standardvärdet är 10, men du kan öka eller minska det här värdet med hjälp av count-parametern i facet-attributet. Det här exemplet returnerar fasetter för stad, begränsat till 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" ]  
    }  
```

Sök indexet inom specifika fält (till exempel ett språkfält):

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"
    }

Sök i Index över flera fält. Du kan till exempel lagra och fråga sökbara fält på flera språk, allt inom samma index. Om engelska och franska beskrivningar finns i samma dokument kan du returnera alla eller alla i frågeresultatet:
```
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"
    }  
```
Du kan bara köra frågor mot index i taget. Skapa inte flera index för varje språk om du inte planerar att fråga ett i taget.

Växling – Hämta den första sidan med objekt (sidstorleken är 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  
    }

Växling – Hämta den andra sidan med objekt (sidstorleken är 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  
    }

Hämta en specifik uppsättning fält:

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"
    }

Hämta dokument som matchar ett specifikt filteruttryck:

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'"  
    }

Sök i indexet och returnera fragment med träffpunkter:

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"  
    }

Sök i indexet och returnera dokument som sorterats från närmre till längre bort från en referensplats:

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)')"
    }

Sök i indexet förutsatt att det finns en bedömningsprofil med namnet "geo" med två avståndsbedömningsfunktioner, en som definierar en parameter med namnet "currentLocation" och en som definierar en parameter med namnet "lastLocation":

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" ]  
    }

Hitta dokument i indexet med hjälp av enkel frågesyntax. Den här frågan returnerar hotell där sökbara fält innehåller termerna "bekvämlighet" och "plats" men inte "hotels":
```
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"  
    }  
```
Tips

Användningen av searchMode=all åsidosätter standardvärdet , vilket searchMode=any säkerställer att -motel innebär "AND NOT" i stället för "OR NOT". Utan får du "OR NOT" som expanderar i stället för att begränsa sökresultat, och det kan vara searchMode=all kontra intuitivt för vissa användare.

Hitta dokument i indexet med Lucene-frågesyntaxen). Den här frågan returnerar hotell där kategorifältet innehåller termen "budget" och alla sökbara fält som innehåller frasen "nyligen uppsökt". Dokument som innehåller frasen "nyligen uppsnad" rangordnas högre på grund av termen boost-värde (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"  
}

Hitta dokument i indexet och prioritera konsekvent bedömning framför kortare svarstider. Den här frågan beräknar dokumentfrekvenser över hela indexet och gör ett bästa för att rikta in sig på samma replik för alla frågor inom samma "session", vilket hjälper till att generera stabil och reproducerbar rangordning.
```
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"
    }  
```