api-conventions.asciidoc 9.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289
  1. [[api-conventions]]
  2. = API Conventions
  3. [partintro]
  4. --
  5. The *elasticsearch* REST APIs are exposed using:
  6. * <<modules-http,JSON over HTTP>>,
  7. * <<modules-thrift,thrift>>,
  8. * <<modules-memcached,memcached>>.
  9. The conventions listed in this chapter can be applied throughout the REST
  10. API, unless otherwise specified.
  11. * <<multi-index>>
  12. * <<common-options>>
  13. --
  14. [[multi-index]]
  15. == Multiple Indices
  16. Most APIs that refer to an `index` parameter support execution across multiple indices,
  17. using simple `test1,test2,test3` notation (or `_all` for all indices). It also
  18. support wildcards, for example: `test*`, and the ability to "add" (`+`)
  19. and "remove" (`-`), for example: `+test*,-test3`.
  20. All multi indices API support the following url query string parameters:
  21. `ignore_unavailable`::
  22. Controls whether to ignore if any specified indices are unavailable, this
  23. includes indices that don't exist or closed indices. Either `true` or `false`
  24. can be specified.
  25. `allow_no_indices`::
  26. Controls whether to fail if a wildcard indices expressions results into no
  27. concrete indices. Either `true` or `false` can be specified. For example if
  28. the wildcard expression `foo*` is specified and no indices are available that
  29. start with `foo` then depending on this setting the request will fail. This
  30. setting is also applicable when `_all`, `*` or no index has been specified. This
  31. settings also applies for aliases, in case an alias points to a closed index.
  32. `expand_wildcards`::
  33. Controls to what kind of concrete indices wildcard indices expression expand
  34. to. If `open` is specified then the wildcard expression is expanded to only
  35. open indices and if `closed` is specified then the wildcard expression is
  36. expanded only to closed indices. Also both values (`open,closed`) can be
  37. specified to expand to all indices.
  38. If `none` is specified then wildcard expansion will be disabled and if `all`
  39. is specified, wildcard expressions will expand to all indices (this is equivalent
  40. to specifying `open,closed`).
  41. The defaults settings for the above parameters depend on the api being used.
  42. NOTE: Single index APIs such as the <<docs>> and the
  43. <<indices-aliases,single-index `alias` APIs>> do not support multiple indices.
  44. [[common-options]]
  45. == Common options
  46. The following options can be applied to all of the REST APIs.
  47. [float]
  48. === Pretty Results
  49. When appending `?pretty=true` to any request made, the JSON returned
  50. will be pretty formatted (use it for debugging only!). Another option is
  51. to set `?format=yaml` which will cause the result to be returned in the
  52. (sometimes) more readable yaml format.
  53. [float]
  54. === Human readable output
  55. Statistics are returned in a format suitable for humans
  56. (eg `"exists_time": "1h"` or `"size": "1kb"`) and for computers
  57. (eg `"exists_time_in_millis": 3600000` or `"size_in_bytes": 1024`).
  58. The human readable values can be turned off by adding `?human=false`
  59. to the query string. This makes sense when the stats results are
  60. being consumed by a monitoring tool, rather than intended for human
  61. consumption. The default for the `human` flag is
  62. `false`.
  63. [float]
  64. === Flat Settings
  65. The `flat_settings` flag affects rendering of the lists of settings. When
  66. `flat_settings` flag is `true` settings are returned in a flat format:
  67. [source,js]
  68. --------------------------------------------------
  69. {
  70. "persistent" : { },
  71. "transient" : {
  72. "discovery.zen.minimum_master_nodes" : "1"
  73. }
  74. }
  75. --------------------------------------------------
  76. When the `flat_settings` flag is `false` settings are returned in a more
  77. human readable structured format:
  78. [source,js]
  79. --------------------------------------------------
  80. {
  81. "persistent" : { },
  82. "transient" : {
  83. "discovery" : {
  84. "zen" : {
  85. "minimum_master_nodes" : "1"
  86. }
  87. }
  88. }
  89. }
  90. --------------------------------------------------
  91. By default the `flat_settings` is set to `false`.
  92. [float]
  93. === Parameters
  94. Rest parameters (when using HTTP, map to HTTP URL parameters) follow the
  95. convention of using underscore casing.
  96. [float]
  97. === Boolean Values
  98. All REST APIs parameters (both request parameters and JSON body) support
  99. providing boolean "false" as the values: `false`, `0`, `no` and `off`.
  100. All other values are considered "true". Note, this is not related to
  101. fields within a document indexed treated as boolean fields.
  102. [float]
  103. === Number Values
  104. All REST APIs support providing numbered parameters as `string` on top
  105. of supporting the native JSON number types.
  106. [[time-units]]
  107. [float]
  108. === Time units
  109. Whenever durations need to be specified, eg for a `timeout` parameter, the duration
  110. can be specified as a whole number representing time in milliseconds, or as a time value like `2d` for 2 days. The supported units are:
  111. [horizontal]
  112. `y`:: Year
  113. `M`:: Month
  114. `w`:: Week
  115. `d`:: Day
  116. `h`:: Hour
  117. `m`:: Minute
  118. `s`:: Second
  119. [[distance-units]]
  120. [float]
  121. === Distance Units
  122. Wherever distances need to be specified, such as the `distance` parameter in
  123. the <<query-dsl-geo-distance-filter>>), the default unit if none is specified is
  124. the meter. Distances can be specified in other units, such as `"1km"` or
  125. `"2mi"` (2 miles).
  126. The full list of units is listed below:
  127. [horizontal]
  128. Mile:: `mi` or `miles`
  129. Yard:: `yd` or `yards`
  130. Feet:: `ft` or `feet`
  131. Inch:: `in` or `inch`
  132. Kilometer:: `km` or `kilometers`
  133. Meter:: `m` or `meters`
  134. Centimeter:: `cm` or `centimeters`
  135. Millimeter:: `mm` or `millimeters`
  136. Nautical mile:: `NM`, `nmi` or `nauticalmiles`
  137. The `precision` parameter in the <<query-dsl-geohash-cell-filter>> accepts
  138. distances with the above units, but if no unit is specified, then the
  139. precision is interpreted as the length of the geohash.
  140. [[fuzziness]]
  141. [float]
  142. === Fuzziness
  143. Some queries and APIs support parameters to allow inexact _fuzzy_ matching,
  144. using the `fuzziness` parameter. The `fuzziness` parameter is context
  145. sensitive which means that it depends on the type of the field being queried:
  146. [float]
  147. ==== Numeric, date and IPv4 fields
  148. When querying numeric, date and IPv4 fields, `fuzziness` is interpreted as a
  149. `+/-` margin. It behaves like a <<query-dsl-range-query>> where:
  150. -fuzziness <= field value <= +fuzziness
  151. The `fuzziness` parameter should be set to a numeric value, eg `2` or `2.0`. A
  152. `date` field interprets a long as milliseconds, but also accepts a string
  153. containing a time value -- `"1h"` -- as explained in <<time-units>>. An `ip`
  154. field accepts a long or another IPv4 address (which will be converted into a
  155. long).
  156. [float]
  157. ==== String fields
  158. When querying `string` fields, `fuzziness` is interpreted as a
  159. http://en.wikipedia.org/wiki/Levenshtein_distance[Levenshtein Edit Distance]
  160. -- the number of one character changes that need to be made to one string to
  161. make it the same as another string.
  162. The `fuzziness` parameter can be specified as:
  163. `0`, `1`, `2`::
  164. the maximum allowed Levenshtein Edit Distance (or number of edits)
  165. `AUTO`::
  166. +
  167. --
  168. generates an edit distance based on the length of the term. For lengths:
  169. `0..1`:: must match exactly
  170. `1..5`:: one edit allowed
  171. `>5`:: two edits allowed
  172. `AUTO` should generally be the preferred value for `fuzziness`.
  173. --
  174. `0.0..1.0`::
  175. converted into an edit distance using the formula: `length(term) * (1.0 -
  176. fuzziness)`, eg a `fuzziness` of `0.6` with a term of length 10 would result
  177. in an edit distance of `4`. Note: in all APIs except for the
  178. <<query-dsl-flt-query>>, the maximum allowed edit distance is `2`.
  179. [float]
  180. === Result Casing
  181. All REST APIs accept the `case` parameter. When set to `camelCase`, all
  182. field names in the result will be returned in camel casing, otherwise,
  183. underscore casing will be used. Note, this does not apply to the source
  184. document indexed.
  185. [float]
  186. === JSONP
  187. By default JSONP responses are disabled.
  188. When enabled, all REST APIs accept a `callback` parameter
  189. resulting in a http://en.wikipedia.org/wiki/JSONP[JSONP] result. You can enable
  190. this behavior by adding the following to `config.yaml`:
  191. http.jsonp.enable: true
  192. Please note, when enabled, due to the architecture of Elasticsearch, this may pose
  193. a security risk. Under some circumstances, an attacker may be able to exfiltrate
  194. data in your Elasticsearch server if they're able to force your browser to make a
  195. JSONP request on your behalf (e.g. by including a <script> tag on an untrusted site
  196. with a legitimate query against a local Elasticsearch server).
  197. [float]
  198. === Request body in query string
  199. For libraries that don't accept a request body for non-POST requests,
  200. you can pass the request body as the `source` query string parameter
  201. instead.
  202. [[url-access-control]]
  203. == URL-based access control
  204. Many users use a proxy with URL-based access control to secure access to
  205. Elasticsearch indices. For <<search-multi-search,multi-search>>,
  206. <<docs-multi-get,multi-get>> and <<docs-bulk,bulk>> requests, the user has
  207. the choice of specifying an index in the URL and on each individual request
  208. within the request body. This can make URL-based access control challenging.
  209. To prevent the user from overriding the index which has been specified in the
  210. URL, add this setting to the `config.yml` file:
  211. rest.action.multi.allow_explicit_index: false
  212. The default value is `true`, but when set to `false`, Elasticsearch will
  213. reject requests that have an explicit index specified in the request body.