Rails使用默认RESTful路由实现批量删除的方案是否符合规范

结论 #

你当前的实现完全符合RESTful规范，也没有明显的设计缺陷，是Rails生态下处理集合级批量操作的推荐方案之一。

合理性说明 #

1. 符合REST设计核心逻辑：REST的本质是将所有操作抽象为对「资源」的HTTP动词调用，你将「某用户的所有token集合」作为一个独立的单数资源来处理，用DELETE动词执行销毁操作，完全贴合REST的设计理念，不属于hack实现。
2. 贴合Rails路由约定：

• 相比自定义match '/apples/all', to: 'apples#destroy_all', via: :delete这类写法，用原生的单数resource生成路由完全遵循Rails的REST路由约定，不需要额外的路由规则配置，可读性和可维护性更高。
• 自动生成标准的路由辅助方法，你无需硬编码接口路径，在视图或业务逻辑中直接调用辅助方法即可生成对应请求路径。
• 批量操作的逻辑和单条资源的CRUD逻辑拆分到不同控制器，符合单一职责原则，避免主控制器（比如TokensController）堆积太多非标准动作。

可优化点 #

你实际的token吊销场景可以将路由定义调整为嵌套结构，层级更清晰：

# routes.rb
resources :users do
  resources :tokens, only: [:index, :show, :create, :destroy] do
    resource :all, only: :destroy, controller: 'all_tokens'
  end
end

上述配置会自动生成你需要的DELETE /users/:user_id/tokens/all路由，和你现有效果完全一致，更直观体现出「all是tokens资源下的子资源」的层级关系。

另外需要注意两个潜在的小问题：

• 做好权限校验：在AllTokensController#destroy中必须校验当前操作者有权限处理目标用户的token，避免直接通过params[:user_id]查询用户就执行删除操作造成越权。
• 大数据量场景的回调处理：如果你的token销毁有依赖Active Record回调的业务逻辑（比如吊销日志上报、用户下线通知等），不要直接用delete_all，改用find_each(&:destroy)分批处理，或者引入异步任务处理，避免请求阻塞和回调丢失。

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