123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121 |
- [[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`
|