122 lines
5.1 KiB
Plaintext
122 lines
5.1 KiB
Plaintext
[[breaking_60_rest_changes]]
|
|
=== REST changes
|
|
|
|
==== Unquoted JSON
|
|
|
|
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.
|
|
|
|
==== Duplicate Keys in JSON, CBOR, Yaml and Smile
|
|
|
|
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.
|
|
|
|
==== Content-Type Auto-detection
|
|
|
|
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.
|
|
|
|
==== Boolean API parameters
|
|
|
|
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.
|
|
|
|
==== Analyze API changes
|
|
|
|
The deprecated request parameters and plain text in request body has been removed. Define parameters in request body.
|
|
|
|
==== Support custom normalizer in Analyze API
|
|
|
|
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.
|
|
|
|
==== Indices exists API
|
|
|
|
The `ignore_unavailable` and `allow_no_indices` options are no longer accepted
|
|
as they could cause undesired results when their values differed from their
|
|
defaults.
|
|
|
|
==== `timestamp` and `ttl` in index requests
|
|
|
|
`timestamp` and `ttl` are not accepted anymore as parameters of index/update
|
|
requests.
|
|
|
|
==== Refresh requests with one or more shard failures return HTTP 500 response instead of 200
|
|
|
|
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.
|
|
|
|
==== Delete by Query API requires an explicit query
|
|
|
|
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.
|
|
|
|
==== DELETE document calls now implicitly create the type
|
|
|
|
Running `DELETE index/type/id` now implicitly creates `type` with a default
|
|
mapping if it did not exist yet.
|
|
|
|
==== Indices information APIs
|
|
|
|
Previously it was possible to execute `GET /_aliases,_mappings` or `GET
|
|
/myindex/_settings,_alias` by separating mulitple 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 mappings for an index,
|
|
`GET /myindex/_mappings` (or `_aliases`, or `_settings`).
|
|
|
|
==== Requests to existing endpoints with incorrect HTTP verb now return 405 responses
|
|
|
|
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:
|
|
|
|
[source,text]
|
|
-------------------------------------------
|
|
$ 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
|
|
--------------------------------------------
|
|
|
|
==== Disallow using `_cache` and `_cache_key`
|
|
|
|
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.
|
|
|
|
==== IndexClosedException to return 400 status code
|
|
|
|
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`
|