Add GET /index API

[clintongormley]

While we have the index exists API:

HEAD /index

and we have:

GET /index/_aliases
GET /index/_mapping
GET /index/_settings
GET /index/_warmer

We don't have a GET /index API which would return all info about the index (ie aliases, settings, mappings, warmers) which could be used to recreate the index with a different name or on a different cluster.

[spinscale]

Hey,

implementation for this is not too complex (see my commit), however, do you think it makes sense, if warmers and aliases could also directly be added when creating an index, so one could pipe this into a create index call?

This is the current output

» curl 'localhost:9200/test?pretty'
{
  "settings" : {
    "index.tests.seed" : "-429205130377286056",
    "index.compound_format" : "0.9941336967222938",
    "index.merge.policy.type" : "org.elasticsearch.index.merge.policy.LogDocMergePolicyProvider",
    "index.number_of_replicas" : "5",
    "index.number_of_shards" : "10",
    "index.version.created" : "1000002",
    "index.uuid" : "d70IIOiGQLiFdau4ZBVifw",
    "index.refresh_interval" : "10s"
  },
  "mappings" : {
    "test" : {
      "properties" : {
        "message" : {
          "type" : "string",
          "store" : true
        }
      }
    }
  },
  "aliases" : {
    "thetest" : { }
  },
  "warmers" : {
    "warmer_1" : {
      "types" : [ ],
      "source" : {
        "query" : {
          "match_all" : { }
        }
      }
    }
  }
}

[dakrone]

@spinscale +1, I personally vote for keeping the warmers and aliases in, just to get all the information.

[clintongormley]

@spinscale Nice - I didn't see this commit. Warmers can already be added in the create index API, but you're right, aliases can't be. I think it would be nice to support this too.

Also see #4140

Bumping this issue to 1.0.1

[clintongormley]

Also see #4614

[clintongormley]

Copied comment over from #4614

With the removal of _aliases (#4539) we've lost an endpoint for efficiently listing available indices & aliases, which Kibana relies on for computing timestamped indices.

It would be nice to have an _indices endpoint that could efficiently return a list of indices with a configurable amount of additional granularity, eg mappings, settings, aliases.

Bonus points if we could support wildcard matching here for both index and alias names, eg

** Every index name **

/_indices

** Every index with its aliases and settings **

/_indices?aliases

** Every index named mydata-* or with an alias matching mydata-, along with its mapping *

/mydata-*/_indices?mapping