Создайте пакетный HTTP API с многочастным ответом

Question

На самом деле я создал Batch HTTP API, который получает массив JSON со многими различными запросами к нашему внутреннему серверу.Пакетный API просто вызывает все эти запросы к балансировщику нагрузки, ожидает возврата всех из них и возвращает новый JSON клиенту.

Клиент получает огромный ответ массива JSON со своими индексами вта же позиция, что и у запроса, поэтому легко узнать, какой ответ адресован для какого запроса.

Мотивация для этого API состояла в том, чтобы решить 5 одновременных подключений браузера и повысить производительность, поскольку Batch API имеет гораздо большепрямой доступ к серверу (между нами нет обратного прокси-сервера или SSL-сервера).

Служба работает довольно хорошо, но теперь у меня есть некоторые новые требования, поскольку она получает все большее использование.Во-первых, служба может использовать много памяти, поскольку у нее есть буфер для каждого запроса, который будет сброшен только тогда, когда все ответы готовы (я использую упорядоченный массив JSON).Более того, поскольку для доставки всех запросов может потребоваться некоторое время, клиенту потребуется подождать, пока все будет обработано, прежде чем получать один байт.

Я планирую изменить службу так, чтобы она возвращала каждый ответ, как только он станет доступен.(и решить обе проблемы выше).И я хотел бы поделиться и подтвердить мои идеи с вами:

1. Я изменю ответ с ответа JSON на ответ, состоящий из нескольких частей.
2. Сервер будет включать для каждой части индекс ответа
3. Сервер сбрасывает ответ, как только он становится доступным
4. Клиентский XHR должен будет понимать составное содержимоевведите ответ и сможете обрабатывать каждую часть, как только она станет доступна.

Я создам PoC для проверки каждого шага, но в этот момент я хотел бы подтвердить идею и услышать некоторые мыслиоб этом.Вот некоторые сомнения, которые у меня есть по поводу решения:

1. Из того, что я прочитал, я сомневаюсь, что тип контента подходит для ответа.многочастному / смешанная?multipart / digest?
2. Можно ли использовать заголовок запроса на принятие, чтобы определить, способен ли клиент обрабатывать реализацию новой службы?Если да, то как правильно принять заголовок для этого?Я планирую использовать ту же конечную точку, но с очень приемлемым заголовком.
3. Как мне разработать клиент XHR, способный обрабатывать многие части одного ответа, как только они станут доступны?Я нашел некоторые идеи в Интернете, но я не совсем уверен в этом.

Answer 1

1. Я изменю ответ с JSON-ответа на многочастный ответ.
2. Сервер будет включать для каждой части индекс ответа
3. сервер сбросит ответ, как только он станет доступным
4. Клиентский XHR должен будет понять ответ с составным типом контента и иметь возможность обрабатывать каждую часть, как только она станет доступной.

Протокол XHR не будет поддерживать этот рабочий процесс посредством одного запроса от клиента.Поскольку XHR в значительной степени зависит от протокола HTTP для связи, XHR следует правилам HTTP-соединения.Первое и самое важное правило: HTTP-соединения всегда инициируются клиентом.Другое правило: XHR возвращает все содержимое тела или завершается неудачей.

Последствия для вашего рабочего процесса заключаются в том, что каждая часть многоэлементного ответа должна запрашиваться клиентом индивидуально.

1. Из того, что я прочитал, я сомневаюсь, что тип контента подходит для ответа.многочастному / смешанная?многочастному / переваривать?

Вы должны сомневаться, поскольку в спецификации нет положений, чтобы сделать это.Атрибут response-type ограничен пустой строкой (по умолчанию), «arraybuffer», «blob», «document», «json» и «text». можно установить переопределение MIMEвведите заголовок, но это не меняет тип ответа.В этом случае в спецификации XHR очень ясно, что он отправит обратно.Это один из типов, перечисленных выше , как описано здесь.

Могу ли я использовать заголовок запроса на принятие, чтобы определить, способен ли клиент обрабатывать реализацию нового сервиса?Если да, то как правильно принять заголовок для этого?Мой план состоит в том, чтобы использовать ту же самую конечную точку, но очень принять заголовок.

Пользовательские HTTP-заголовки предназначены для того, чтобы помочь нам сообщить серверу о наших возможностях на клиенте.Это легко сделать.он не обязательно должен быть в заголовке accept (поскольку это также определенный список типов MIME).

Как мне разработать клиент XHR, который сможет обрабатывать многие части одного ответа, как только они станут доступны?Я нашел некоторые идеи в Интернете, но я не совсем уверен в этом.

XHR обрабатывается клиентом и не может быть переопределен по всем причинам безопасности.Так что вряд ли это будет доступно в качестве решения по этой причине.

Примечание: обычно можно предложить использовать пользовательскую версию Chromium, но ваши ограничения этого не позволяют.