uri-request.asciidoc 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135
  1. [[search-uri-request]]
  2. === URI Search
  3. A search request can be executed purely using a URI by providing request
  4. parameters. Not all search options are exposed when executing a search
  5. using this mode, but it can be handy for quick "curl tests". Here is an
  6. example:
  7. [source,js]
  8. --------------------------------------------------
  9. GET twitter/_search?q=user:kimchy
  10. --------------------------------------------------
  11. // CONSOLE
  12. // TEST[setup:twitter]
  13. And here is a sample response:
  14. [source,js]
  15. --------------------------------------------------
  16. {
  17. "timed_out": false,
  18. "took": 62,
  19. "_shards":{
  20. "total" : 1,
  21. "successful" : 1,
  22. "skipped" : 0,
  23. "failed" : 0
  24. },
  25. "hits":{
  26. "total" : {
  27. "value": 1,
  28. "relation": "eq"
  29. },
  30. "max_score": 1.3862944,
  31. "hits" : [
  32. {
  33. "_index" : "twitter",
  34. "_type" : "_doc",
  35. "_id" : "0",
  36. "_score": 1.3862944,
  37. "_source" : {
  38. "user" : "kimchy",
  39. "date" : "2009-11-15T14:12:12",
  40. "message" : "trying out Elasticsearch",
  41. "likes": 0
  42. }
  43. }
  44. ]
  45. }
  46. }
  47. --------------------------------------------------
  48. // TESTRESPONSE[s/"took": 62/"took": "$body.took"/]
  49. [float]
  50. ==== Parameters
  51. The parameters allowed in the URI are:
  52. [cols="<,<",options="header",]
  53. |=======================================================================
  54. |Name |Description
  55. |`q` |The query string (maps to the `query_string` query, see
  56. <<query-dsl-query-string-query,_Query String
  57. Query_>> for more details).
  58. |`df` |The default field to use when no field prefix is defined within the
  59. query.
  60. |`analyzer` |The analyzer name to be used when analyzing the query string.
  61. |`analyze_wildcard` |Should wildcard and prefix queries be analyzed or
  62. not. Defaults to `false`.
  63. |`batched_reduce_size` | The number of shard results that should be reduced
  64. at once on the coordinating node. This value should be used as a protection
  65. mechanism to reduce the memory overhead per search request if the potential
  66. number of shards in the request can be large.
  67. |`default_operator` |The default operator to be used, can be `AND` or
  68. `OR`. Defaults to `OR`.
  69. |`lenient` |If set to true will cause format based failures (like
  70. providing text to a numeric field) to be ignored. Defaults to false.
  71. |`explain` |For each hit, contain an explanation of how scoring of the
  72. hits was computed.
  73. |`_source`|Set to `false` to disable retrieval of the `_source` field. You can also retrieve
  74. part of the document by using `_source_includes` & `_source_excludes` (see the <<request-body-search-source-filtering, request body>>
  75. documentation for more details)
  76. |`stored_fields` |The selective stored fields of the document to return for each hit,
  77. comma delimited. Not specifying any value will cause no fields to return.
  78. |`sort` |Sorting to perform. Can either be in the form of `fieldName`, or
  79. `fieldName:asc`/`fieldName:desc`. The fieldName can either be an actual
  80. field within the document, or the special `_score` name to indicate
  81. sorting based on scores. There can be several `sort` parameters (order
  82. is important).
  83. |`track_scores` |When sorting, set to `true` in order to still track
  84. scores and return them as part of each hit.
  85. |`track_total_hits` |Defaults to `10,000`. Set to `false` in order to disable the tracking
  86. of the total number of hits that match the query.
  87. It also accepts an integer which in this case represents the number of
  88. hits to count accurately.
  89. (See the <<request-body-search-track-total-hits, request body>> documentation
  90. for more details).
  91. |`timeout` |A search timeout, bounding the search request to be executed
  92. within the specified time value and bail with the hits accumulated up to
  93. that point when expired. Defaults to no timeout.
  94. |`terminate_after` |The maximum number of documents to collect for
  95. each shard, upon reaching which the query execution will terminate early.
  96. If set, the response will have a boolean field `terminated_early` to
  97. indicate whether the query execution has actually terminated_early.
  98. Defaults to no terminate_after.
  99. |`from` |The starting from index of the hits to return. Defaults to `0`.
  100. |`size` |The number of hits to return. Defaults to `10`.
  101. |`search_type` |The type of the search operation to perform. Can be
  102. `dfs_query_then_fetch` or `query_then_fetch`.
  103. Defaults to `query_then_fetch`. See
  104. <<request-body-search-search-type,_Search Type_>> for
  105. more details on the different types of search that can be performed.
  106. |`allow_partial_search_results` |Set to `false` to return an overall failure if the request would produce
  107. partial results. Defaults to true, which will allow partial results in the case of timeouts
  108. or partial failures. This default can be controlled using the cluster-level setting
  109. `search.default_allow_partial_results`.
  110. |=======================================================================