0

我正在尝试找到一个可用于不同场景的数据模式，到目前为止我发现的有希望的格式是 collection+json 格式（http://amundsen.com/media-types/collection/）。

到目前为止，它有很多我需要的功能并且非常灵活，但是我不明白为什么它使用匿名对象（例如：）{"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"},而不是简单的键值对。（例如：“全名”：“J. Doe”，）。

我知道如何传输更多信息，如提示等，但解析速度要慢得多，并且很难为其创建客户端，因为他必须通过在数组中搜索来访问字段。将数据绑定到特定视图时，必须知道存在哪些字段，因此必须再次将匿名对象转换为键值映射。

那么使用这个匿名对象而不是键值映射是否有真正的优势？

4

2 回答 2

2

我认为主要原因是因为消费者客户端不需要提前知道数据的格式。

正如现在在collection+json中提出的那样，您知道在数据对象中您只需通过解析就可以找到有关数据的内容，'name'始终是字段的标识名称，'value'是值等等，您的客户可能不知道有多少字段或其名称：

{
 "name" : "full-name", 
 "value" : "J. Doe", 
 "prompt" : "Full Name"
},
{
 "name" : "age", 
 "value" : "42", 
 "prompt" : "Age"
}

如果你有

{
 "full-name" : "J. Doe", 
 "age" : "42"
}

客户需要事先了解您的表示，因此它应该期望并理解“全名”、“年龄”和所有特定于应用程序的字段。

于 2013-11-27T10:42:24.593 回答
0

我写了这个问题然后忘了它，但找到了我在这里寻找的答案：

https://groups.google.com/forum/#!searchin/collectionjson/key/collectionjson/_xaXs2Q7N_0/GQkg2mvPjqMJ

来自集合+JSON 的创建者 Mike Amundsen

我理解您希望将对象序列化模式添加到 CJ。但是，我的 CJ 设计的主要目标之一是不支持对象序列化。我知道序列化是 Web 消息经常需要的功能。这是优化代码和程序员体验的好方法。但这并不是我在这个特定设计中的目标。

我认为扩展 Kevin ref'd 是一个不错的选择。不确定是否有人真的在使用它。如果你想设计一个（基于你的“身体”想法），那很酷。如果你想从一个要点开始而不是做整个“拉”的事情，那很酷。发布它，让我们谈谈它。

另一方面，我为 CJ 编写了一个非常基本的客户端解析器（它位于 repo 的基本文件夹中），以展示如何干净地隐藏导航 CJ 状态模型的“昂贵”部分。我实际上有一个工作项来创建一个可以将状态表示转换为任意本地对象模型的客户端库，但还没有时间完成这项工作。也许这是你想帮助我的事情？

在更深（可能更无聊）的层面上，这种状态模型方法是我想到的更大模式的一部分，将消息视为“无类型”容器，并允许客户端和服务器使用他们喜欢的任何本地对象模型- 无需就该对象模型达成跨网络协议。这是我正在努力的“自以为是的设计模型”。

最后，正如您在线程顶部正确指出的那样，HAL 和 Siren 能够更好地支持对象序列化样式消息。我认为这很酷，我鼓励人们（包括我的客户）在对象序列化是首选模式时使用这些其他格式，并在状态转移是首选模式时使用 CJ。

于 2013-11-27T13:23:19.113 回答