Elasticsearch6.4专题之8:API Conventions(API 约定)

API Conventions(API 约定)

Multiple Indices

Most APIs that refer to an index parameter support execution across multiple indices, using simple test1,test2,test3 notation (or _all for all indices). It also support wildcards, for example: test* or *test or te*t or *test*, and the ability to “exclude” (-), for example: test*,-test3.

All multi indices API support the following url query string parameters:

• ignore_unavailable
  
  Controls whether to ignore if any specified indices are unavailable, this includes indices that don’t exist or closed indices. Either true or false can be specified.
• allow_no_indices
  
  Controls whether to fail if a wildcard indices expressions results into no concrete indices. Either true or false can be specified. For example if the wildcard expression foo* is specified and no indices are available that start with foo then depending on this setting the request will fail. This setting is also applicable when _all, * or no index has been specified. This settings also applies for aliases, in case an alias points to a closed index.
• expand_wildcards
  
  Controls to what kind of concrete indices wildcard indices expression expand to. If open is specified then the wildcard expression is expanded to only open indices and if closed is specified then the wildcard expression is expanded only to closed indices. Also both values (open,closed) can be specified to expand to all indices.

If none is specified then wildcard expansion will be disabled and if all is specified, wildcard expressions will expand to all indices (this is equivalent to specifying open,closed).

Date math support in index names

Date math index name resolution enables you to search a range of time-series indices, rather than searching all of your time-series indices and filtering the results or maintaining aliases. Limiting the number of indices that are searched reduces the load on the cluster and improves execution performance. For example, if you are searching for errors in your daily logs, you can use a date math name template to restrict the search to the past two days.

Almost all APIs that have an index parameter, support date math in the index parameter value.

A date math index name takes the following form:

<static_name{date_math_expr{date_format|time_zone}}>

Where:

• static_name
  
  is the static text part of the name
• date_math_expr
  
  is a dynamic date math expression that computes the date dynamically
• date_format
  
  is the optional format in which the computed date should be rendered. Defaults to YYYY.MM.dd.
• time_zone
  
  is the optional time zone . Defaults to utc.

You must enclose date math index name expressions within angle brackets, and all special characters should be URI encoded. For example:

# GET /<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
  "query" : {
    "match": {
      "test": "data"
    }
  }
}
或者
# GET /<logstash-{now/d}>/_search
curl -X GET "localhost:9200/%3Clogstash-%7Bnow%2Fd%7D%3E/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "query" : {
    "match": {
      "test": "data"
    }
  }
}'

Percent encoding of date math characters
The special characters used for date rounding must be URI encoded as follows:

header 1	header 2
<	%3C
>	%3E
/	%2F
{	%7B
}	%7D
	%7C
+	%2B
:	%3A
,	%2C

The following example shows different forms of date math index names and the final index names they resolve to given the current time is 22nd March 2024 noon utc.

Expression	Resolves to
<logstash-{now/d}>	logstash-2024.03.22
<logstash-{now/M}>	logstash-2024.03.01
<logstash-{now/M{YYYY.MM}}>	logstash-2024.03
<logstash-{now/M-1M{YYYY.MM}}>	logstash-2024.02
<logstash-{now/d{YYYY.MM.dd|+12:00}}>	logstash-2024.03.23

To use the characters { and } in the static part of an index name template, escape them with a backslash , for example:

<elastic\\{ON\\}-{now/M}> resolves to elastic{ON}-2024.03.01

The following example shows a search request that searches the Logstash indices for the past three days, assuming the indices use the default Logstash index name format, logstash-YYYY.MM.dd.

# GET /<logstash-{now/d-2d}>,<logstash-{now/d-1d}>,<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd-2d%7D%3E%2C%3Clogstash-%7Bnow%2Fd-1d%7D%3E%2C%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
  "query" : {
    "match": {
      "test": "data"
    }
  }
}
或
# GET /<logstash-{now/d-2d}>,<logstash-{now/d-1d}>,<logstash-{now/d}>/_search
curl -X GET "localhost:9200/%3Clogstash-%7Bnow%2Fd-2d%7D%3E%2C%3Clogstash-%7Bnow%2Fd-1d%7D%3E%2C%3Clogstash-%7Bnow%2Fd%7D%3E/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "query" : {
    "match": {
      "test": "data"
    }
  }
}'

Common options

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

Pretty Results

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

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.

Date Math

Most parameters which accept a formatted date value—such as gt and lt in range queries range queries, or from and to in daterange aggregations—understand date maths.

The expression starts with an anchor date, which can either be now, or a date string ending with ||. This anchor date can optionally be followed by one or more maths expressions:

• +1h - add one hour
• -1d - subtract one day
• /d - round down to the nearest day

The supported time units differ from those supported by time units for durations. The supported units are:

header1	header1
y	years
M	months
w	weeks
d	days
h	hours
H	hours
m	minutes
s	seconds

Assuming now is 2001-01-01 12:00:00, some examples are:

• now+1h
  
  now in milliseconds plus one hour. Resolves to: 2001-01-01 13:00:00
• now-1h
  
  now in milliseconds minus one hour. Resolves to: 2001-01-01 11:00:00
• now-1h/d
  
  now in milliseconds minus one hour, rounded down to UTC 00:00. Resolves to: 2001-01-01 00:00:00
• 2001.02.01\|\|+1M/d
  
  2001-02-01 in milliseconds plus one month. Resolves to: 2001-03-01 00:00:00

Response Filtering

All REST APIs accept a filter_path parameter that can be used to reduce the response returned by Elasticsearch. This parameter takes a comma separated list of filters expressed with the dot notation:

GET /_search?q=elasticsearch&filter_path=took,hits.hits._id,hits.hits._score
或
curl -X GET "localhost:9200/_search?q=elasticsearch&filter_path=took,hits.hits._id,hits.hits._score&pretty"

It also supports the * wildcard character to match any field or part of a field’s name:

GET /_cluster/state?filter_path=metadata.indices.*.stat*
或
curl -X GET "localhost:9200/_cluster/state?filter_path=metadata.indices.*.stat*&pretty"

And the ** wildcard can be used to include fields without knowing the exact path of the field. For example, we can return the Lucene version of every segment with this request:

GET /_cluster/state?filter_path=routing_table.indices.**.state
或
curl -X GET "localhost:9200/_cluster/state?filter_path=routing_table.indices.**.state&pretty"

It is also possible to exclude one or more fields by prefixing the filter with the char -:

GET /_count?filter_path=-_shards
或
curl -X GET "localhost:9200/_count?filter_path=-_shards&pretty"

And for more control, both inclusive and exclusive filters can be combined in the same expression. In this case, the exclusive filters will be applied first and the result will be filtered again using the inclusive filters:

GET /_cluster/state?filter_path=metadata.indices.*.state,-metadata.indices.logstash-*
或
curl -X GET "localhost:9200/_cluster/state?filter_path=metadata.indices.*.state,-metadata.indices.logstash-*&pretty"

Note that Elasticsearch sometimes returns directly the raw value of a field, like the _source field. If you want to filter _source fields, you should consider combining the already existing _source parameter (see Get API for more details) with the filter_path parameter like this:

POST /library/book?refresh
{"title": "Book #1", "rating": 200.1}
POST /library/book?refresh
{"title": "Book #2", "rating": 1.7}
POST /library/book?refresh
{"title": "Book #3", "rating": 0.1}
GET /_search?filter_path=hits.hits._source&_source=title&sort=rating:desc
或
curl -X POST "localhost:9200/library/book?refresh&pretty" -H 'Content-Type: application/json' -d'
{"title": "Book #1", "rating": 200.1}
'
curl -X POST "localhost:9200/library/book?refresh&pretty" -H 'Content-Type: application/json' -d'
{"title": "Book #2", "rating": 1.7}
'
curl -X POST "localhost:9200/library/book?refresh&pretty" -H 'Content-Type: application/json' -d'
{"title": "Book #3", "rating": 0.1}
'
curl -X GET "localhost:9200/_search?filter_path=hits.hits._source&_source=title&sort=rating:desc&pretty"

Flat Settings

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

GET twitter/_settings?flat_settings=true
或
curl -X GET "localhost:9200/twitter/_settings?flat_settings=true&pretty"

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

GET twitter/_settings?flat_settings=false
或
curl -X GET "localhost:9200/twitter/_settings?flat_settings=false&pretty"

By default the flat_settings is set to false.

Parameters

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

Boolean Values

All REST APIs parameters (both request parameters and JSON body) support providing boolean “false” as the value false and boolean “true” as the value true. All other values will raise an error.

Number Values

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

Time units

Whenever durations need to be specified, e.g. for a timeout parameter, the duration must specify the unit, like 2d for 2 days. The supported units are:

header 1	header 2
d	days
h	hours
m	minutes
s	seconds
ms	milliseconds
micros	microseconds
nanos	nanoseconds

Byte size units

Whenever the byte size of data needs to be specified, eg when setting a buffer size parameter, the value must specify the unit, like 10kb for 10 kilobytes. Note that these units use powers of 1024, so 1kb means 1024 bytes. The supported units are:

header 1	header 2
b	Bytes
kb	Kilobytes
mb	Megabytes
gb	Gigabytes
tb	Terabytes
pb	Petabytes

Unit-less quantities

Unit-less quantities means that they don’t have a “unit” like “bytes” or “Hertz” or “meter” or “long tonne”.

If one of these quantities is large we’ll print it out like 10m for 10,000,000 or 7k for 7,000. We’ll still print 87 when we mean 87 though. These are the supported multipliers:

header 1	header 2
``	Single
k	Kilo
m	Mega
g	Giga
t	Tera
p	Peta

Distance Units

Wherever distances need to be specified, such as the distance parameter in the Geo Distance Query), 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:

header 1	header 2
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

Fuzziness

Some queries and APIs support parameters to allow inexact fuzzy matching, using the fuzziness parameter.

When querying text or keyword 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. Low and high distance arguments may be optionally provided AUTO:[low],[high], if not specified, the default values are 3 and 6, equivalent to AUTO:3,6 that make 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.

Enabling stack traces

By default when a request returns an error Elasticsearch doesn’t include the stack trace of the error. You can enable that behavior by setting the error_trace url parameter to true. For example, by default when you send an invalid size parameter to the _search API:

POST /twitter/_search?size=surprise_me
或
curl -X POST "localhost:9200/twitter/_search?size=surprise_me&pretty"

But if you set error_trace=true:

POST /twitter/_search?size=surprise_me&error_trace=true
或
curl -X POST "localhost:9200/twitter/_search?size=surprise_me&error_trace=true&pretty"

Request body in query string

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. When using this method, the source_content_type parameter should also be passed with a media type value that indicates the format of the source, such as application/json.

Content-Type Requirements

The type of the content sent in a request body must be specified using the Content-Type header. The value of this header must map to one of the supported formats that the API supports. Most APIs support JSON, YAML, CBOR, and SMILE. The bulk and multi-search APIs support NDJSON, JSON and SMILE; other types will result in an error response.

Additionally, when using the source query string parameter the content type must be specified using the source_content_type query string parameter.

URL-based access control

Many users use a proxy with URL-based access control to secure access to Elasticsearch indices. For multi-search, multi-get and bulk requests, the user has the choice of specifying an index in the URL and on each individual request within the request body. This can make URL-based access control challenging.

To prevent the user from overriding the index which has been specified in the URL, add this setting to the elasticsearch.yml file:

rest.action.multi.allow_explicit_index: false

The default value is true, but when set to false, Elasticsearch will reject requests that have an explicit index specified in the request body.