Question

假设我有一个嵌套的资源如下：

resources :authors do
  resources :books
end

鉴于我已将Devise连接到我的API以验证用户身份。

假设一位作者对自己进行身份验证，我应该提供/books等路线，还是应该坚持/authors/:author_id/books路线？

我的逻辑背后是，因为我可以确定谁登录，提供/books是有道理的，/authors/:author_id/books似乎有点矫枉过正，更适合管理员的api ......

对于最好（更具可持续性）的方法，有人可以解释一下吗？

Answer 1

如果您要使用/ books，那么您只能使用rails中的许多功能，并且必须编写额外的代码才能从作者中提取数据。

我喜欢作者 / authors /：author_id / books 方法，因为您可以控制author_id参数。假设您使用的是诸如friendly_id之类的宝石，那么您的网址将类似于 / authors / jsmith ，并且在jsmith页面上您可以在此处列出他的图书而无需 /作者/ JSMITH /书籍

如果您正在使用设计，请通过在索引操作中调用current_user方法并在控制器创建操作而不是表单隐藏字段中设置current_user id来保护每个用户页面。使用cancan进行授权。

Answer 2

我个人更喜欢/books方式。我的论点：

在这种情况下，控制器中的逻辑将是这样的：
```
books = current_author.books.all()
```
它完全拯救了你想要访问私人信息的任何邪恶用户（因为在这种情况下，访问书籍的唯一途径是作为作者登录 - 所以安全集中在一个地方）
在/books部分
因为/ books路由没有用户ID，它预测用户在url中替换用户ID。有些人喜欢这样做，看看会发生什么。而且我认为你不希望他们这样做

所以我的投票是/books

Answer 3

我更喜欢为我的API进行版本控制，并在需要的地方使用嵌套。例如，如果书籍始终作用于author_id，那么它应该是嵌套的，否则它不应该嵌套。

版本化路线如下：

`/api/v1/books/:id`

BooksController位于/controllers/api/v1下的地图中，其类声明如下：

module Api::V1
  class BooksController < ApplicationController
  end
end

和routes.rb看起来像

MyApplication::Application.routes.draw do


  namespace :api do
    namespace :v1 do
      resources :authors
      resources :books
    end
  end

end

版本控制很适合API的客户端实现。您可以在不破坏支持的情况下添加新功能和重构。

使用rails的嵌套资源的RESTful api路由

3 个答案: