Backbone.js的宁静JSON API设计 [英] Backbone.js restful json API design
问题描述
我有以下功能在我的API和我strumbled在几个问题：
I have the following functionality at my API and I strumbled upon a few questions:
-
POST /用户（需要全名，电子邮件，密码）将创建一个新的用户，如果用户已经创建产生一个独特的激活ID和激活帐户是通过邮件发送到用户的链接。
POST /user (requires fullName, email, password) will create a new user, if the user has been created an unique activation ID is generated and a link to activate the account is send through mail to the user.
PUT /用户（需要ID，邮箱）时将激活用户。
PUT /user (requires id, email) will activate the user.
一旦用户激活它的帐户，就可以登录。
Once the user has activated it's account, it can login.
- POST /会话（需要电子邮件，密码）和日志的用户。
- GET /会议将着眼于cookie的会话ID和返回，如果auth用户的信息。
- 删除/会话注销用户。
一旦用户登录，他被要求提交自己的利益（只是一个HTML textarea的），他们可以提交他们的帐户太（地点，性别等的描述，但它是所有可选的，所以也是一个HTML textarea的刚像Twitter帐户说明）
Once the user is logged in, he is asked to submit their interests (just a HTML textarea) and they can submit a description about their account too (Location, gender, etc but it is all optional so also an HTML textarea just like Twitter account description)
现在我的问题是：
正如你所看到2. PUT /用户激活用户，但我将如何处理在适当的宁静设计提交的利益和帐户说明？
As you can see 2. PUT /user will activate the user, but how would I handle the submit interests and account description in a proper restful design?
我应该看的地步，我的后台服务器PUT /用户会在和检测，凡提交的领域？
Should I look at the point where at my backend server PUT /user will come in and detect the fields that where submitted?
或者，它将使更多的SENCE创建一个分离PUT /用户/激活和PUT /用户/利益。
Or would it make more sence to create a separated PUT /user/activate and PUT /user/interests.
一旦完成，我想扩大它恢复密码，也这将是一个PUT /用户将不能在服务器端的现场检测会有点凌乱？
Once this is finished, I want to expand it with restore password, also this would be a PUT /user wouldn't the field detection at the server side will get kinda messy?
现在约骨干，这是我的会话模型：
Now about backbone, this is my session model:
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
});
}
感谢您的阅读。
推荐答案
在REST风格的世界的经验法则是：
A rule of thumb in RESTful world is:
下来动词，名词了。
这是因为魔术4 GET，POST，PUT，DELETE ]应该够所有操作：无 /用户/激活 / /用户/编辑的东西左右。
That's because the magic 4 [GET, POST, PUT, DELETE] should be enough for all actions: no /users/activate / /user/edit stuff around.
同时使 PUT 较全 /用户激活看似合法的，所以将作出一切请求 /根并通过实体=用户ID = 3 ......等。
While making a PUT over the whole /users for activation may seem legit, so would be making all the requests to /root and passing "entity = users, id = 3, ..." and so on.
我建议你使用 /实体名称为集合[在那里你可以 POST 来创建一个新] ，然后 /实体名称/：为了指代单个实体[在这种情况下，单个用户]
I advice you to use /entityname for the collection [where you can POST to create a new one], then /entityname/:id in order to refer to a single entity [in this case, a single user].
现在你可以做一个 PUT 在 /用户/ 123 来完成任何你所需要的。
Now you can make a PUT on /users/123 to accomplish whatever you need.
当然，你可以窝资源：
/users/:id/interests
这是为各方利益的路线：ID个用户 - 在它可以发出 GET 检索所有这些，或 POST 将元素添加到列表中，一个 PUT 设置全部从头列表。
This is the route for all interests of :id-th user - you can issue a GET over it to retrieve them all, or a POST to add an element to the list, a PUT to set all the list from scratch.
你的会议最后一个思想资源：一个真正的RESTful服务应该是*的无国籍的，即它不应该依赖会话。授权必须在每次请求提出，请参见 HTTP基本认证，虽然你可以来与会话有时。
One last thought about your session resource: a true RESTful service should be *stateless, i.e. it should not rely on session. Authorization has to be made on every request, see HTTP Basic Auth, though you can come with a session sometimes.
要对你的架构保持一致，你可以定义一个 /用户/：ID /会话资源在那里你可以 POST 为了使新的登录，这样你就可以跟踪用户访问。
To be consistent to your schema, you can define a /user/:id/sessions resource where you can POST in order to make a new login, so you can keep track of user accesses.
这篇关于Backbone.js的宁静JSON API设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
