2

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

resources :authors do
  resources :books
end

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

假设作者对自己进行了身份验证，我应该提供诸如此类的路线/books还是应该坚持/authors/:author_id/books路线？

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

有人可以阐明什么是最好的（更可持续的）方法吗？

4

3 回答 3

3

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

我喜欢作者/authors/:author_id/books方法，因为您可以控制 author_id 参数。假设您要使用诸如friendly_id之类的宝石，那么您的网址将类似于/authors/jsmith，而在jsmith 页面上，您可以在其中列出他的书籍而无需转到/authors/jsmith/books

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

于 2013-05-24T14:44:59.100 回答
1

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

  1. 在这种情况下，您的控制器中的逻辑将是这样的：

    books = current_author.books.all()

    并且它完全可以让您免受任何想要访问私人信息的邪恶用户的伤害（因为在这种情况下，访问书籍的唯一方法是以作者身份登录 - 所以安全性集中在一个地方）

  2. /books作者在章节中列出他的书籍清单会更舒服

  3. 因为 /books 路由中没有用户 ID，它是预测用户替换 url 中的用户 ID。有些人喜欢这样做，看看会发生什么。我认为你不希望他们这样做

所以我的投票是/books

于 2013-05-24T14:18:01.303 回答
1

我更喜欢对我的 API 进行版本控制，并在需要的地方使用嵌套。例如，如果书籍总是以 a 为范围，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 的客户端实现。您可以在不破坏支持的情况下添加新功能和重构。

于 2013-05-24T15:19:21.590 回答