将待删除对象ID放入URL查询参数是否为不良开发实践？

你的这种写法lectures/remove?id=${lecture._id}不算错误，但不符合RESTful API的设计规范，属于不够优雅的实现方式。下面具体说路径参数和查询参数的区别，以及更优的传参方案：

路径参数 vs 查询参数的核心区别 #

• 语义精准度：路径参数的作用是定位唯一资源，比如DELETE /lectures/${lecture._id}，从端点就能直接读懂“要删除ID为xxx的lecture资源”；而查询参数更多用于筛选一批符合条件的资源，用?id=xxx传递删除目标，语义上更偏向“删除所有满足id=xxx条件的资源”，虽然实际效果一样，但对API的可读性和一致性有影响。
• API一致性：REST风格的API遵循“资源为核心”的原则，单个资源的CRUD通常是：
  • 获取：GET /lectures/${id}
  • 更新：PUT /lectures/${id}
  • 删除：DELETE /lectures/${id}
    这种统一的结构能让其他开发者快速理解API意图，不需要额外记忆/remove这类自定义后缀。
• 路由维护成本：用路径参数可以通过/lectures/:id这样的通配路由，统一处理单个资源的各类操作；而/lectures/remove需要单独配置一条路由，增加了冗余的维护成本。

更优的DELETE传参方案 #

1. 单个资源删除：优先用路径参数，端点设计为DELETE /lectures/${lecture._id}，完全不需要/remove后缀——HTTP的DELETE方法已经明确了操作类型，后缀属于多余的语义重复。
2. 批量资源删除：如果需要删除多个资源，不建议用DELETE /lectures?id=1&id=2这种多查询参数的方式（语义模糊），也尽量避免用DELETE请求带RequestBody（虽然HTTP标准没禁止，但很多客户端、代理或框架对DELETE的Body支持不佳）。可以考虑两种方案：
   • 用路径参数传递多个ID，比如DELETE /lectures/1,2,3，后端解析逗号分隔的ID列表；
   • 如果批量删除逻辑复杂（比如带筛选条件），可以用POST请求（比如POST /lectures/batch-delete），通过Body传递筛选规则，这种方式更清晰且兼容性更好。

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