Buscar documentos (Azure Cognitive Buscar API de REST)

Una solicitud de consulta tiene como destino la colección de documentos de un único índice en un servicio de búsqueda. Incluye parámetros que definen los criterios de coincidencia y los parámetros que dan forma a la respuesta. A partir de la versión de la API 2021-04-30-Preview, también puede usar un alias de índice para tener como destino un índice determinado en lugar de usar el propio nombre del índice.

Puede usar GET o POST. Los parámetros de consulta se especifican en la cadena de consulta en el caso de las solicitudes GET y en el cuerpo de la solicitud en el caso de las solicitudes POST.

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

Si usa POST, agregue la acción "search" como parámetro URI.

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]  

Cuando se llama a con GET, la longitud de la dirección URL de la solicitud no puede superar los 8 KB. Esta longitud suele ser suficiente para la mayoría de las aplicaciones. Sin embargo, algunas aplicaciones producen consultas muy grandes, específicamente cuando se usan expresiones de filtro OData. Para estas aplicaciones, HTTP POST es una mejor opción porque permite filtros más grandes que GET.

Con POST, el número de cláusulas en un filtro es el factor limitador, no el tamaño de la cadena del filtro, ya que el límite de tamaño de la solicitud POST es de 16 MB aproximadamente. Aunque el límite de tamaño de la solicitud POST es muy grande, las expresiones de filtro no pueden ser arbitrariamente complejas. Para obtener más información sobre las limitaciones de complejidad del filtro, vea Sintaxis de expresiones de OData para Azure Cognitive Search.

Parámetros de identificador URI

Parámetro Descripción
[nombre del servicio] Necesario. Establézcalo en el nombre único definido por el usuario del servicio de búsqueda.
[nombre de índice]/docs Necesario. Especifica la colección de documentos de un índice con nombre.
[parámetros de consulta] Los parámetros de consulta se especifican en el URI de las solicitudes GET y en el cuerpo de la solicitud para las solicitudes POST.
api-version Necesario. La versión estable actual es api-version=2020-06-30. Consulte Versiones de API para obtener más versiones. En el caso de las consultas, la versión de api siempre se especifica como un parámetro URI para GET y POST.

Recomendaciones de codificación de direcciones URL

Recuerde codificar la dirección URL parámetros de consulta específicos al llamar directamente a la API REST GET. En el caso de una operación de búsqueda de documentos , la codificación de direcciones URL podría ser necesaria para los siguientes parámetros de consulta:

  • paquetes Bower
  • $filter
  • facet
  • highlightPreTag
  • highlightPostTag

La codificación de direcciones URL solo se recomienda para parámetros individuales. Si por accidente codifica como URL la cadena de consulta completa (todo lo que hay después de ?), se interrumpirán las solicitudes.

Además, la codificación con URL solo es necesaria cuando se llama directamente a la API de REST directamente con GET. No es necesario codificar direcciones URL al usar POST o al usar la biblioteca cliente de .NET Azure Cognitive Search, que controla la codificación por usted.

Encabezados de solicitud

En la siguiente tabla se describen los encabezados de solicitud obligatorios y opcionales.

Campos Descripción
Content-Type Necesario. Establézcalo en "application/json"
api-key Necesario. Cadena única generada por el sistema que autentica la solicitud en el servicio de búsqueda. Las solicitudes de consulta en la colección de documentos pueden especificar una clave de administrador o una clave de consulta como clave de API. La clave de consulta se usa para las operaciones de solo lectura en la colección de documentos. Puede encontrar la clave de API en el panel del servicio de búsqueda en el Azure Portal.

Cuerpo de la solicitud

Para GET: ninguno.

Para 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": #  
   }  

Continuación de las respuestas de búsqueda parciales

A veces, Azure Cognitive Search no pueden devolver todos los resultados solicitados en una única respuesta de búsqueda. Esto puede ocurrir por diferentes motivos, como cuando la consulta solicita demasiados documentos no especificando $top ni especificando un valor para $top demasiado grande. En tales casos, Azure Cognitive Search incluirá la @odata.nextLink anotación en el cuerpo de la respuesta y también @search.nextPageParameters si se trata de una solicitud POST. Puede usar los valores de estas anotaciones para formular otra solicitud de Search a fin de obtener la siguiente parte de la respuesta de búsqueda. Esto se denomina continuación de la solicitud de búsqueda original, y las anotaciones se suelen llamar tokens de continuación. Consulte el ejemplo de Respuesta a continuación para obtener más información sobre la sintaxis de estas anotaciones y dónde aparecen en el cuerpo de la respuesta.

Los motivos por los que Azure Cognitive Search podrían devolver tokens de continuación son específicos de la implementación y están sujetos a cambios. Los clientes sólidos deben estar siempre preparados para controlar los casos en que se devuelven menos documentos de lo esperado y se incluye un token de continuación para seguir recuperando documentos. Tenga en cuenta también que debe usar el mismo método HTTP como solicitud original para poder continuar. Por ejemplo, si envía una solicitud GET, las solicitudes de continuación que envíe también deben utilizar GET (y lo mismo para POST).

Nota:

El propósito de @odata.nextLink y @search.nextPageParameters es proteger el servicio de las consultas que solicitan demasiados resultados, no proporcionar un mecanismo general para la paginación. Si desea paginar los resultados, use $top y $skip juntos. Por ejemplo, si desea páginas de tamaño 10, la primera solicitud debe tener $top=10 y $skip=0, la segunda solicitud debe tener $top=1' y $skip=10, la tercera solicitud debe tener $top=10 y $skip=20, etc.

Parámetros de consulta

Una consulta acepta varios parámetros en la dirección URL cuando se llama con GET y como propiedades JSON en el cuerpo de la solicitud cuando se llama con POST. La sintaxis de algunos parámetros es algo diferente entre GET y POST. Estas diferencias se indican según corresponda a continuación.

Nombre Tipo Descripción
api-version string Necesario. Versión de la API REST usada para la solicitud. Para obtener una lista de las versiones admitidas, consulte Versiones de API. Para esta operación, la versión de api se especifica como un parámetro de URI independientemente de si llama a Buscar documentos con GET o POST.
$count boolean Opcional. Los valores válidos son "true" o "false". El valor predeterminado es "false". Cuando se llama con POST, este parámetro se denomina count en lugar de $count. Especifica si capturar el número total de resultados. Este es el recuento de todos los documentos que coinciden con los parámetros de búsqueda y $filter, ignorando $top y $skip. Establecer este valor en "true" puede degradar el rendimiento. El recuento devuelto es una aproximación. Si desea obtener solo el recuento sin ningún documento, puede usar $top=0.
facet string Opcional. Campo por el que se va a facetar. La cadena puede contener parámetros para personalizar la faceta, expresada como pares de nombre-valor separados por comas. Cuando se llama con POST, este parámetro se denomina facetas en lugar de faceta.

Válidos son "count", "sort", "values", "interval" y "timeoffset".

"count" es el número máximo de términos de faceta; el valor predeterminado es 10. No hay ningún límite superior en el número de términos, pero los valores más altos degradarán el rendimiento, especialmente si el campo con facetas contiene un gran número de términos únicos. Por ejemplo, "facet=category,count:5" obtiene las cinco categorías principales en los resultados de faceta. Si el parámetro count es menor que el número de términos únicos, es posible que los resultados no sean precisos. Esto es debido a la manera en que se distribuyen las consultas de facetas entre las particiones. El aumento del recuento generalmente aumenta la precisión de los recuentos de términos, pero a un costo de rendimiento.

"sort" se puede establecer en "count", "-count", "value", "-value". Use count para ordenar de forma descendente por recuento. Use -count para ordenar de forma ascendente por recuento. Use el valor para ordenar de forma ascendente por valor. Use -value para ordenar de forma descendente por valor (por ejemplo, "facet=category,count:3,sort:count" obtiene las tres categorías principales en los resultados de faceta en orden descendente por el número de documentos con cada nombre de ciudad). Si las tres categorías principales son Presupuesto, Motel y Lujo, y Presupuesto tiene 5 resultados, Motel tiene 6 y Lujo tiene 4, los cubos se ordenarán como Motel, Presupuesto, Lujo. Para -value, "facet=rating,sort:-value" genera depósitos para todas las clasificaciones posibles, en orden descendente por valor (por ejemplo, si las clasificaciones van de 1 a 5, los cubos se ordenarán 5, 4, 3, 2, 1, independientemente del número de documentos que coincidan con cada clasificación).

"values" se puede establecer en valores numéricos delimitados por canalización o Edm.DateTimeOffset que especifican un conjunto dinámico de valores de entrada de faceta (por ejemplo, "facet=baseRate,values:10 | 20" produce tres cubos: uno para la velocidad base 0 hasta pero no incluye 10, uno para 10 hasta , pero no incluye 20, y otro para 20 y superior). Una cadena "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" genera dos cubos: uno para hoteles renovados antes de febrero de 2010 y otro para hoteles renovados el 1 de febrero de 2010 o posterior. Los valores deben aparecer en orden secuencial y ascendente para obtener los resultados esperados.

"interval" es un intervalo entero mayor que 0 para números, o minuto, hora, día, semana, mes, trimestre, año para los valores de fecha y hora. Por ejemplo, "facet=baseRate,interval:100" genera cubos basados en intervalos de velocidad base de tamaño 100. Si las tarifas base están entre $60 y $600, habrá depósitos para 0-100, 100-200, 200-300, 300-400, 400-500 y 500-600. La cadena "facet=lastRenovationDate,interval:year" genera un cubo para cada año cuando se renovaron los hoteles.

"timeoffset" se puede establecer en ([+-]hh:mm, [+-]hhmm o [+-]hh). Si se usa, el parámetro timeoffset debe combinarse con la opción interval y solo cuando se aplica a un campo de tipo Edm.DateTimeOffset. El valor especifica la diferencia horaria UTC para explicar la configuración de los límites de tiempo. Por ejemplo: "facet=lastRenovationDate,interval:day,timeoffset:-01:00" usa el límite del día que comienza a las 01:00:00 UTC (medianoche en la zona horaria de destino).

count y sort se pueden combinar en la misma especificación de faceta, pero no se pueden combinar con el intervalo o los valores, y el intervalo y los valores no se pueden combinar.

Las facetas interval en fecha y hora se calculan en función de la hora UTC si no se especifica timeoffset. Por ejemplo: para "facet=lastRenovationDate,interval:day", el límite del día comienza a las 00:00:00 UTC.
$filter string Opcional. Una expresión de búsqueda estructurada en sintaxis OData estándar. Solo se pueden usar campos filtrables en un filtro. Al llamar a con POST, este parámetro se denomina filtro en lugar de $filter. Consulte Sintaxis de expresión de OData para obtener Azure Cognitive Search para obtener más información sobre el subconjunto de la gramática de expresiones de OData que Azure Cognitive Search admite.
highlight string Opcional. Un conjunto de nombres de campo separados por coma usados resultados destacados. Solo se pueden usar campos que se pueden buscar para el resaltado de aciertos. De forma predeterminada, Azure Cognitive Search devuelve hasta 5 resaltados por campo. El límite se puede configurar por campo anexando "-<max # of highlights>" después del nombre del campo. Por ejemplo, "highlight=title-3,description-10" devuelve hasta 3 visitas resaltadas del campo de título y hasta 10 visitas del campo de descripción. El número máximo de resaltados debe ser un entero entre 1 y 1000 inclusive.
highlightPostTag string Opcional. Tiene como valor predeterminado "</em>". Etiqueta de cadena que se anexa al término resaltado. Debe establecerse con highlightPreTag. Los caracteres reservados en la dirección URL deben estar codificados con porcentaje (por ejemplo, %23 en vez de #).
highlightPreTag string Opcional. Tiene como valor predeterminado "</em>". Etiqueta de cadena que antepone al término resaltado. Debe establecerse con highlightPostTag. Los caracteres reservados en la dirección URL deben estar codificados con porcentaje (por ejemplo, %23 en vez de #).
minimumCoverage integer Opcional. Los valores válidos son un número comprendido entre 0 y 100, que indica el porcentaje del índice que debe estar disponible para atender la consulta antes de que se pueda notificar como correcto. El valor predeterminado es "100".

Una cobertura del cien por ciento significa que todas las particiones respondieron a la solicitud (ni los problemas de mantenimiento ni las actividades de mantenimiento reducen la cobertura). En la configuración predeterminada, menos de la cobertura completa devolverá el código de estado HTTP 503.

Reducir minimumCoverage puede ser útil si se producen errores 503 y desea aumentar la probabilidad de que la consulta se realice correctamente, especialmente para los servicios configurados para una réplica. Si establece minimumCoverage y Search se realiza correctamente, devolverá HTTP 200 e incluirá un @search.coverage valor en la respuesta que indica el porcentaje del índice que se incluyó en la consulta. En este escenario, no se garantiza que todos los documentos coincidentes estén presentes en los resultados de la búsqueda, pero si la disponibilidad de la búsqueda es más importante que la recuperación, la reducción de la cobertura puede ser una estrategia de mitigación viable.
$orderby string Opcional. Una lista de expresiones separadas por coma según la cual ordenar los resultados. Cuando se llama con POST, este parámetro se denomina orderby en lugar de $orderby. Cada expresión puede ser un nombre de campo o una llamada a la función geo.distance(). Cada expresión puede ir seguida de "asc" para indicar ascendente y "desc" para indicar descendente. Si hay valores NULL en el campo de ordenación, los valores NULL aparecen primero en orden ascendente y último en orden descendente. El valor predeterminado es ascendente. Los empates se resolverán por la puntuación de coincidencia de los documentos. Si no se especifica ningún $orderby, el criterio de ordenación predeterminado es descendente por puntuación de coincidencia de documento. Hay un límite de 32 cláusulas para $orderby.
queryType string Opcional. Los valores válidos son "simple" o "full". El valor predeterminado es "simple".

"simple" interpreta las cadenas de consulta mediante la sintaxis de consulta simple que permite símbolos como +, * y "". Las consultas se evalúan en todos los campos que se pueden buscar (o campos indicados en searchFields) en cada documento de forma predeterminada.

"full" interpreta las cadenas de consulta mediante la sintaxis de consulta completa de Lucene que permite búsquedas específicas y ponderadas de campo. No está admitido el intervalo de búsqueda en el lenguaje de consulta de Lucene, es preferible usar $filter que ofrece una funcionalidad similar.
scoringParameter string Opcional. Indica los valores de cada parámetro definido en una función de puntuación (como referencePointParameter) con el formato "name-value1,value2,..." Cuando se llama con POST, este parámetro se denomina scoringParameters en lugar de scoringParameter. Además, se especifica como una matriz JSON de cadenas donde cada cadena es un par de valores de nombre independientes.

Para los perfiles de puntuación que incluyen una función, separe la función de su lista de entrada con un - carácter. Por ejemplo, una función denominada "mylocation" sería "&scoringParameter=mylocation--122.2,44.8". El primer guión separa el nombre de la función de la lista de valores, mientras que el segundo guión forma parte del primer valor (longitud en este ejemplo).

Para los parámetros de puntuación, como para la potenciación de etiquetas que pueden contener comas, puede escapar cualquiera de estos valores en la lista mediante comillas simples. Si los propios valores contienen comillas simples, puede separarlos duplicando la comilla simple. Supongamos que tiene un parámetro de aumento de etiquetas denominado "mytag" y desea aumentar en los valores de etiqueta "Hello, O'Brien" y "Smith", la opción de cadena de consulta sería "&scoringParameter=mytag-'Hello, O'Brien',Smith". Las comillas solo son necesarias para los valores que contienen comas.
scoringProfile string Opcional. El nombre de un perfil de puntuación para evaluar puntuaciones de coincidencia para documentos coincidentes a fin de ordenar los resultados.
scoringStatistics string Opcional. Los valores válidos son "local" o "global". El valor predeterminado es "local". Especifique si se deben calcular estadísticas de puntuación, como la frecuencia del documento, globalmente (en todas las particiones) para obtener una puntuación más coherente o localmente (en la partición actual) para una menor latencia. Consulte Estadísticas de puntuación en Azure Cognitive Search. Las estadísticas de puntuación siempre se calcularán localmente para los términos que usan la búsqueda aproximada ("~") .
paquetes Bower string Opcional. Texto que se va a buscar. Todos los campos que se pueden buscar se buscan de forma predeterminada a menos que se especifique searchFields. En el índice, el texto de un campo en el que se puede buscar se tokeniza, por lo que se pueden separar varios términos por espacios en blanco (por ejemplo: "search=hello world"). Para encontrar un término, use * (esto puede ser útil para las consultas de filtro booleano). Omitir este parámetro tiene el mismo efecto que establecerlo en *. Para obtener información específica sobre la sintaxis de búsqueda, vea Sintaxis de consulta simple .

A veces, los resultados pueden ser sorprendentes al consultar los campos que se pueden buscar. El objeto Tokenizer incluye una lógica para controlar casos comunes a texto en inglés, como apóstrofo, comas en números, etc. Por ejemplo, 'search=123,456' coincidirá con un único término '123,456' en lugar de los términos individuales '123' y '456', ya que las comas se usan como separadores de miles para números grandes en inglés. Por este motivo, se recomienda usar espacios en blanco en lugar de signos de puntuación para separar los términos del parámetro de búsqueda.
searchMode string Opcional. Los valores válidos son "any" o "all" Defaults to "any". Especifica si alguno o todos los términos de búsqueda deben coincidir para considerar el documento como una coincidencia.
searchFields string Opcional. La lista de nombres de campo separados por coma donde buscar el texto especificado. Los campos de destino deben marcarse como buscables en el esquema de índice.
$select string Opcional. Lista de campos separados por comas que se van a incluir en el conjunto de resultados. Solo los campos marcados como recuperables se pueden incluir en esta cláusula. Si no se especifica nada o se establece en *, se incluirán en la proyección todos los campos marcados como recuperables en el esquema. Cuando se llama con POST, este parámetro se denomina select en lugar de $select.
sessionID string Opcional. El uso de sessionId ayuda a mejorar la coherencia de la puntuación de relevancia para los servicios de búsqueda con varias réplicas. En las configuraciones de varias réplicas, puede haber pequeñas diferencias entre las puntuaciones de relevancia de los documentos individuales para la misma consulta. Cuando se proporciona un identificador de sesión, el servicio realizará el mejor esfuerzo para enrutar una solicitud determinada a la misma réplica para esa sesión. Tenga cuidado de que reutilizar repetidamente los mismos valores de identificador de sesión puede interferir con el equilibrio de carga de las solicitudes entre réplicas y afectar negativamente al rendimiento del servicio de búsqueda. El valor utilizado como sessionId no puede empezar con el carácter "_". Si un servicio no tiene réplicas, este parámetro no tiene ningún efecto en el rendimiento o la coherencia de la puntuación.
$skip integer Opcional. El número de resultados de búsqueda que se van a omitir. Cuando se llama con POST, este parámetro se denomina skip en lugar de $skip. Este valor no puede ser mayor que 100 000. Si necesita examinar documentos en secuencia, pero no puede usar $skip debido a esta limitación, considere la posibilidad de usar $orderby en un campo que tenga valores únicos para cada documento del índice (por ejemplo, la clave de documento) y $filter con una consulta de intervalo en su lugar.
$top integer Opcional. El número de resultados de búsqueda que se van a recuperar. El valor predeterminado es 50. Cuando se llama con POST, este parámetro se denomina top en lugar de $top. Si especifica un valor mayor que 1000 y hay más de 1000 resultados, solo se devolverán los primeros 1000 resultados, junto con un vínculo a la página siguiente de resultados (vea @odata.nextLink en el ejemplo siguiente).

Azure Cognitive Search usa la paginación del lado servidor para evitar que las consultas recuperen demasiados documentos a la vez. El tamaño de página predeterminado es 50, mientras que el tamaño máximo de página es 1000. Esto significa que, de forma predeterminada , Los documentos de búsqueda devuelven como máximo 50 resultados si no se especifica $top. Si hay más de 50 resultados, la respuesta incluye información para recuperar la página siguiente de como máximo 50 resultados (vea "@odata.nextLink" y "@search.nextPageParameters" en los ejemplos siguientes. De forma similar, si especifica un valor mayor que 1000 para $top y hay más de 1000 resultados, solo se devuelven los primeros 1000 resultados, junto con información para recuperar la página siguiente de como máximo 1000 resultados.

Response

Código de estado: al obtener una respuesta correcta, se visualiza 200 Correcto.

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

Ejemplos

Puede encontrar ejemplos adicionales en sintaxis de expresiones de OData para Azure Cognitive Search.

  1. Busque en el índice ordenado de manera descendente por fecha:

    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. En una búsqueda por facetas, busque el índice y recupere facetas para categorías, clasificaciones, etiquetas, así como elementos con baseRate en intervalos específicos.

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

    Observe que la última faceta está en un subcampo. Las facetas cuentan el documento primario (Hoteles) y no los subdocumentos intermedios (Rooms), por lo que la respuesta determinará el número de hoteles que tienen habitaciones en cada cubo de precios.

  3. Con un filtro, reduzca el resultado de la consulta por facetas anterior después de que el usuario seleccione Clasificación 3 y categoría "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. En una búsqueda con facetas, establezca un límite superior en términos únicos devueltos en una consulta. El valor predeterminado es 10, pero puede aumentarlo o disminuirlo con el parámetro count en el atributo de faceta. Este ejemplo devuelve facetas por ciudad, limitadas a 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. Busque en el índice dentro de campos específicos (por ejemplo, un campo de idioma):

    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. Busque en el índice en varios campos. Por ejemplo, puede almacenar y consultar los campos de búsqueda en varios idiomas, todo ello en el mismo índice. Si las descripciones de inglés y francés coexisten en el mismo documento, puede devolver cualquiera en los resultados de la consulta:

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

    Solo puede consultar el índice a la vez. No cree varios índices para cada idioma a menos que planee consultar una de cada vez.

  7. Paginación: obtiene la primera página de elementos (el tamaño de página es 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. Paginación: obtenga la segunda página de elementos (el tamaño de página es 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. Recupere un conjunto específico de campos:

    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. Recupere documentos que coincidan con una expresión de filtro específica:

    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. Busque en el índice y devuelva fragmentos con resultados destacados:

    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. Busque en el índice y devuelva documentos ordenados desde los más cercanos a los más lejanos respecto de una ubicación de referencia:

    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. Busque en el índice, suponiendo que existe un perfil de puntuación llamado "geo" con dos funciones de puntuación de distancia, una que define un parámetro llamado "currentLocation" y otro que define un parámetro llamado "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" ]  
        }  
    
  14. Busque documentos en el índice con una sintaxis de consulta simple. Esta consulta devuelve los hoteles, en los que los campos de búsqueda contienen los términos "comodidad" y "ubicación", pero no "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"  
        }  
    

    Sugerencia

    El uso de searchMode=all invalida el valor predeterminado de searchMode=any, lo que asegura que -motel significa "AND NOT" en lugar de "OR NOT". Sin searchMode=all, obtendrá "O NO", que expandirá en lugar de restringir los resultados de la búsqueda, lo cual puede resultar contradictorio para algunos usuarios.

  15. Busque documentos en el índice mediante la sintaxis de consulta de Lucene). Esta consulta devuelve los hoteles en los que el campo de categoría contiene el término "budget" y todos los campos de búsqueda que incluyen la expresión "recently renovated". Los documentos que contienen la expresión "recently renovated" tienen una clasificación más alta como resultado del valor de aumento del término (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. Busque documentos en el índice, a la vez que favorece la puntuación coherente frente a una latencia menor. Esta consulta calculará las frecuencias de documento en todo el índice y hará un mejor esfuerzo para tener como destino la misma réplica para todas las consultas dentro de la misma "sesión", lo que ayudará a generar una clasificación estable y reproducible.

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

Consulte también