事实上，从来就创建接收与许多不同的要求给我们的后端服务器的JSON阵列批量HTTP API。批处理API只是把所有这些请求的负载平衡器，等待所有的人的回报，并返回一个新的JSON到客户端。
客户端接收其在相同的位置请求指数巨大的JSON阵列响应，所以很容易知道什么响应什么请求解决。
这个API的动机是为了解决5浏览器同时连接和提高性能的批处理API具有对服务器更加直接访问（我们没有一个反向代理或则之间的SSL服务器）。
该服务正在运行得很好，但现在我有一些新的要求，因为它是获得更多的使用。首先，该服务可以使用大量的内存，因为它对当所有响应准备将只刷新每个请求的缓冲区（我使用的是有序的JSON阵列）。更多的，因为它可能需要一些时间来所有请求交付，客户端将需要等到一切处理收货单字节之前。
我计划更改服务尽快返回每个响应是可用的（和解决上述两个问题）。并愿与大家分享，并验证了我的想法：
我将创建一个的PoC来验证每一个步骤，但在这一刻，我想验证这个想法，听到关于它的一些想法。这里有些怀疑我有解决方案：
- 我会改变从JSON响应多响应的响应。
- 服务器将包括每一个部分，响应的指数
- 服务器会刷新一次，其可用的响应
- 客户XHR需要理解多部分内容类型响应，并能够尽快，因为它是可处理每一个部分。
该XHR协议将不支持通过来自客户端的单个请求该工作流程。由于XHR在很大程度上依赖于用于通信的HTTP协议，XHR遵循HTTP连接规则。第一个也是最重要的规则：HTTP连接总是由客户端启动。另一条规则：XHR返回整个内容体或失败。
使您的工作的影响是多部分响应的每个部分都必须由客户单独请求。
- 从我读，我在内容类型的怀疑是正确的响应。多/混合？多/消化？
你应该在怀疑有在specfication没有规定这样做。响应类型属性被限制为the empty string (default), "arraybuffer", "blob", "document", "json", and "text".所以能够设定的倍率MIME类型报头，但这并不改变响应类型。考虑到事件的情况下，该XHR规范是什么，将发回很清楚。这是上面列出as documented here.的类型之一
- 我可以用一个接收请求头，以确定客户端是否能够处理新的服务实现？如果是这样，什么是正确的接受标头吗？我的计划是使用相同的点，但很接受头。
自定义HTTP标旨在帮助我们告诉服务器是什么我们的能力是在客户端上。这是很容易做到。它不一定必须在accept头（作为也是定义的MIME类型的列表）。
- 我怎样才能尽快为他们提供开发XHR客户端能够处理单个响应的许多地方？我在网上找到了一些ideias但我不那么完全有信心。
XHR是由客户端本地处理，并不能覆盖所有的各种各样的安全考虑。因此，这是不太可能可以作为这个原因的解决方案。
注：通常人们可能会建议使用的铬的定制版本，但你的约束不允许为。