Restful 响应中的 json 数据是否应该包含对象类型信息？
假设我们想要填充一些 javascript 模型（例如backbone.js 模型），给定来自服务器的 json 响应，如下所示：
{
"todo": {
"title": "My todo",
"items": [
{ "body": "first item." },
{ "body": "second item"}
]
}
}
此数据不包含类型信息，因此当我们看到 < 时，我们不知道要填充哪个模型代码>“待办事项”键。
当然，可以创建一些自定义标准来将 json 响应对象中的键链接到客户端模型。例如：
{
"todo": {
"_type": "Todo",
"title": "My todo",
...
}
}
虽然这适用于对象，但当涉及到列表时就会变得尴尬：
"items": {
"_type": "TodoItem",
"_value": [
{ "body": "first item." },
{ "body": "second item"}
]
}
在创建此自定义规则之前，问题是：
是否有关于在响应数据中包含客户端类型信息的 RESTful 指南？
如果不是，在响应 json 中包含客户端类型信息是否是一个好主意？
除了填充模型的整个方法之外，还有哪些其他替代方案？
编辑
虽然可以从 URL 检索模型类型，例如 /todo 和 /user，但这种方法的问题是初始群体N 个模型意味着 N 个 http 请求。
相反，初始填充可以通过单个大合并树完成，只需 1 个请求。在这种情况下，url 中的模型类型信息会丢失。
Let's say we want to populate some javascript models (eg backbone.js models), given a json response from a server like this:
{
"todo": {
"title": "My todo",
"items": [
{ "body": "first item." },
{ "body": "second item"}
]
}
}
This data does not contain the type information, so we do not know which model to populate when we see the "todo" key.
Of course one can create some custom standard to link the keys in the json response object to the client side models. For instance:
{
"todo": {
"_type": "Todo",
"title": "My todo",
...
}
}
While this works for objects, it gets awkward when it comes to lists:
"items": {
"_type": "TodoItem",
"_value": [
{ "body": "first item." },
{ "body": "second item"}
]
}
Before creating this custom rules, the questions are:
Are there any RESTful guidelines on including client side type information in response data?
If not, is it a good idea to include the client side type information in the response json?
Beside this whole approach of populating models, what are other alternatives?
Edit
While the model type can be retrieved from the url, eg /todo and /user, the problem with this approach is that the initial population of N models would mean N http requests.
Instead, the initial population can be done from a single big merged tree with only 1 request. In this case, the model type information in the url is lost.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当你有一个模型可以扩展另一个模型时，它真的很有用。指示具体使用哪个模型消除混乱
it's really useful when you have a model that extends another. indicating which model specifically to use eliminate the confusion
每个 REST 对象使用不同的端点 (url)。因此该 url 包含“哪个型号”信息。
每个模型都是变量和（固定）类型的固定集合。
因此通常不需要通过线路发送动态类型信息。
已添加回复 @ali 的评论 -
正确。但您现在问一个不同/更精确的问题：“如何处理 Backbone 模型的初始负载而不引起许多 http 请求？”我不确定这个问题的最佳答案。一种方法是告诉主干下载多个模型集合。
这会将调用次数减少到每个模型一次，而不是每个模型实例一次。
第二种方法是通过非 REST 调用/响应从服务器下载当前数据树。这是个好主意。浏览器客户端可以接收响应，然后将其逐个模型馈送到主干网。请务必向用户提供一些有关正在发生的情况的反馈。
回复：嵌套模型。这是一个SO q。
A different endpoint (url) is used for each REST object. So the url includes the "which model" information.
And each model is a fixed collection of variables and (fixed) types.
So there is usually no need to send dynamic type information over the wire.
Added Re the comment from @ali--
Correct. But you're now asking a different/more precise question: "How do I handle the initial load of Backbone models without causing many http requests?" I'm not sure of the best answer to this question. One way would be to tell backbone to download multiple collections of models.
That would reduce the number of calls to one per model vs one per model instance.
A second way would be a non-REST call/response to download the current tree of data from the server. This is a fine idea. The browser-client can receive the response and then feed it model by model into backbone. Be sure to give the user some feedback about what's going on.
Re: nested models. Here's a SO q on it.
考虑到，正如其他答案中已经说过的那样，在 REST 中，每个资源都有自己的端点，因此您尝试做的事情（即将所有模型隐藏在单个端点后面）并不完全符合 REST 规范，恕我直言。本身没什么大不了的。
嵌套集合可能就是这里的答案。
“包装器”集合在初始化时从单个端点获取所有模型，并将它们推送到各自的集合。当然，您必须在 json 中发送类型信息。
从那时起，每个“内部”集合都会对其自己的事件做出反应，并处理自己的端点。
只要您意识到这一点，我不认为这种优化有什么大问题。
Consider that, as already said in other answers, in REST each resource has its own endpoint, and thus what you are trying to do (ie. hide all your models behind a single endpoint) is not fully REST-compliant, IMHO. Not a big deal per se.
Nested collections could be the answer here.
The "wrapper" collection fetches all the models from a single endpoint at init time, and pushes them to the respective collections. Of course you must send the type info in the json.
From that point on, each "inner" collection reacts to its own events, and deals with its own endpoint.
I don't see huge problems with such an optimization, as long as you are aware of it.