Refactor `GET {index}` vs `GET {index}/_settings` etc

[clintongormley]

Today the RestGetIndicesAction registers:

    controller.registerHandler(GET, "/{index}", this);
    controller.registerHandler(GET, "/{index}/{type}", this);

... where {type} is zero or more of _aliases, _mappings, _settings, _warmers (which should be removed)

But then we have RestGetFieldMappingAction which registers:

    controller.registerHandler(GET, "/_mapping/field/{fields}", this);
    controller.registerHandler(GET, "/_mapping/{type}/field/{fields}", this);
    controller.registerHandler(GET, "/{index}/_mapping/field/{fields}", this);
    controller.registerHandler(GET, "/{index}/{type}/_mapping/field/{fields}", this);
    controller.registerHandler(GET, "/{index}/_mapping/{type}/field/{fields}", this);

and RestGetSettingsAction which registers:

    controller.registerHandler(GET, "/{index}/_settings/{name}", this);
    controller.registerHandler(GET, "/_settings/{name}", this);
    controller.registerHandler(GET, "/{index}/_setting/{name}", this);

and the deprecated RestGetIndicesAliasesAction which registers:

    controller.registerHandler(GET, "/{index}/_aliases/{name}", this);
    controller.registerHandler(GET, "/_aliases/{name}", this);

This makes for some confusion eg you'd expect GET index/_settings to be handled by RestGetSettingsAction but actually you have to specify eg GET index/_settings/* in order to force that code path.

Can we refactor this to simplify the code?

• RestGetIndicesAliasesAction is already deprecated.
• I'm not sure that GET {index}/_settings/{name} really needs to be supported. I think we can get rid of it in master.
• The GET index/type/_mapping order has been deprecated since 1.0 in favour of GET index/_mapping/type, which just leaves handling the GET _mapping/field structure

[dadoonet]

See also #13906 which is about removing GET aliases

[pojans]

Hello! I'm representing a group from KTH trying to solve this issue. We're kind of stuck and need some guidance. Is there anybody who would be willing to look into this with us and provide a little help?

Thank you in advance.

[dackebro]

Hi, in the last item listed it says "which just leaves handling the GET _mapping/field structure". We interpret these as connected to the three lines

controller.registerHandler(GET, "/_mapping/field/{fields}", this);
controller.registerHandler(GET, "/_mapping/{type}/field/{fields}", this);
controller.registerHandler(GET, "/{index}/_mapping/field/{fields}", this);

We feel like they fill a function, and this makes us unsure about whether anything shuold be done about these, and if so, what should be kept and what should be deprecated?

[javanna]

Hi @spojan & @dackebro , I did some digging and I am not too sure what is left to be done here.

Most of this issue has been tackled with #24723, in fact RestGetIndicesAction doesn't parse "features" anymore, and no longer registers the /{index}/{type} endpoint.

We now also have RestGetAllSettingsAction that registers /_settings, RestGetAllMappingsAction that registers /_mappings and RestGetAllAliasesAction that registers /_aliases.

RestGetSettingsAction registers {index}/_settings/{name} where {name} is a way to filter settings that will be returned. I am not sure that we want to remove this.

Last but not least, we still support index/type/_mapping while index/_mapping/type should be preferred, and that is true for RestGetMappingAction and RestGetFieldMappingAction, but also for `RestPutMappingAction. Maybe we should open an issue for this last change only? What do you think @clintongormley ?

[clintongormley]

@javanna that last change will be taken care of by #15613, so I think we can close this issue.

@spojan and @dackebro thanks for taking a look - we'd welcome your contributions on another open ticket.