REST changes

In previous versions of Elasticsearch, JSON documents were allowed to contain unquoted field names. This feature was removed in the 5.x series, but a backwards-compatibility layer was added via the system property elasticsearch.json.allow_unquoted_field_names. This backwards-compatibility layer has been removed in Elasticsearch 6.0.0.

In previous versions of Elasticsearch, documents were allowed to contain duplicate keys. Elasticsearch 6.0.0 enforces that all keys are unique. This applies to all content types: JSON, CBOR, Yaml and Smile.

In previous versions of Elasticsearch, having a proper Content-Type for the data in a request was not enforced. Elasticsearch 6.0.0 enforces that all requests with a body must have a supported Content-Type and this type will be used when parsing the data.

When using the source query string parameter, the source_content_type parameter must also be specified with the media type of the source.

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.

The deprecated request parameters and plain text in request body has been removed. Define parameters in request body.

Analyze API can analyze normalizer and custom normalizer. In previous versions of Elasticsearch, Analyze API is requiring a tokenizer or analyzer parameter. In Elasticsearch 6.0.0, Analyze API can analyze a text as a keyword field with custom normalizer or if char_filter/filter is set and tokenizer/analyzer is not set.

timestamp and ttl are not accepted anymore as parameters of index/update requests.

Refresh requests that are broadcast to multiple shards that can have one or more shards fail during the request now return a 500 response instead of a 200 response in the event there is at least one failure.

In previous versions of Elasticsearch, delete by query requests without an explicit query were accepted, match_all was used as the default query and all documents were deleted as a result. From version 6.0.0, delete by query requests require an explicit query.

Running DELETE index/type/id now implicitly creates type with a default mapping if it did not exist yet.

Previously it was possible to execute GET /_aliases,_mappings or GET /myindex/_settings,_alias by separating multiple types of requests with commas in order to retrieve multiple types of information about one or more indices. This comma-separation for retrieving multiple pieces of information has been removed. GET /_all can be used to retrieve all aliases, settings, and mappings for all indices.

In order to retrieve only the mapping for an index use: GET /myindex/_mapping (or _alias for a list of aliases, or _settings for the settings).

Issuing a request to an endpoint that exists, but with an incorrect HTTP verb (such as a POST request to /myindex/_settings) now returns an HTTP 405 response instead of a 404. An Allow header is added to the 405 responses containing the allowed verbs. For example:

$ curl -v -XPOST 'localhost:9200/my_index/_settings'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
> POST /my_index/_settings HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Allow: PUT,GET
< content-type: application/json; charset=UTF-8
< content-length: 134
<
{
  "error" : "Incorrect HTTP method for uri [/my_index/_settings] and method [POST], allowed: [PUT, GET]",
  "status" : 405
}
* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

The _cache and _cache_key options in queries have been deprecated since version 2.0.0 and have been ignored since then, issuing a deprecation warning. These options have now been completely removed, so using them now will throw an error.

An IndexClosedException is returned whenever an api that doesn’t support closed indices (e.g. search) is called passing closed indices as parameters and ignore_unavailable is set to false. The response status code returned in such case changed from 403 to 400