RESTful集合资源 - 惯用的JSON表示和往返

Question

我有一个名为Columns的集合资源.一个GET用Accept: application/json 不能直接返回一个集合,所以我表示需要它窝在一个属性: -

{ "propertyName": [
   { "Id": "Column1", "Description": "Description 1" },
   { "Id": "Column2", "Description": "Description 2" }
  ]
}

问题:

什么是上面的标识符propertyName使用的最佳名称？它应该是:
- d(即是ð建立的惯例或者是特定于某些特定的框架(MS WCF和MS ASP.NET AJAX？)
- 结果(即结果是既定惯例还是特定于某些特定规范(MS OData)？)
- 列(即顶级属性应该有一个清晰的名称,它有助于消除我对泛型的使用的歧义application/json作为媒体类型)
NB我觉得应该有一些包装它的东西很舒服,正如@tuespetre指出的那样,XML或任何其他表示方式会迫使你在某种程度上包装它
当重新输入内容时,是否应保留所述属性中的相同包装[鉴于出于安全原因实际上并不需要它,并且可能传统的JSON使用惯用法可能会丢弃PUT和POST的嵌套,因为它们不需要保护反对脚本攻击]？

我的直觉告诉我它应该是对称的,因为每个其他的表示,但可能有现有技术删除d /*结果**[假设这是第1部分的答案]*

...或者PUT-back(或POST)是否需要包装属性,只需使用: -
```
 [
       { "Id": "Column1", "Description": "Description 1" },
       { "Id": "Column2", "Description": "Description 2" }
 ]
```
- 如果有人希望添加,那么任何根级元数据会在哪里？
- 如何/一个人如何制作一个POST只知道它需要是对称的？

编辑:我特别感兴趣的是一个有理由的理由,特别考虑到JSON对客户端使用的影响.例如,HAL负责定义对两个目标表示都有意义的绑定.

编辑2:尚未接受,为什么？到目前为止,答案没有引用或任何使他们在我搜索和从前20个看似合理的命中中挑选出来的东西中脱颖而出的东西.我太挑剔了吗？我想我是(或者更有可能我不能正确地提出问题:D).它有点疯狂一周和3天,即使a)承认微不足道的奖金仍然只获得123次观看(其中3个答案也不错)

Answer 1