JSON 响应是否应该返回 base64 编码的文件？答案

【问题标题】：Should a JSON response return a base64-encoded file?JSON 响应是否应该返回 base64 编码的文件？
【发布时间】：2011-11-23 00:00:24
【问题描述】：

我正在创建一个 Web 服务，它将返回由其他用户“排队”的 XPS 文档。我想尽量减少请求的数量，因此我正在考虑将生成的排队文件合并到一个响应中：

"Files":
[
  {"Id": 1, "ContentType": "application/vnd.ms-xpsdocument", "Data": "base64-encoded data of file here" },
  {"Id": 2, "ContentType": "application/vnd.ms-xpsdocument", "Data": "another files base64 data"}
]

这是一个糟糕的主意吗？有什么我应该担心的吗？因为多台服务器会轮询这个 API，所以我真的很想尽量减少发送的请求数。如果有更好的方法可以做到这一点，我真的很感激任何建议。

FWIW，我计划用来对文件进行 base64 编码/解码的方法取自 this question。

【问题讨论】：

我一般不认为每个文件一个请求太多。您正在做的事情可能会奏效，但权衡起来似乎有点过于复杂。
@AndrewBarber - 我同意 KISS 的想法。但是，如果有 10 台服务器每隔几分钟使用 20 个文件访问此 API，我觉得需要减少请求的数量。此外，这意味着我必须在公共 API 中公开另一种方法。
我不确定你想要达到什么目的。如果是性能或吞吐量，Base64 将数据大小增加一半。如果它将文件数据嵌入到任意结构中，那么按原样传递它们的便利性可能会超过性能损失。
@ivan_pozdeev - 是的，我同意，这是这种方法的缺点:(。我只是想了解如何明智地做到这一点。
为了增加您的复杂性，您的文件大小是多少？根据这一点，可能有必要限制文件的数量（可能基于它们的大小），因此您的整体响应大小不会很大

标签： .net json web-services

【解决方案1】：

将文件压缩/压缩到存档中？这样可以避免 base64 数据爆炸。

编辑：正如您在 cmets 中还询问如何处理每个文件的元数据，让我在这里总结一下以方便将来参考：

将元数据放入每个 zip 文件条目的注释字段中。
对于每个文件，在存档中创建一个单独的文件，该文件具有相同的名称和一些您将元数据放入的关键扩展名 (.metadata?)。
将元数据嵌入到文件名中。（我想这是一个新想法）

【讨论】：

是的 - 我最初有这个，但它不允许我提供有关文件的元数据（id、名称、创建者等）。
对于每个文件，在存档中创建一个单独的文件，该文件具有相同的名称和一些您将元数据放入的关键扩展名（.metadata？）？
一个更好的主意是使用 zip 文件的注释字段作为元数据。
我将使用我原来的直觉，只需压缩文件并使用 .metadata 建议或评论字段。谢谢！
我想我应该明确一点，zip 存档中的每个文件都有自己的注释字段。整个 zip 存档没有一个评论字段，因为我之前的评论可能会被解释为所说的。

【解决方案2】：

如果以性能为目标，我会想到两个答案：

1) 使用客户端可轻松解析的不同数据格式，并允许二进制数据无需转换（某种序列化或只是原始文件数据之前的结构化前导码）。

2) 将 .xps 文档保存在某处（可能是 ramdisk）并通过单独的文件请求提供服务。

【讨论】：

【解决方案3】：

真正的问题是请求开销是否是满足 N 个文档请求所需的带宽或时间的重要部分。

也就是说，在 N 个请求中为 N 个文档提供服务需要一些时间和带宽（即每个请求一个文档）。

在 M 个请求（其中 M 更少带宽。但是，带宽节省是否显着？服务器端的处理是否有任何节省？每个请求肯定会有一些开销，但如果文档很大，带宽差异将可以忽略不计。如果服务器的每个文档处理时间明显大于每个请求的时间，那么节省的时间将可以忽略不计。

也就是说，如果可以的话，批处理数据通常是个好主意。我不会说对 JSON 进行 base64 编码是一个坏主意。如果您的客户已经设置好使用 JSON，这是一个绝妙的主意。通过在服务器上启用自动压缩（通常是 gzip），您可以节省带宽，但需要花费一些服务器时间。

【讨论】：