elasticsearch - 编写REST API的PUT端点的最佳实践

Question

我正在构建具有某些业务逻辑的基本CRUD服务，并且我将开始在PUT(更新)端点上工作。我已经为我的数据对象完全编写并测试了GET(读取)和POST(创建)。我的文档的数据存储是AWS上的ElasticSearch实例。

关于如何构造PUT，我有一些决定，即如何确定有效请求。我的目标是做到这一点，以便POST仅创建新 Assets 的为，而PUT仅更新现有文档的为。 (目前，我在POST中使用/_doc/进行 flex 处理，但是作为此工作的一部分，目的是移至/_create/)

我有点卡在嘴边的是在对Elastic进行API调用以进行更新之前检查文档是否存在的“正确”方法。

当用户向PUT提交文档时，我是否应该首先从Elastic上使用带有文档ID的GET来确保文档已经存在？还是我应该简单地尝试“更新”资源，如果资源不存在，就会创建一个？

显然，每种策略都需要权衡取舍。对于后者，对不存在的文档进行PUT几乎完全消除了对POST的需求，因此，我将更倾向于使用前者-尽管进行了额外的REST调用-以保持基本的完整性。 REST定义。

有什么想法吗？

Answer 1

是否要更新文档(带有版本控制)或创建具有与所有先前版本相关的共享ID的新文档的考虑取决于您的用例-它们中的任何一个都是“正确的”，但是目前尚无足够的信息来建议。

关于文档存在策略-ES中本质上有两种ID类型-我称之为:

内部ID( _id )

外部ID( doc_values 提供的ID)

创建索引和文档:

PUT myindex

PUT myindex/_doc/internal_id_1
{
  "external_id": "1"
}

内部ID检查

GET myindex/_doc/internal_id_1

要么

GET myindex/_count
{
  "query": {
    "ids": {
      "values": [
        "internal_id_1"
      ]
    }
  }
}

要么

GET myindex/_count
{
  "query": {
    "term": {      
      "_id": {
        "value": "internal_id_1"
      }
    }
  }
}

外部ID检查

GET myindex/_count
{
  "query": {
    "term": {
      "external_id": {
        "value": "1"
      }
    }
  }
}

和许多其他( terms， match(用于部分匹配等)，...)

请注意，我使用的是 _count端点而不是 _search-速度稍快。

如果打算在继续更新之前检查给定文档的 _version，请用 _count替换 _search?version=true，并且 _version属性将变为可用:

{
  "_index":"myindex",
  "_type":"_doc",
  "_id":"internal_id_1",
  "_version":2,             <---
  "_score":1.0,
  "_source":{
    "external_id":"1"
  }
}