【问题标题】:RESTful vs custom page flow, what's the right approach?RESTful vs 自定义页面流,正确的方法是什么?
【发布时间】:2011-09-13 17:10:12
【问题描述】:

新手问题,请放轻松:)

我一直在努力协调根据 RESTful 模型设计系统实体的概念,并以一种对我和客户都合乎逻辑且有意义的方式实际组织我的网站流程。举个例子吧:

假设我正在实现一个用于在现实生活中分享电影的网站。你有一个电影模型,你有一个用户模型(加入了一些 auth / authz)。我想将电影视为 REST 资源并让用户浏览它们会非常简单,然后您可以拥有一系列代表所有权、借用和借出的关系(联合表)。到目前为止一切顺利。

现在,任何网站都会有一个用户仪表板的概念,您可以在其中查看用户的当前完整状态以及与他相关的信息。仪表板是否也是某种 REST 资源?我想这不可能,因为它确实对每个单独的用户都非常具体。那我把它放在哪里呢?我是否只是创建一个名为 UserDashboard 的控制器,并可能将根 (mysite.com/userdashboard) 路由到来自 UserDashboard 控制器的默认操作,例如,给定用户 ID,显示该用户在系统中的所有关系?

这是 Rails 的方式吗?我是否以某种方式打破了 RESTful 范式?

谢谢!

【问题讨论】:

    标签: ruby-on-rails ruby-on-rails-3


    【解决方案1】:

    你可以有两种方式:

    您可以创建一个代表用户仪表板的实体并将单独的数据存储在该实体中,或者您可以在代表仪表板的控制器上创建一个操作。两者都符合 REST 标准,因为您可以通过转到 /Dashboards(db_id) 或转​​到 /users/4/Dashboard 来唯一标识仪表板,这两个 URI 都可以识别唯一实体。

    【讨论】:

    • 您会在控制器操作中重定向/阻止用户尝试访问其他人的仪表板吗?
    • 我可能会重定向到他自己的仪表板。这意味着我将用户 ID 存储在会话中的某个位置,并且不需要在 URL 中指定它,因此只需在用户控制器上执行 /dashboard 操作。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-12-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-12-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多