无需枚举对象的批量POST请求：无ID时批量修改对象的方案咨询

原设计存在的核心问题 #

• 语义不规范：路径中携带modify这类动作动词不符合REST API的设计惯例，且将过滤条件放在查询参数中，一旦出现参数拼写错误、权限校验漏判的情况，极易导致误修改全量数据
• 能力局限性：仅支持单条件过滤，无法应对多字段组合过滤、范围匹配、枚举值匹配等复杂批量筛选场景
• 安全性不足：没有显式的操作确认机制，请求一旦发出就会立即执行修改，没有回退兜底的空间
• 可观测性差：无法从请求日志中直观看到本次批量操作的筛选范围、修改内容，后续排查问题难度高

推荐实现方案 #

方案1：标准REST风格批量更新（适用于中小规模批量操作） #

请求路径统一用POST /objects/batch，把筛选条件、修改内容都放到请求体里，示例请求结构如下：

{
  "filter": {
    "name": "foo",
    "status": "active",
    "create_time": {"$lt": "2024-01-01T00:00:00Z"}
  },
  "update": {
    "status": "inactive",
    "desc": "批量过期"
  },
  "options": {
    "dry_run": false,
    "return_modified_count": true
  }
}

该方案的优势：

• 过滤条件支持任意复杂组合，不受查询参数长度限制
• 内置dry_run（试运行）参数，开启时只会返回符合条件的对象数量，不会实际执行修改，方便用户提前确认操作范围
• 所有操作参数都存在请求体中，日志审计、问题排查都更方便
• 可以灵活添加限流、最大修改数量限制等控制逻辑，比如后台限制单次批量修改最多1000条，超过就拒绝请求避免误操作

方案2：异步批量操作（适用于超大规模数据修改） #

如果单次操作可能修改上万甚至更多数据，同步请求容易超时，可选用异步方案：

1. 第一步先提交批量修改任务：POST /objects/batch/jobs，请求体结构和方案1一致
2. 接口立即返回任务ID：{"job_id": "xxx-123"}
3. 客户端可以通过GET /objects/batch/jobs/xxx-123查询任务执行进度、修改成功/失败数量
4. 任务执行完成后可以返回修改失败的对象ID列表、错误原因等明细

额外安全建议 #

• 所有批量修改接口必须加操作权限校验，区分单条更新和批量更新的权限
• 可以配置高危操作二次校验，比如修改范围超过100条时需要额外传入操作验证码或者管理员确认标识
• 必须记录批量操作的全量日志，包括操作人、筛选条件、修改内容、修改条数、操作时间，方便追溯

内容的提问来源于stack exchange，提问作者Badredine Kheddaoui