Indices APIsedit

The mapping, alias, settings, and warmer index APIs are all similar but there are subtle differences in the order of the URL and the response body. For instance, adding a mapping and a warmer look slightly different:

PUT /{index}/{type}/_mapping
PUT /{index}/_warmer/{name}

These URLs have been unified as:

PUT /{indices}/_mapping/{type}
PUT /{indices}/_alias/{name}
PUT /{indices}/_warmer/{name}

GET /{indices}/_mapping/{types}
GET /{indices}/_alias/{names}
GET /{indices}/_settings/{names}
GET /{indices}/_warmer/{names}

DELETE /{indices}/_mapping/{types}
DELETE /{indices}/_alias/{names}
DELETE /{indices}/_warmer/{names}

All of the {indices}, {types} and {names} parameters can be replaced by:

  • _all, * or blank (ie left out altogether), all of which mean “all”
  • wildcards like test*
  • comma-separated lists: index_1,test_*

The only exception is DELETE which doesn’t accept blank (missing) parameters. If you want to delete something, you should be specific.

Similarly, the return values for GET have been unified with the following rules:

  • Only return values that exist. If you try to GET a mapping which doesn’t exist, then the result will be an empty object: {}. We no longer throw a 404 if the requested mapping/warmer/alias/setting doesn’t exist.
  • The response format always has the index name, then the section, then the element name, for instance:

    {
        "my_index": {
            "mappings": {
                "my_type": {...}
            }
        }
    }

    This is a breaking change for the get_mapping API.

In the future we will also provide plural versions to allow putting multiple mappings etc in a single request.

See put-mapping, get-mapping, get-field-mapping, delete-mapping, update-settings, get-settings, warmers, and aliases for more details.