Common options

edit

The following options can be applied to all of the REST APIs.

Pretty Results

edit

When appending ?pretty=true to any request made, the JSON returned will be pretty formatted (use it for debugging only!). Another option is to set ?format=yaml which will cause the result to be returned in the (sometimes) more readable yaml format.

Human readable output

edit

Statistics are returned in a format suitable for humans (eg "exists_time": "1h" or "size": "1kb") and for computers (eg "exists_time_in_millis": 3600000 or "size_in_bytes": 1024). The human readable values can be turned off by adding ?human=false to the query string. This makes sense when the stats results are being consumed by a monitoring tool, rather than intended for human consumption. The default for the human flag is false.

Flat Settings

edit

The flat_settings flag affects rendering of the lists of settings. When flat_settings flag is true settings are returned in a flat format:

{
  "persistent" : { },
  "transient" : {
    "discovery.zen.minimum_master_nodes" : "1"
  }
}

When the flat_settings flag is false settings are returned in a more human readable structured format:

{
  "persistent" : { },
  "transient" : {
    "discovery" : {
      "zen" : {
        "minimum_master_nodes" : "1"
      }
    }
  }
}

By default the flat_settings is set to false.

Parameters

edit

Rest parameters (when using HTTP, map to HTTP URL parameters) follow the convention of using underscore casing.

Boolean Values

edit

All REST APIs parameters (both request parameters and JSON body) support providing boolean "false" as the values: false, 0, no and off. All other values are considered "true". Note, this is not related to fields within a document indexed treated as boolean fields.

Number Values

edit

All REST APIs support providing numbered parameters as string on top of supporting the native JSON number types.

Time units

edit

Whenever durations need to be specified, eg for a timeout parameter, the duration 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:

y

Year

M

Month

w

Week

d

Day

h

Hour

m

Minute

s

Second

Distance Units

edit

Wherever distances need to be specified, such as the distance parameter in the Geo Distance Filter), the default unit if none is specified is the meter. Distances can be specified in other units, such as "1km" or "2mi" (2 miles).

The full list of units is listed below:

Mile

mi or miles

Yard

yd or yards

Feet

ft or feet

Inch

in or inch

Kilometer

km or kilometers

Meter

m or meters

Centimeter

cm or centimeters

Millimeter

mm or millimeters

Nautical mile

NM, nmi or nauticalmiles

The precision parameter in the Geohash Cell Filter accepts distances with the above units, but if no unit is specified, then the precision is interpreted as the length of the geohash.

Fuzziness

edit

Some queries and APIs support parameters to allow inexact fuzzy matching, using the fuzziness parameter. The fuzziness parameter is context sensitive which means that it depends on the type of the field being queried:

Numeric, date and IPv4 fields

edit

When querying numeric, date and IPv4 fields, fuzziness is interpreted as a +/- margin. It behaves like a Range Query where:

-fuzziness <= field value <= +fuzziness

The fuzziness parameter should be set to a numeric value, eg 2 or 2.0. A date field interprets a long as milliseconds, but also accepts a string containing a time value — "1h" — as explained in Time units. An ip field accepts a long or another IPv4 address (which will be converted into a long).

String fields

edit

When querying string fields, fuzziness is interpreted as a Levenshtein Edit Distance — the number of one character changes that need to be made to one string to make it the same as another string.

The fuzziness parameter can be specified as:

0, 1, 2
the maximum allowed Levenshtein Edit Distance (or number of edits)
AUTO

generates an edit distance based on the length of the term. For lengths:

0..2
must match exactly
3..5
one edit allowed
>5
two edits allowed

AUTO should generally be the preferred value for fuzziness.

0.0..1.0
converted into an edit distance using the formula: length(term) * (1.0 - fuzziness), eg a fuzziness of 0.6 with a term of length 10 would result in an edit distance of 4. Note: in all APIs except for the Fuzzy Like This Query, the maximum allowed edit distance is 2.

Result Casing

edit

All REST APIs accept the case parameter. When set to camelCase, all field names in the result will be returned in camel casing, otherwise, underscore casing will be used. Note, this does not apply to the source document indexed.

JSONP

edit

When enabled, all REST APIs accept a callback parameter resulting in a JSONP result. You can enable this behavior by adding the following to config.yaml:

http.jsonp.enable: true

Please note, when enabled, due to the architecture of Elasticsearch, this may pose a security risk. Under some circumstances, an attacker may be able to exfiltrate data in your Elasticsearch server if they’re able to force your browser to make a JSONP request on your behalf (e.g. by including a <script> tag on an untrusted site with a legitimate query against a local Elasticsearch server).

Request body in query string

edit

For libraries that don’t accept a request body for non-POST requests, you can pass the request body as the source query string parameter instead.