History

Nik Everett 0c47d49784 Make sure non-collecting aggs include sub-aggs (backport of #64214 ) (#64247 ) Now that we're consistently using `cat_match` to filter which shards we run on we can get this confusing case: 1. You have a search with, say, a range and a sub-agg. 2. That search has a query that `can_match` can recognize will match no docs. On any shard. 3. So we dutifully run it on a single shard so it can produce the "empty" aggs. 4. The shard we pick happens to not have the target of the range mapped. 5. This kicks in the special range aggregator that doesn't collect any documents. 6. Before this commit, that range aggregator also never produced any sub-aggs. So, without this change, it was quite possible for a search that happened to match no documents to "throw away" the sub-aggs of a range and a few other aggs. We've had this problem for a long, long time but it is more confusing now because `can_match` is really kicking in and causing us to see cases where it looks like you are targeting a lot of shards but you really are only targeting a couple. It used to be that to get the "no sub-aggs" behavior you had to explicitly target only shards that didn't map the target field of the `range` agg. And, like, in that case it isn't too bad because you targeted a sort of degenerate shard. But now that `can_match` is doing its thing you can end up with the confusing steps above. It took me several hours to track down what what happening I know how the individual pieces of all of this works. It took four hours to figure out how they fit together in this case.... Anyway! This replaces all the aggregator implementations that throw out the sub-aggregators with ones that keep them. I think this'll be less confusing in the future. Closes #64142		2020-10-28 08:38:05 -04:00
..
src	Make sure non-collecting aggs include sub-aggs (backport of #64214 ) (#64247 )	2020-10-28 08:38:05 -04:00
.gitignore	Initial commit (blank repository)	2013-05-23 17:56:22 +02:00
README.markdown	[DOCS] Note doc links should be live in REST API JSON specs (#53871 )	2020-03-23 07:42:03 -04:00
build.gradle	Add support for missing value fetchers. (#63585 )	2020-10-12 17:34:21 -07:00
keywords.json	Update rest-api-spec keyword list	2020-06-25 09:55:13 +01:00

README.markdown

Elasticsearch REST API JSON specification

This repository contains a collection of JSON files which describe the Elasticsearch HTTP API.

Their purpose is to formalize and standardize the API, to facilitate development of libraries and integrations.

Example for the "Create Index" API:

{
  "indices.create": {
    "documentation":{
      "url":"https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-create-index.html"
    },
    "stability": "stable",
    "url":{
      "paths":[
        {
          "path":"/{index}",
          "method":"PUT",
          "parts":{
            "index":{
              "type":"string",
              "description":"The name of the index"
            }
          }
        }
      ]
    },
    "params": {
      "timeout": {
        "type" : "time",
        "description" : "Explicit operation timeout"
      }
    },
    "body": {
      "description" : "The configuration for the index (`settings` and `mappings`)"
    }
  }
}

The specification contains:

The name of the API (indices.create), which usually corresponds to the client calls
Link to the documentation at the http://elastic.co website.

IMPORANT: This should be a live link. Several downstream ES clients use this link to generate their documentation. Using a broken link or linking to yet-to-be-created doc pages can break the Elastic docs build.
stability indicating the state of the API, has to be declared explicitly or YAML tests will fail
- experimental highly likely to break in the near future (minor/path), no bwc guarantees. Possibly removed in the future.
- beta less likely to break or be removed but still reserve the right to do so
- stable No backwards breaking changes in a minor
Request URL: HTTP method, path and parts
Request parameters
Request body specification

NOTE If an API is stable but it response should be treated as an arbitrary map of key values please notate this as followed

{
  "api.name": {
    "stability" : "stable",
    "response": {
      "treat_json_as_key_value" : true
    }
  }
}

Backwards compatibility

The specification follows the same backward compatibility guarantees as Elasticsearch.

Within a Major, additions only.
If an item has been documented wrong it should be deprecated instead as removing these might break downstream clients.
Major version change, may deprecate pieces or simply remove them given enough deprecation time.

Deprecations

The specification schema allows to codify API deprecations, either for an entire API, or for specific parts of the API, such as paths or parameters.

Entire API:

{
  "api" : {
    "deprecated" : {
      "version" : "7.0.0",
      "description" : "Reason API is being deprecated"
    },
  }
}

Specific paths and their parts:

{
  "api": {
    "url": {
      "paths": [
        {
          "path":"/{index}/{type}/{id}/_create",
          "method":"PUT",
          "parts":{
            "id":{
              "type":"string",
              "description":"Document ID"
            },
            "index":{
              "type":"string",
              "description":"The name of the index"
            },
            "type":{
              "type":"string",
              "description":"The type of the document",
              "deprecated":true
            }
          },
          "deprecated":{
            "version":"7.0.0",
            "description":"Specifying types in urls has been deprecated"
          }
        }
      ]
    }
  }
}

Parameters

{
  "api": {
    "url": {
      "params": {
        "stored_fields": {
          "type": "list",
          "description" : "",
          "deprecated" : {
            "version" : "7.0.0",
            "description" : "Reason parameter is being deprecated"
          }
        }
      }
    }
  }
}

License

This software is licensed under the Apache License, version 2 ("ALv2").