来自 Web 服务的 JSON 响应 - 最佳实践问题

Question

我正在编写一个简单的Web服务，返回JSON响应。它将被大量使用，因此出于性能原因，我想尝试使 JSON 响应尽可能小。我对设计决策持观望态度;你怎么想！

我来自服务器的 JSON 响应如下所示：

{
  "customers":
  [
    {
      "id": "337",
      "key": "APIfe45904c"
    },
    {
      "id": "338",
      "key": "somethingDifferent"
    },
    {
      "id": "339",
      "key": "APIfe45904c"
    },
    {
      "id": "340",
      "key": "APIfe45904c"
    }
  ]
}

这里的APIfe45904c用于大约 60-70% 的记录，所以我还可以修改 JSON 响应以删除重复的信息并添加一个default_key即如果没有指定key，客户端应该像这样假设default_key：

{
  "default_key": "APIfe45904c",
  "customers":
  [
    {
      "id": "337"
    },
    {
      "id": "338",
      "key": "somethingDifferent"
    },
    {
      "id": "339"
    },
    {
      "id": "340"
    }
  ]
}

还没有客户端正在使用 Web 服务，因此这不会破坏任何内容。这是好的做法吗？它可以工作，并且可以生成一个小的 JSON 响应，但我感到冲突。我喜欢使用该服务的开发人员的 KISS 原则，但我也希望 JSON 响应尽可能小。

我很想用c替换customers，id用i替换，用k替换key以帮助减小文件大小，但我认为如果我想让其他客户端开始使用它将是一个问题。出于同样的原因，我应该放弃default_key的想法吗？

每个 JSON 响应可能不再有 200 行 id/密钥对，所以我不需要合并分页等。

Answer 1

我会像你说的那样保持简单，然后使用 gzip 压缩它。它应该压缩得很好，因为它是重复的，并且对程序员来说仍然很方便。

有关为 AJAX 输出 gzip 标头的指针，请参阅此处：gzip 编码是否与 JSON 兼容？

Answer 2

除非您有非常特殊的性能需求，否则我总是会选择清晰而不是简洁。特别是对于将被许多开发人员使用的 API。

Answer 3

应使用一致的格式，其中每条记录都有一个id和一个key字段。 您失去的带宽是不必在客户端预处理 JSON 而获得的。

我倾向于像您一样分析我的 JSON 数据结构，但最终不值得您节省一点空间。 您的 JSON 数据结构看起来不错...你看过Twitter的JSON数据结构吗？ 现在这很丑陋。

Answer 4

我会

使用默认的关键思想，但我不会缩短属性名称，因为这可能会令人困惑。也许您可以从 Web 服务调用(从查询字符串(中获取一个参数，该参数指定客户端是否希望缩短属性名称。