Web服务的JSON设计 - 如何表达属性

Question

在我的团队中，设计我们的休息界面似乎有两种思路。这是一系列端点，它们本身就是我们销售的产品，因此客户界面是JSON。问题是如何表达对象的属性。我的想法是将属性作为资源的显式字段，如下所示：

{
  "myThing": [
    {
      "color": "blue",
      "number": "212"
    }
  ]
}

通过这种方法，您可以通过了解其属性来理解对象，并且感觉更加优雅和明确。对于潜在客户的商务人士来说，文档是直截了当的。

然而，我们的一些开发人员认为，以下是表达属性的首选方式 - 我相信因为我们有很多属性而且更容易管理，尽管可能有其他福利。但是，我不认为此信息的体系结构是用户友好或明确的，并且需要更广泛地交叉引用文档。

{
  "myThing": [
    {
      "attribute": "color",
      "value": "blue"
    },
    {
      "attribute": "number",
      "value": "212"
    }
  ]
}

我的问题 - 除了感觉第一种方法更直观之外，找到最佳实践或一种方法比另一种方法具有说服力的论证是困难的。任何人都可以指出一些最佳实践JSON设计，有利于一个优于另一个吗？谢谢！

Answer 1

哦，这在一些基本术语中是合格的，但两者都可以工作。诀窍是决定哪一个会更成功？它有助于想到成功与不成功，整个对与错的论点非常基于个人意见，并且是如此大量浪费时间。从不认为这是与技术人员合作的正确方法，你可以更容易地放牧猫。

因此，让我们将模型分解为Pro And Cons。

方法一是传统模式：

<强>临

1. 对象和属性定义明确。

2. 属性可以被验证，因为它们是已知的，即这是一个日期。

3. 更易于理解和记录。

<强>缺点：

1. 属性是静态的，扩展属性集将要求我们更新代码，并可能在客户知道属性时引入问题。

接近两个被称为实体属性值设计模式的方法（顺便说一下，关于数据库设计中的BIG no no）。

<强>临

1. 向对象添加属性不需要进行太多更改。它也不太可能破坏客户等。

<强>缺点：

1. 文档更难。

2. 数据验证要困难得多，你的例子中的颜色属性应该是像Blue这样的字符串吗？或者像＃ffae12这样的HEX？也许CMYK？它更难以验证和记录这些类型的东西。

3. 要求开发人员/客户了解设置和获取值的机制，即它打破了正常的编程范例。

如何选择使用哪种型号？

这里的原则是了解您的数据。如果对象具有不同属性的负载并且它们非常动态，即您在很多时候添加或删除属性，那么接近2更好。例如，社交媒体类型数据非常适合。

如果您正在处理金融交易数据，例如借记，贷方等，您希望尽可能高的验证，除了付款和接收付款没有改变，您不太可能在信用证中引入第三个帐号交易对象。不是说这是不可能的，但不太可能。

始终保持开放的心态，并在需要时使用最合适的工具。不要盲目跟随思想流派。了解您的工具，数据，然后它很容易创新。