1

我的 API 有以下功能，我偶然发现了几个问题：

  1. POST /user（需要全名、电子邮件、密码）将创建一个新用户，如果已创建用户，则会生成一个唯一的激活 ID，并通过邮件将激活帐户的链接发送给用户。

  2. PUT /user（需要 id、email）将激活用户。

一旦用户激活了它的帐户，它就可以登录。

  1. POST /session（需要电子邮件、密码）并登录用户。
  2. GET /session 将查看 cookie 会话 ID，如果经过身份验证，则返回用户信息。
  3. DELETE /session 将用户注销。

一旦用户登录，他会被要求提交他们的兴趣（只是一个 HTML 文本区域），他们也可以提交关于他们的帐户的描述（位置、性别等，但这都是可选的，所以也是一个 HTML 文本区域，就像 Twitter 帐户一样描述）

现在我的问题是：

如您所见 2. PUT /user 将激活用户，但是我将如何在适当的 restful 设计中处理提交的兴趣和帐户描述？

我是否应该查看我的后端服务器 PUT /user 将进入并检测提交的字段的位置？

或者创建一个单独的 PUT /user/activate 和 PUT /user/interests 是否更有意义。

完成后，我想用恢复密码来扩展它，这也是一个 PUT /用户，服务器端的字段检测会不会有点乱？

现在关于骨干网，这是我的会话模型：

var Session = Backbone.Model.extend({
  url: '/session'
});

var session = new Session();
session.fetch(); // Get the user authentication of the backend server.

我的用户模型：

var User = Backbone.Model.extend({
  url: '/user'
});

function signup(fullName, email, password){
  var user = new User();
  user.save({
    fullName: fullName,
    email: email,
    password: password
  });
};

function activate(id, activationId){
  var user = new User();
  user.save({
    id: id,
    activationId: activationId
  });
};

// Possibility...?
function submitInterests(id, interests){
  var user = new User(url: '/user/interests/');
  user.save({
    id: id,
    activationid: activationId
  });
}

感谢您的阅读。

4

1 回答 1

1

RESTful 世界的经验法则是：

动词向下，名词向上。

那是因为魔法 4 [ GET, POST, PUT, DELETE] 应该足以满足所有操作：没有/users/activate//user/edit周围的东西。

虽然对激活PUT进行整体/users处理似乎是合法的，但向/root“实体 = 用户，ID = 3，...”等发出所有请求并传递这些请求也是如此。

我建议您使用/entityname集合 [您可以POST在其中创建新集合]，然后/entityname/:id引用单个实体 [在这种情况下，单个用户]。

现在你可以做一个PUT完成/users/123你需要的任何事情。

当然你可以嵌套资源：

/users/:id/interests

这是:id-th用户所有兴趣的路线 - 你可以GET在它上面发出一个来检索它们，或者一个POST向列表中添加一个元素，一个从头开始PUT设置所有列表。

关于您的资源的最后一个想法session：真正的 RESTful 服务应该是 * stateless，即它不应该依赖会话。必须对每个请求进行授权，请参阅HTTP Basic Auth，尽管有时您可以使用会话。

为了与您的架构保持一致，您可以定义一个/user/:id/sessions资源，POST以便进行新的登录，这样您就可以跟踪用户访问。

于 2012-09-11T23:33:57.780 回答