include_type_name supports in indices.exists API for 6.7.0

[ezimuel]

The parameter include_type_name is not included in indices.exists API for 6.7.0.
I tested and this endpoint supports this parameter as reported also in this issue for elastic/elasticsearch-perl.

Interesting, using Elasticsearch 6.8 even without the usage of include_type_name the [DEPRECATION] warning disappear thanks to #43905 (comment).

From the rest-api-spec the include_type_name parameter is reported only in these endpoints:

indices.create.json
indices.get_field_mapping.json
indices.get.json
indices.get_mapping.json
indices.get_template.json
indices.put_mapping.json
indices.put_template.json
indices.rollover.json

I'm wondering if there are other APIs like indices.exists that also support it but they are not reported in the specification.

Let me know so I can create a PR to add the indices.exists in 6.7 branch and eventually in other spec.

Thanks!

[elasticmachine]

Pinging @elastic/es-search (:Search/Mapping)

[cbuescher]

Hi @ezimuel,
thanks for raising the issue. As far as I re-read the issues you pointed to above, we decided that indices.exists does not need to support the include_type_name since its response body is empty. This is why we opted for removing the deprecation warning starting with 6.8 instead (as you mentioned in #43905).
I'm not sure what we can do on 6.7 since this is a branch we don't release from any more. If it helps you on the client side if the parameter is mentioned in the rest-spec then I think you can open a PR against 6.7 but it won't land in any release afaik.

[ezimuel]

@cbuescher thanks, do you confirm that include_type_name is only available in the mentioned endpoints?

Even if we don't release 6.7 anymore I can send a PR to update the API specification, since include_type_nameis supported in indices.exists for 6.7. This can be relevant for folks using the API specification for generating code (as I did) or for refence.

[cbuescher]

do you confirm that include_type_name is only available in the mentioned endpoints?

Yes, those eight endpoint should be the only ones that support this parameter. I just checked the code on 7.x again and could map each of these APIs to a Rest*Action that evaluates the parameter at some point. I didn't check for older 7.x versions or 6.x but this should largely cover it:

API	param usage ( as of 7.x, be30901)
indices.create.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestCreateIndexAction.javaL64
indices.get_field_mapping.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestGetFieldMappingAction.javaL81
indices.get.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestGetIndicesAction.javaL75
indices.get_mapping.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestGetMappingAction.javaL97
indices.get_template.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestGetIndexTemplateAction.javaL77
indices.put_mapping.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestPutMappingAction.javaL81
indices.put_template.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestPutIndexTemplateAction.javaL68
indices.rollover.json	server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestRolloverIndexAction.javaL60

Even if we don't release 6.7 anymore ... This can be relevant for folks using the API specification for generating code (as I did) or for refence.

If it helps we can add it to the branch, sure.

[javanna]

Nothing left to do here. Closing.