我对收集资源的设计感到困惑。
假设我有一个用户资源 - 如下所示。
http://www.example.com/users/{user-id}
user : {
id : "",
name : "",
age : "",
addresses : [
{
line1 : "",
line2 : "",
city : "",
state : "",
country : "",
zip : ""
}
]
}
现在,我的用户如何收集资源表示?它应该是用户表示列表(如上所述)吗?或者它可以是下面的一个子集:
http://www.example.com/users/
users : [
{
id : "",
name : "",
link : {
rel : "self",
href : "/users/{id}"
}
}
]
集合资源表示是否应包含包含资源的完整表示,还是可以是子集?
答案 0 :(得分:8)
媒体类型定义了如何传达信息的规则。请查看Collection+JSON和HAL的规范,了解如何执行您要执行的操作。
答案 1 :(得分:0)
这完全取决于你想要它做什么。 REST API的优点在于它们非常灵活。您可以以任何方式(理论上)表示您想要的数据。
就个人而言,我会有一个允许用户指定表示的子集或样式的属性。例如/users/{userid}.json?output=simple
或/users/{userid}.json?subset=raw
沿着这些方向的某些东西也可以让你在不牺牲灵活性的情况下嵌套表示和微调你想要的东西:
/users/{userid}.json?output=simple&subset=raw
天空是极限
答案 2 :(得分:0)
这没有真正的标准。你有选择:
返回收集项资源的链接列表(即用户ID)。
http://www.example.com/users/
users : [
"jsmith",
"mjones",
...
]
请注意,这些实际上可以解释为相对URI,这有点支持“所有资源都应该可以通过以下URI从根URI中访问”理想。
http://www.example.com/users/ + jsmith = http://www.example.com/users/jsmith
返回部分资源(用户)列表,允许调用者指定要包含的字段。如果用户不提供任何字段,您可能还有一个默认的字段选择 - 默认情况甚至可能是“包括所有字段。”
http://www.example.com/users/?field=id&field=name&field=link
users : [
{
id : "jsmith",
name : "John Smith",
link : "www.google.com"
},
...
]
答案 3 :(得分:0)
我会通过娱乐
来使list
服务细化
http://www.example.com/users?include=address|profile|foo|bar
可以使用,
或-
之类的任何分隔符(&和URL编码除外)代替|
。在服务器端,检查那些包含属性并相应地呈现JSON响应。
答案 4 :(得分:0)
它可以是子集,但取决于数据。看看下面的代码。
{
"usersList": {
"users": [{
"firstName": "Venkatraman",
"lastName": "Ramamoorthy",
"age": 27,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [{
"type": "mobile",
"number": "+91-9999988888"
}, {
"type": "fax",
"number": "646 555-4567"
}]
}, {
"firstName": "John",
"lastName": "Smith",
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [{
"type": "home",
"number": "212 555-1234"
}, {
"type": "fax",
"number": "646 555-4567"
}]
}]
}
}