实际上，我已经创建了一个Batch HTTP API，它接收一个JSON数组，其中包含对后端服务器的许多不同请求。Batch API只需将所有这些请求调用到负载均衡器，等待所有请求的返回，然后向客户端返回一个新的JSON。
客户端收到一个巨大的JSON数组响应，其索引与请求位于同一位置，因此很容易知道针对哪个请求要处理什么响应。
此API的动机是解决5个浏览器同时连接并提高性能，因为Batch API可以更直接地访问服务器(在此期间，我们没有反向代理或SSL服务器)。
该服务运行得很好，但随着它的使用越来越多，现在我有了一些新的要求。首先，该服务可以使用大量内存，因为它为每个请求都有一个缓冲区，只有在所有响应就绪时才会刷新(我使用的是有序的JSON数组)。此外，由于传递所有请求可能需要一些时间，因此客户端需要等待所有请求都得到处理，然后才能接收到单个字节。
我计划更改服务，以便在可用时尽快返回每个响应(并解决上述两个问题)。我想与您分享并验证我的想法：
- 我将把响应从JSON响应更改为多部分响应
- 服务器将为每个部分包括响应的索引
- 一旦响应可用，服务器将刷新响应
- 客户端XHR需要理解多部分内容类型响应，并能够在每个部分可用时立即处理
我会创建一个PoC来验证每一步，但现在我想验证这个想法，并听取一些想法。以下是我对解决方案的一些疑虑：
- 从我读到的内容来看，我认为这种内容类型适合回应。多部分/混合？多部分/摘要
- 我可以使用accept请求头来确定客户端是否能够处理新的服务实现吗？如果是，那么什么是正确的accept标头？我的计划是使用相同的端点，但非常接受标头
- 如何开发一个XHR客户端，使其能够在单个响应的多个部分可用时立即处理这些部分？我在网上找到了一些想法，但当时我并不完全相信
- 我将把响应从JSON响应更改为多部分响应
- 服务器将为每个部分包括响应
- 一旦响应可用，服务器将刷新响应
- 客户端XHR需要了解多部分内容类型响应能够在每个零件可用时立即对其进行处理
XHR协议将不通过来自客户端的单个请求来支持此工作流程。由于XHR在很大程度上依赖于HTTP协议进行通信，因此XHR遵循HTTP连接规则。第一条也是最重要的规则：HTTP连接总是由客户端发起的。另一条规则：XHR返回整个内容体或失败。
对工作流的影响是，客户端必须单独请求多部分响应的每一部分。
- 从我读到的内容来看，我认为这种内容类型适合回答多部分/混合？多部分/摘要
您应该有疑问，因为规范中没有这样做的规定。响应类型属性仅限于空字符串(默认值)、"arraybuffer"、"blob"、"document"、"json"one_answers"text"。可以设置覆盖MIME类型标头，但这不会更改响应类型。在这种情况下，XHR规范非常清楚它将发送回什么。它是上面列出的类型之一，如本文所述。
- 我可以使用accept吗请求标头，用于标识客户端是否能够处理新的服务实施？如果是，什么是正确的accept标头这我的计划是使用相同的端点，但非常接受标头
自定义HTTP标头旨在帮助我们告诉服务器我们在客户端上的功能。这很容易做到。它不一定必须在accept标头中(因为这也是MIME类型的定义列表)。
- 如何我能开发一个能够处理一旦有可用的单一响应？我在上面发现了一些想法网络，但我当时并不完全有信心
XHR由客户端本地处理，由于各种安全原因无法覆盖。因此，出于这个原因，这不太可能成为一种解决方案。
注意：通常有人可能会建议使用自定义版本的Chromium，但您的限制不允许这样做。