Question

我正在编写一个返回JSON响应的简单Web服务。它会被大量使用，所以我想尝试让JSON响应尽可能小，以提高性能。我对设计决定持怀疑态度;便士为你的想法！

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

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

这里约有60-70％的记录使用APIfe45904c，因此我也可以修改JSON响应以删除重复的信息并添加default_key，即如果没有{{} 1}}指定，客户端应该假设key像这样：

default_key

还没有客户使用网络服务，所以这不会破坏任何东西。这是好习惯吗？它起作用，并且产生一个小的JSON响应，但我很矛盾。我喜欢使用该服务的开发人员的KISS原则，但我也希望尽可能小的JSON响应。

我很想将{ "default_key": "APIfe45904c", "customers": [ { "id": "337" }, { "id": "338", "key": "somethingDifferent" }, { "id": "339" }, { "id": "340" } ] }替换为customers，将c替换为id，将i替换为key，以帮助缩小文件大小，但我想如果我想让其他客户开始使用它，这将是一个问题。我是否应该出于同样的原因放弃k的想法？

每个JSON响应可能不会有200行id / key对，所以我不需要加入分页等。

Answer 1

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

请参阅此处获取输出AJAX的gzip标头的指针：Is gzip encoding compatible with JSON?

Answer 2

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

Answer 3

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

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

Answer 4

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

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

4 个答案: