REST API设计问题：复杂查询实现与关联统计字段暴露方案咨询

问题1：复杂过滤查询的实现方案 #

• 首先明确：使用POST实现复杂查询不违反REST规范。REST核心约束是无状态、资源可识别、统一接口，并没有强制要求所有查询类请求必须使用GET。GET请求的query参数存在长度限制（多数服务端、代理默认支持2~8KB），多层嵌套过滤、大数组参数、长匹配规则等场景确实不适合用GET传递参数。
• 行业通用的最优方案就是暴露POST /api/A/search接口：你可以将复杂过滤规则放在请求体中提交，将「搜索结果集合」作为返回的资源，完全符合REST语义。
• 如果你想更严格对齐HTTP方法的幂等性要求，也可以选择两种替代方案，但综合性价比远低于search接口方案：
  1. 将过滤参数序列化后做Base64编码，放在GET的单个query参数中传递，缺点是可读性差、调试成本高
  2. 先调用POST /api/A/filter提交过滤规则，服务端返回唯一filter_id，再调用GET /api/A?filter_id=xxx获取结果，缺点是多一次请求，还需要维护filter_id的过期、清理逻辑，复杂度高。

问题2：关联实体计数的暴露方案 #

三种符合REST规范的实现方式，可根据业务场景选择：

1. 默认返回扩展字段：直接在A资源的列表返回结构中新增b_count、c_count字段作为内置扩展属性，适合计数是A列表的高频必备字段的场景。如果存在不需要计数的使用场景，可以增加fields查询参数控制返回字段，例：GET /api/A?fields=id,name,b_count
2. 动态嵌入参数控制：新增embed查询参数，由调用方指定需要返回的关联数据，例：GET /api/A?embed=b.count,c.count，服务端根据参数动态拼接返回计数，灵活性更高，适合多场景复用A列表接口的情况。
3. 独立批量计数接口：新增POST /api/A/batch-count接口，传入A的ID数组，返回对应每个ID的B、C关联计数，前端拿到A列表后再二次调用接口拼接数据，适合计数是低频使用属性的场景，避免主接口返回冗余数据。

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