delete API允许根据特定索引的id从索引中删除JSON文档。下面的示例将从id为1的名为twitter的索引中删除JSON文档:

DELETE /twitter/_doc/1

上述删除操作的结果为:

{
    "_shards" : {
        "total" : 2,
        "failed" : 0,
        "successful" : 2
    },
    "_index" : "twitter",
    "_type" : "_doc",
    "_id" : "1",
    "_version" : 2,
    "_primary_term": 1,
    "_seq_no": 5,
    "result": "deleted"
}

乐观并发控制

Delete操作可以是有条件的，并且只有在为文档的最后修改分配了由if_seq_no和if_primary_term参数指定的序列号和主项时才可以执行。如果检测到不匹配，该操作将导致versionconflict texception和状态代码409。有关详细信息，请参阅乐观并发控制。

版本控制

索引的每个文档都有版本。在删除文档时，可以指定版本，以确保我们试图删除的相关文档实际上是被删除的，同时它没有更改。在文档上执行的每个写操作(包括删除操作)都会使其版本增加。删除后的文档的版本号在短时间内保持可用，以便控制并发操作。已删除文档的版本可用的时间长度由索引决定index.gc_deletes，默认值为60秒。

路由

当索引使用控制路由的能力时，为了删除文档，还应该提供路由值。例如:

DELETE /twitter/_doc/1?routing=kimchy

上面将根据用户路由删除id为1的tweet。注意，在没有正确路由的情况下发出delete将导致文档不被删除。

当_routing映射按需要设置，且没有指定路由值时，delete API将抛出RoutingMissingException并拒绝请求。

自动创建索引

如果使用外部版本控制变体，如果之前没有创建索引，delete操作将自动创建索引(查看create index API，以手动创建索引)。

分布式

delete操作被散列到一个特定的分片id中，然后被重定向到该id组中的主分片中，并被复制(如果需要的话)到该id组中的分片副本中。

等待活动碎片

在发出删除请求时，可以设置wait_for_active_shards参数，以要求在开始处理删除请求之前激活最少数量的碎片副本。有关详细信息和使用示例，请参见此处。

刷新

控制何时可以搜索到此请求所做的更改。

超时

在执行删除操作时，分配给执行删除操作的主碎片可能不可用。其中的一些原因可能是主碎片目前正在从存储中恢复或正在进行重新定位。默认情况下，delete操作将等待主碎片可用最多1分钟，然后失败并响应错误。可以使用timeout参数显式地指定它等待的时间。下面是一个设置为5分钟的例子:

DELETE /twitter/_doc/1?timeout=5m