Question

我正在创建一个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。

Answer 1

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

编辑：正如您在评论中还询问如何处理每个文件的元数据一样，让我在此总结一下，以便日后参考：

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

Answer 2

如果表现是目标，我会想到两个答案：

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

2）将.xps文档保存在某处（可能是ramdisk）并使用单独的文件请求提供。

Answer 3

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

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

在M个请求中服务N个文档可能需要较少的带宽（其中M <＆lt; N）。但是，带宽节省是否显着？服务器端的处理有节省吗？肯定有一些每请求开销，但如果文档很大，带宽差异可以忽略不计。如果服务器的每个文档处理时间远远大于每个请求的时间，那么节省的费用可以忽略不计。

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

JSON响应应该返回base64编码的文件吗？

3 个答案: