Buscar documentos (Azure Cognitive Search API REST)

  • Artículo
  • Tiempo de lectura: 22 minutos

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 parámetros que dan forma a la respuesta.

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]  

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 con GET, la longitud de la dirección URL de solicitud no puede superar los 8 KB. Esta longitud suele ser suficiente para la mayoría de las aplicaciones. Sin embargo, algunas aplicaciones generan 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 de los filtros, vea Sintaxis de expresiones de OData para Azure Cognitive Search.

Parámetros de identificador URI

Parámetro Descripción
[nombre del servicio] Obligatorio. Establezca esta opción en el nombre único definido por el usuario del servicio de búsqueda.
[nombre del índice]/docs Obligatorio. 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 Obligatorio. La versión estable actual es api-version=2020-06-30 . Consulte Versiones de API para obtener más versiones. Para 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 parámetros de consulta específicos mediante URL al llamar directamente a la API REST GET. Para una operación de búsqueda de documentos, la codificación de direcciones URL puede 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 necesaria ninguna codificación de dirección URL cuando se usa POST o cuando se usa la biblioteca cliente de .NETAzure 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 Obligatorio. Establezca esta opción en "application/json"
api-key Obligatorio. 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 administración 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 la 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 Azure Cognitive Search no se 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 al no especificar $top o especificar un valor para $top que sea demasiado grande. En tales casos, Azure Cognitive Search incluirá la anotación en el cuerpo de la respuesta y también si @odata.nextLink se trata de una solicitud @search.nextPageParameters 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. Vea el ejemplo de Respuesta siguiente 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 Azure Cognitive Search pueden 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 y es proteger el servicio de las consultas que solicitan demasiados resultados, no proporcionar un mecanismo @odata.nextLink @search.nextPageParameters general para la paginación. Si desea paginar los resultados, use $top y $skip juntos. Por ejemplo, si quiere 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, y así sucesivamente.

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 como aplicables 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 URI independientemente de si se 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, omitiendo $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 puede facetar. La cadena puede contener parámetros para personalizar las caras, expresadas como pares nombre-valor separados por comas. Cuando se llama con POST, este parámetro se denomina facetas en lugar de faceta.

Las válidas 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 por caras 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 suele aumentar 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 descendentemente por recuento. Use -count para ordenar de forma ascendente por count. Use value para ordenar de forma ascendente por valor. Use -value para ordenar 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 de cuántos documentos 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" genera tres depósitos: uno para la velocidad base 0 hasta, pero sin incluir 10, uno para 10 hasta , pero sin incluir 20, y otro para | 20 y superior). Una cadena "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" genera dos depósitos: uno para hoteles restaurados antes de febrero de 2010 y otro para hoteles renovados el 1 de febrero de 2010 o posterior.

"interval" es un intervalo entero mayor que 0 para los valores de fecha y hora, hora, día, semana, mes, trimestre, año. Por ejemplo, "facet=baseRate,interval:100" genera depósitos basados en intervalos de velocidad base de tamaño 100. Si las tarifas base están entre 60 y 600 USD, 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 depósito por cada año en que se han renovado 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 de 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 valores o de intervalo, y interval y los valores no se pueden combinar.

Las facetas de intervalo 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 de 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 filter en lugar de $filter. Consulte Sintaxis de expresiones de OData 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 admiten búsquedas para el resaltado de pulsaciones. De forma predeterminada, Azure Cognitive Search devuelve hasta 5 resaltados por campo. El límite se puede configurar por campo anexando "-<número máximo de resaltados>" después del nombre del campo. Por ejemplo, "highlight=title-3,description-10" devuelve hasta 3 aciertos resaltados del campo de título y hasta 10 aciertos 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 entre 0 y 100, que indica el porcentaje del índice que debe estar disponible para dar servicio a la consulta antes de que se pueda indicar como correcto. El valor predeterminado es "100".

Una cobertura del cien por cien significa que todas las particiones respondieron a la solicitud (no se han reducido los problemas de mantenimiento del servicio ni las actividades de mantenimiento). En la configuración predeterminada, una cobertura inferior a la 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 éxito de las consultas, especialmente para los servicios configurados para una réplica. Si establece minimumCoverage y La búsqueda se realiza correctamente, devolverá HTTP 200 e incluirá un valor en la respuesta que indica el porcentaje del índice incluido en @search.coverage la consulta. En este escenario, no se garantiza que todos los documentos correspondientes estén presentes en los resultados de la búsqueda, pero si la disponibilidad de 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 $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 de búsqueda (o campos indicados en searchFields) de cada documento de forma predeterminada.

"full" interpreta las cadenas de consulta mediante la sintaxis de consulta completa de Lucene, que permite búsquedas ponderadas y específicas del 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 (por ejemplo, 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 nombre-valores independiente.

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 llamada "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 así como para el aprovechamiento de etiquetas que contienen comas, es posible separar tales valores de la lista mediante el uso de comillas simples. Si los propios valores contienen comillas simples, puede separarlos duplicando la comilla simple. Supongamos que tiene un parámetro de potenciación de etiquetas llamado y desea aumentar los valores de etiqueta "Hello, O'Alexa" y "Smith", la opción de cadena de consulta "mytag" sería "&scoringParameter=mytag-'Hello, O''Parameter',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 desea calcular estadísticas de puntuación, como la frecuencia del documento, globalmente (en todas las particiones) para una puntuación más coherente o localmente (en la partición actual) para una latencia menor. Vea 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 que permite búsquedas se tokeniza, por lo que varios términos se pueden separar 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 realizar consultas en campos en los que se pueden realizar búsquedas. 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 solo 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 esta razón, se recomienda usar espacios en blanco en lugar de signos de puntuación para separar los términos en el parámetro de búsqueda.
searchMode string Opcional. Los valores válidos son "any" o "all" Los valores predeterminados son "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 incluirán en el conjunto de resultados. En esta cláusula solo se pueden incluir campos marcados como recuperables. 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 ligeras diferencias entre las puntuaciones de relevancia de documentos individuales para la misma consulta. Cuando se proporciona un identificador de sesión, el servicio hará todo lo posible para enrutar una solicitud determinada a la misma réplica para esa sesión. Tenga cuidado de que volver a usar 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 ninguna réplica, este parámetro no tiene ningún efecto en el rendimiento ni en la coherencia de 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 del 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 siguiente página de resultados (consulte en el ejemplo @odata.nextLink siguiente).

Azure Cognitive Search 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, Buscar documentos devuelve 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 " " y " " en los ejemplos @odata.nextLink @search.nextPageParameters siguientes. Del mismo modo, 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 en 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 se encuentra en un subdominio. Las facetas cuentan el documento primario (Hoteles) y no los sub documentos intermedios (Salas), por lo que la respuesta determinará el número de hoteles que tienen habitaciones en cada depósito de precios.

  3. Con un filtro, reduzca el resultado de la consulta por caras 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: obtiene 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 sobre una latencia inferior. Esta consulta calculará las frecuencias de documento en todo el índice y hará todo lo posible para dirigirse a 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"
    }

Vea también