0

我正在创建一个基于 Rails 的 API 来管理短信订阅。有一个subscriptions控制器respond_to :html, :json, :xml和一个Subscription模型。两者都工作正常。

订阅后，用户仍然需要通过在发送到他手机的页面上输入 PIN 来确认他的订阅，所以我正在考虑一个confirms控制器来管理它。

我有几个关于如何实现这一点的问题。

(1) 订阅后的正确方法或最佳实践是什么。显示创建的订阅对象（html、json 或 xml，具体取决于它的创建方式）并将确认控制器作为单独的操作进行管理，还是应该重定向到确认控制器？

我想由于 API 响应 json 和 XML，重定向到任何其他页面/控制器不是一个好主意，并且显示创建的对象会更好吗？

(2) 如果是这种情况，我正在使用 CanCan 来管理角色能力。由于订阅属于User不需要经过身份验证的所有者（开发人员）POST（我知道谁是用户所有者，因为给出的关键字/短代码的组合）并且订阅可以由任何冲浪者进行（不需要用于在创建之前进行身份验证）我如何将创建的对象限制为该冲浪者？

我猜如果User已登录，则很容易向他展示该对象，因为它是所有者，但是创建该对象且不需要进行身份验证的常规冲浪者呢？

我没有任何方法可以将冲浪者连接到对象以限制它的能力。

(3) 在创建对象后向普通冲浪者展示对象是个好主意吗？我可能认为这可能不相关，因为当开发人员通过 api 本身的 json 进行操作时？

订阅模型非常简单，它的工作原理是这样的

$ curl http://mysite.com/subscriptions \
-d shortcode=7889 \
-d keyword=KEYWORD \
-d phone=6895874587 \
-d country=us \
4

1 回答 1

1

让我尝试一一攻击：）

  1. 在创建记录后，如果状态码支持，通常返回对象是一个好习惯，即如果创建记录，您应该返回对象以及 200 状态码。请记住，某些状态代码不允许正文，即 201。通常，大多数现代 http 客户端都支持重定向，但我仍会将其保留在 2 个单独的操作中

  2. 通常，对用户进行身份验证仍然是一个好主意，因为您希望防止一个用户代表另一个用户发帖。无论您是否可以通过分析参数来确定用户是谁，您都可以将订阅与它联系起来，例如：

    @user=User.find_by_phone(params[:phone]) @subscrition = @user.subscritions.build(params)

  3. 是的，归还已保存的内容通常是个好主意。

于 2012-06-04T19:58:09.063 回答