History

Adrien Grand b72f27a410 Core: Cut over to the Lucene filter cache. This removes Elasticsearch's filter cache and uses Lucene's instead. It has some implications: - custom cache keys (`_cache_key`) are unsupported - decisions are made internally and can't be overridden by users ('_cache`) - not only filters can be cached but also all queries that do not need scores - parent/child queries can now be cached, however cached entries are only valid for the current top-level reader so in practice it will likely only be used on read-only indices - the cache deduplicates filters, which plays nicer with large keys (eg. `terms`) - better stats: we already had ram usage and evictions, but now also hit count, miss count, lookup count, number of cached doc id sets and current number of doc id sets in the cache - dynamically changing the filter cache size is not supported anymore Internally, an important change is that it removes the NoCacheFilter infrastructure in favour of making Query.rewrite specializing the query for the current reader so that it will only be cached on this reader (look for IndexCacheableQuery). Note that consuming filters with the query API (createWeight/scorer) instead of the filter API (getDocIdSet) is important for parent/child queries because otherwise a QueryWrapperFilter(ParentQuery) would run the wrapped query per segment while relations might be cross segments.		2015-05-04 09:02:15 +02:00
..
api	Core: Cut over to the Lucene filter cache.	2015-05-04 09:02:15 +02:00
test	Remove core delete-by-query implementation, to be replaced with a plugin	2015-04-28 16:09:04 -04:00
.gitignore	Initial commit (blank repository)	2013-05-23 17:56:22 +02:00
LICENSE.txt	Updated copyright years to include 2015	2015-02-28 03:18:45 +01:00
README.markdown	[API] changed all the links in json specs to the new site	2015-03-24 17:30:32 +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": "http://www.elastic.co/guide/en/elasticsearch/reference/master/indices-create-index.html",
    "methods": ["PUT", "POST"],
    "url": {
      "path": "/{index}",
      "paths": ["/{index}"],
      "parts": {
        "index": {
          "type" : "string",
          "required" : true,
          "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 http://elastic.co
List of HTTP methods for the endpoint
URL specification: path, parts, parameters
Whether body is allowed for the endpoint or not and its description

The methods and url.paths elements list all possible HTTP methods and URLs for the endpoint; it is the responsibility of the developer to use this information for a sensible API on the target platform.

Utilities

The repository contains some utilities in the utils directory:

The thor api:generate:spec will generate the basic JSON specification from Java source code
The thor api:generate:code generates Ruby source code and tests from the specs, and can be extended to generate assets in another programming language

Run bundle install and then thor list in the utils folder.

The full command to generate the api spec is:

thor api:spec:generate --output=myfolder --elasticsearch=/path/to/es

License

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