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

【问题标题】：JSON Response from web service - best practices question来自 Web 服务的 JSON 响应 - 最佳实践问题
【发布时间】：2011-06-15 17:31:13
【问题描述】：

我正在编写一个返回 JSON 响应的简单 Web 服务。它将被大量使用，因此出于性能原因，我想尝试使 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 响应尽可能小。

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

每个 JSON 响应可能不会超过 200 行 id/key 对，因此我不需要合并分页等。

【问题讨论】：

为什么这个标签是“休息”？出于性能原因，消息需要尽可能小的架构与 REST 完全相反，REST 依赖于缓存来发送更少的较大消息而不是许多较小的消息。

标签： javascript web-services json api rest

【解决方案1】：

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

有关为 AJAX 输出 gzip 标头的指针，请参见此处：Is gzip encoding compatible with JSON?

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

您应该使用一致的格式，其中每条记录都有一个id 和一个key 字段。无需在客户端预处理 JSON 即可获得带宽损失。

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

【讨论】：

【解决方案4】：

我会采用默认的关键思想，但我不会缩短属性名称，因为这可能会造成混淆。也许您可以从 Web 服务调用（来自查询字符串）中获取一个参数，该参数指定客户端是否希望具有缩短的属性名称。

【讨论】：