接收资源ID列表的API端点遇无效ID时应如何返回响应

• 仅返回命中的4个产品资源：完全不可行。前端拿到返回结果后，根本无法区分是请求时只传了4个有效ID，还是传了5个ID但缺失1个，完全没法满足“感知是否全部ID查询成功”的核心需求，直接排除。
• 返回命中资源+requestedCount、returnedCount统计字段：部分可行，但信息不足。前端确实可以通过两个字段数值是否相等，快速判断是否全量命中，满足当前最基础的判断需求，但拿不到具体缺失的是哪个ID，后续要做错误提示、缺失资源补查、问题埋点的时候，还得前端自己拿传入ID和返回资源ID做差集，既增加前端计算量，也容易因为两边ID类型不一致（比如服务端返回数字、前端传的时候转成字符串）出判断bug。
• 直接返回对应HTTP状态码的错误响应：可行性极低，不推荐。首先HTTP状态码语义不匹配：传入ID格式完全合规，请求本身没有格式错误、权限问题，用400（参数错误）、404（资源不存在）都不准确；其次一旦返回错误，已经查询到的4条有效资源会被全部丢弃，既浪费数据库查询性能，也完全不兼容后续可能的“展示可访问的部分商品”类业务需求，灵活性极差。除非业务规则强制要求“批量查询时只要有一个ID不存在，整个请求直接判定失败”，否则不要选这个方案。

接口统一返回200 OK状态码（请求被服务端正常接收、正常处理完成，符合状态码语义），响应体包含三类字段，兼顾当前需求和后续扩展性：

1. 统计字段：保留requestedCount（传入的待查询ID总数）、returnedCount（实际命中的资源数量），前端一行判断就能知道是不是全量命中，满足现在“全量成功才展示列表”的需求。
2. 资源列表字段：比如命名为items，存放所有查询命中的产品资源数据，和原有返回逻辑兼容。
3. 缺失ID字段：命名为missingIds，值为数组类型，存放所有未查询到对应记录的ID（比如示例场景下值为[4]）。

响应示例参考：

{
  "requestedCount": 5,
  "returnedCount": 4,
  "missingIds": [4],
  "items": [
    {"id": 1, "name": "产品1", "price": 99},
    {"id": 2, "name": "产品2", "price": 199},
    {"id": 3, "name": "产品3", "price": 299},
    {"id": 5, "name": "产品5", "price": 499}
  ]
}

这个方案的优势很明确：

• 前端逻辑简单：判断全量命中不用自己做ID差集，直接对比两个统计字段即可，需要做错误提示的时候直接读missingIds就能拿到具体缺失的ID，不用额外计算。
• 兼容性强：后续如果业务调整为允许展示部分命中的产品，接口结构完全不用改，直接读取items渲染即可。
• 没有性能浪费：已经查到的有效数据正常返回，不会因为部分资源缺失就丢弃全部结果。

如果团队内部有强依赖HTTP状态码做批量操作状态标识的规范，也可以在部分资源缺失时返回207 Multi-Status状态码，但普通Web业务场景下更推荐统一返回200，避免前端全局HTTP错误拦截器把这类部分成功的响应当成异常拦截，导致拿不到响应体数据。

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