通过使用index API，文档可以被 索引——存储和使文档可被搜索。但是首先，我们要确定文档的位置。正如我们刚刚讨论的，一个文档的_index、_type和 _id 唯一标识一个文档。我们可以提供自定义的 _id 值，或者让 index API 自动生成。

使用自定义的ID

如果你的文档有一个自然的标识符（例如，一个user_account 字段或其他标识文档的值），你应该使用如下方式的index API 并 提供你自己的 _id：

  1. PUT /{index}/{type}/{id}
  2. {
  3.   "field": "value",
  4.   ...
  5. }

举个例子，如果我们的索引成为website，类型称为blog，并且选择123作为ID，那么索引请求应该是下面这样：

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "Just trying this out...",
  "date":  "2014/01/01"
}

Elasticsearch 响应体如下所示：

{
   "_index":    "website",
   "_type":     "blog",
   "_id":       "123",
   "_version":  1,
   "created":   true
}

该响应表示文档已经成功创建，该索引包括_index、_type和_id 元数据，以及一个新元素：_version。

在Elasticsearch中每个文档都有一个版本号。当每次对文档进行修改时（包括删除），_version 的值会递增。在处理冲突 中，我们讨论了怎样使用 _version 号码确保你的应用程序中的一部分修改不会覆盖另一部分所做的修改。

Autogenerating IDs

如果你的数据没有自然ID，Elasticsearch可以帮我们自动生成ID。请求的结构调整为：不再使用PUT 谓词（“使用这个URL 存储这个文档”），而是使用POST 谓词（“存储文档在这个URL 命名空间下”）。

现在该URL只需包含_index 和 _type:

POST /website/blog/
{
  "title": "My second blog entry",
  "text":  "Still trying this out...",
  "date":  "2014/01/01"
}

除了 _id 是ELasticsearch自动生成的，响应的其他部分和前面的类似：

{
   "_index":    "website",
   "_type":     "blog",
   "_id":       "AVFgSgVHUP18jI2wRx0w",
   "_version":  1,
   "created":   true
}

自动生成的ID是URL-safe、基于Base64编码且长度为20个字符的GUID字符串。这些GUID字符串由可修改的FlakeID模式生成，这种模式运行多个节点并行生成唯一ID，且互相之间的冲突概率几乎为零。