rest.asciidoc 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121
  1. [[breaking_60_rest_changes]]
  2. === REST changes
  3. ==== Unquoted JSON
  4. In previous versions of Elasticsearch, JSON documents were allowed to contain unquoted field names.
  5. This feature was removed in the 5.x series, but a backwards-compatibility layer was added via the
  6. system property `elasticsearch.json.allow_unquoted_field_names`. This backwards-compatibility layer
  7. has been removed in Elasticsearch 6.0.0.
  8. ==== Duplicate Keys in JSON, CBOR, Yaml and Smile
  9. In previous versions of Elasticsearch, documents were allowed to contain duplicate keys. Elasticsearch 6.0.0
  10. enforces that all keys are unique. This applies to all content types: JSON, CBOR, Yaml and Smile.
  11. ==== Content-Type Auto-detection
  12. In previous versions of Elasticsearch, having a proper Content-Type for the data in a request was not enforced.
  13. Elasticsearch 6.0.0 enforces that all requests with a body must have a supported Content-Type and this type will
  14. be used when parsing the data.
  15. When using the `source` query string parameter, the `source_content_type` parameter must also be specified with
  16. the media type of the source.
  17. ==== Boolean API parameters
  18. All REST APIs parameters (both request parameters and JSON body) support providing boolean "false" as the
  19. value `false` and boolean "true" as the value `true`. All other values will raise an error.
  20. ==== Analyze API changes
  21. The deprecated request parameters and plain text in request body has been removed. Define parameters in request body.
  22. ==== Support custom normalizer in Analyze API
  23. Analyze API can analyze normalizer and custom normalizer.
  24. In previous versions of Elasticsearch, Analyze API is requiring a `tokenizer` or `analyzer` parameter.
  25. In Elasticsearch 6.0.0, Analyze API can analyze a text as a keyword field with custom normalizer
  26. or if `char_filter`/`filter` is set and `tokenizer`/`analyzer` is not set.
  27. ==== Indices exists API
  28. The `ignore_unavailable` and `allow_no_indices` options are no longer accepted
  29. as they could cause undesired results when their values differed from their
  30. defaults.
  31. ==== `timestamp` and `ttl` in index requests
  32. `timestamp` and `ttl` are not accepted anymore as parameters of index/update
  33. requests.
  34. ==== Refresh requests with one or more shard failures return HTTP 500 response instead of 200
  35. Refresh requests that are broadcast to multiple shards that can have one or more
  36. shards fail during the request now return a 500 response instead of a 200
  37. response in the event there is at least one failure.
  38. ==== Delete by Query API requires an explicit query
  39. In previous versions of Elasticsearch, delete by query requests without an explicit query
  40. were accepted, match_all was used as the default query and all documents were deleted
  41. as a result. From version 6.0.0, delete by query requests require an explicit query.
  42. ==== DELETE document calls now implicitly create the type
  43. Running `DELETE index/type/id` now implicitly creates `type` with a default
  44. mapping if it did not exist yet.
  45. ==== Indices information APIs
  46. Previously it was possible to execute `GET /_aliases,_mappings` or `GET
  47. /myindex/_settings,_alias` by separating mulitple types of requests with commas
  48. in order to retrieve multiple types of information about one or more indices.
  49. This comma-separation for retrieving multiple pieces of information has been
  50. removed.. `GET /_all` can be used to retrieve all aliases, settings, and
  51. mappings for all indices. In order to retrieve only the mappings for an index,
  52. `GET /myindex/_mappings` (or `_aliases`, or `_settings`).
  53. ==== Requests to existing endpoints with incorrect HTTP verb now return 405 responses
  54. Issuing a request to an endpoint that exists, but with an incorrect HTTP verb
  55. (such as a `POST` request to `/myindex/_settings`) now returns an HTTP 405
  56. response instead of a 404. An `Allow` header is added to the 405 responses
  57. containing the allowed verbs. For example:
  58. [source,text]
  59. -------------------------------------------
  60. $ curl -v -XPOST 'localhost:9200/my_index/_settings'
  61. * Trying 127.0.0.1...
  62. * TCP_NODELAY set
  63. * Connected to localhost (127.0.0.1) port 9200 (#0)
  64. > POST /my_index/_settings HTTP/1.1
  65. > Host: localhost:9200
  66. > User-Agent: curl/7.51.0
  67. > Accept: */*
  68. >
  69. < HTTP/1.1 405 Method Not Allowed
  70. < Allow: PUT,GET
  71. < content-type: application/json; charset=UTF-8
  72. < content-length: 134
  73. <
  74. {
  75. "error" : "Incorrect HTTP method for uri [/my_index/_settings] and method [POST], allowed: [PUT, GET]",
  76. "status" : 405
  77. }
  78. * Curl_http_done: called premature == 0
  79. * Connection #0 to host localhost left intact
  80. --------------------------------------------
  81. ==== Disallow using `_cache` and `_cache_key`
  82. The `_cache` and `_cache_key` options in queries have been deprecated since version 2.0.0 and
  83. have been ignored since then, issuing a deprecation warning. These options have now been completely
  84. removed, so using them now will throw an error.
  85. ==== IndexClosedException to return 400 status code
  86. An `IndexClosedException` is returned whenever an api that doesn't support
  87. closed indices (e.g. search) is called passing closed indices as parameters
  88. and `ignore_unavailable` is set to `false`. The response status code returned
  89. in such case changed from `403` to `400`