Previous versions of Elasticsearch ignored unrecognized URL query
string parameters. This means that extraneous parameters or parameters
containing typographical errors would be silently accepted by
Elasticsearch. This is dangerous from an end-user perspective because it
means a submitted request will silently execute not as intended. This
leniency has been removed and Elasticsearch will now fail any request
that contains unrecognized query string parameters.

The endpoint for checking whether a type exists has been changed from
{index}/{type} to {index}/_mapping/{type} in order to prepare for the
removal of types when HEAD {index}/{id} will be used to check whether a
document exists in an index. The old endpoint will keep working until 6.0.

The client, master_only, data_only and master_data fields have been
removed in favor of master, data, ingest and coordinating_only. A
node can contribute to multiple counts as it can have multiple roles. Every
node is implicitly a coordinating node, so whenever a node has no explicit
roles, it will be counted as coordinating only.

Node roles are now returned in a specific section, called roles, as part of
nodes stats and nodes info response. The new section is an array that holds all
the different roles that each node fulfills. In case the array is returned
empty, that means that the node is a coordinating only node.

Previously, JSON documents were allowed with unquoted field names, which isn’t
strictly JSON and broke some Elasticsearch clients. If documents were already
indexed with unquoted fields in a previous version of Elasticsearch, some
operations may throw errors. To accompany this, a commented out JVM option has
been added to the jvm.options file:
-Delasticsearch.json.allow_unquoted_field_names.

Note that this option is provided solely for migration purposes and will be
removed in Elasticsearch 6.0.0.

wait_for_relocating_shards is now wait_for_no_relocating_shards in /_cluster/healthedit

The wait_for_relocating_shards parameter that used to take a number is now simply a boolean
flag wait_for_no_relocating_shards, which if set to true, means the request will wait (up
until the configured timeout) for the cluster to have no shard relocations before returning.
Defaults to false, which means the operation will not wait.