【问题标题】:Json Object with one attribute or primitive Json Data type?具有一个属性或原始 Json 数据类型的 Json 对象?
【发布时间】:2019-02-15 09:35:23
【问题描述】:

我正在构建一个创建资源的 REST API。该资源只有一个属性,即相当长且唯一的字符串。我计划将此数据作为 JSON 发送到 API。我看到将数据建模为 JSON 的两种选择

  1. 原始 JSON 字符串数据类型
  2. 具有一个字符串属性的 JSON 对象。

这两个选项都有效。

这两个选项中的哪一个更适合这种情况?为什么?

【问题讨论】:

    标签: json rest


    【解决方案1】:

    返回的基本答案

    我个人会使用选项 2,即:`具有一个 String 属性的 JSON 对象。'

    另外,在设计方面:我更喜欢返回一个具有键/值的对象。键也是一个名称,提供返回内容的上下文。

    仅返回一个字符串,基本上是一个 "" 或 {""} 缺少该上下文(返回变量的名称。

    辩论:原始字符串是 Json 对象吗?

    对于 String 本身是否是有效的 JSON 文档,似乎也存在一些混淆。

    这种混淆和争论在以下提到各种技术规范的帖子中非常明显:Is a primitive type considered JSON?

    唯一可以确定的是,带有键值对的 JSON 对象绝对有效!

    至于字符串本身..我不确定(需要更多阅读)。

    更新:就创建/更新实体(发布/放置)而言的回答

    在上面的特定情况下,与“运行到几千字节”的如此大的字符串有关......我的感觉是这将包含在请求正文中。

    在发送数据的特定上下文中,我实际上可以使用 1 或 2。此外,1 似乎更优化(如果您的框架支持它),因为有关数据是什么的上下文与REST API 方法。

    但是,如果将来您需要再添加一个参数,则必须使用具有多个键的 JSON 实体。

    【讨论】:

    • JSON 标准只允许数组和对象位于顶层。很好的答案!
    • @Evert 感谢您的澄清!我正在阅读那个stackoverflow帖子中的讨论,这有点混合啊哈哈哈:D
    • 我实际上正在收回它。我想确定一下,但事实证明 RFC 确实允许顶层的所有内容:tools.ietf.org/html/rfc8259#section-2
    • @Evert 太烦人了,他们似乎已经改变了主意。
    • @MenelaosBakopoulos。只是想澄清一下......我指的是作为输入发送到 API 的 JSON 数据。在这种情况下,我认为资源本身将设置有关数据内容的上下文。例如,如果资源是电子邮件(即 API 端点是 /email)并且数据是 。 PUT /email/ 会有意义。但正如我所说,由于我的数据是一个运行到几千字节的字符串,所以我无法对其建模。所以,我正在寻找其他选择
    猜你喜欢
    • 2021-12-09
    • 2018-11-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多