实际上，我已经创建了一个批处理HTTP API，该API接收到一个JSON数组，该数组具有对我们的后端服务器的许多不同请求。 Batch API只是将所有这些请求调用到负载均衡器，等待所有请求返回并向客户端返回新的JSON。
客户端会收到一个巨大的JSON数组响应，其索引与请求的位置相同，因此很容易知道针对哪个请求处理了什么响应。
此API的动机是解决5个浏览器的同时连接并提高性能，因为Batch API对服务器具有更直接的访问权限（在此之间，我们没有反向代理或SSL服务器）。
该服务运行良好，但是现在我有了一些新的要求，因为它得到了越来越多的使用。首先，该服务可以使用大量内存，因为它为每个请求都有一个缓冲区，只有在所有响应准备就绪时（我正在使用有序JSON数组），才会刷新该服务。而且，由于所有请求都需要花费一些时间，因此客户端将需要等待所有处理，然后再接收单个字节。
我正计划更改服务以在每个响应可用时返回它（并解决上述两个问题）。并希望与您分享并验证我的想法：
我将创建一个PoC来验证每个步骤，但此刻我想验证该想法并听到一些想法。我对解决方案有一些疑问：
答案 0 :(得分：0)
- 我将响应从JSON响应更改为多部分 回应。
- 服务器将为每个部分包括 响应
- 服务器将在响应可用后刷新响应
- 客户XHR将需要了解多部分内容类型的响应以及 能够尽快处理每个零件。
XHR协议不会通过来自客户端的单个请求来支持此工作流程。由于XHR严重依赖HTTP协议进行通信，因此XHR遵循HTTP连接规则。第一个也是最重要的规则：HTTP连接始终由客户端启动。另一个规则：XHR返回整个内容主体，否则将失败。
对您的工作流程的影响是，客户必须分别请求多部分响应的每个部分。
- 根据我的阅读，我对这种内容类型感到怀疑，因为它适合 响应。多份/混合？多部分/摘要？
您应该对此表示怀疑，因为规范中没有规定要这样做。 response-type属性限制为the empty string (default), "arraybuffer", "blob", "document", "json", and "text".，可以设置替代MIME类型标头，但这不会更改响应类型。鉴于这种情况，XHR规范非常清楚其将发送回什么内容。它是以上as documented here.
列出的类型之一
- 我可以使用接受吗 请求标头，以识别客户端是否能够处理新的 服务实施？如果是这样，正确的接受标头是什么 这个？我的计划是使用相同的端点，但非常接受标头。
自定义HTTP标头旨在帮助我们告诉服务器客户端所具有的功能。这很容易做到。它不一定必须位于accept标头中（因为它也是MIME类型的已定义列表）。
- 如何 我可以开发一个XHR客户端，该客户端能够处理 可用后立即作出单一回应？我发现了一些想法 Web，但那时我并不完全有信心。
XHR由客户端本地处理，并且由于各种安全原因不能被覆盖。因此，由于这个原因，这不太可能作为解决方案。
注意：通常可能会建议您使用Chromium的自定义版本，但您的限制不允许这样做。