Является ли хорошей идеей объединить несколько HTTP-запросов для экономии пропускной способности?

Я готовлю одностраничное приложение, которое иногда будет использоваться по медленной мобильной связи. Некоторые из его частей довольно тяжелы с точки зрения запросов API (выборка десяти различных ресурсов для нового отображения экрана).

Теперь, является ли хорошей идеей объединить эти сервисы с сервисом, который предоставляет все необходимые данные, но не настолько «чист» с точки зрения принципов REST? Ожидается ли значительный прирост производительности?

Одним из преимуществ REST является возможность кэширования запросов через традиционные http-кэши (при условии, что это кешируемые запросы).

Когда у вас есть одиночные, большие, менее часто используемые и, возможно, другие запросы (я собираюсь выбрать элементы на a,b,c,dэтот раз и элементыa,b,d,e следующий раз), вы повышаете вероятность того, что запрос будет пропущен, и срок его действия истек из кэша, который может быть сидя где-то между вами и источником.

Учитывая два набора запросов , указанных выше, второй запрос может иметь 75% кэш хит скорости и быть значительно быстрее , выборка простоe , а не все четыре вещи.

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

Это не значит, что он был бы идеальным для подключения к мобильной сети, где вероятность получения нелокальных попаданий в кэш менее высока. Но для горячих точек или других ситуаций с Wi-Fi, попадание в кэш может быть гораздо более полезным.

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

Идеально было бы проверить это, чтобы увидеть, как ваше приложение преформируется в различных ситуациях. Подумайте о том, чтобы настроить ситуацию, когда вы привязали свое мобильное устройство к локальной сети Wi-Fi, которую вы можете отслеживать (это только первый удар в Google), и смоделировать плохое подключение к Интернету, чтобы увидеть, как на самом деле все работает (или нет). и какой из них имеет лучшую производительность.

Ваша интуиция в некоторой степени правильна - в целом, делать меньше запросов, безусловно, предпочтительнее; коренастые API, как правило, лучше. Особенно с точным подключением, когда вы можете увидеть некоторые работы, а некоторые не в состоянии создать кошмарные сценарии отступления, поскольку ничто не может полагаться ни на что.

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

Или вы, вероятно, захотите сделать это обоими способами.

Проверьте эту статью Dropbox Tech Blog .

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

Краткое содержание:

Веб-сайт Dropbox должен загружать сотни миниатюр. Из-за ограничений в некоторых браузерах не все миниатюры загружаются параллельно (запросы помещаются в очередь). Они хотели использовать SPDY , но не смогли этого сделать, потому что части их системы еще не поддерживают его. В конце они использовали пакетные запросы по HTTP, которые возвращали несколько миниатюр на ответ в сжатой форме. Общее время загрузки страницы составило 40% по результатам.

Короче говоря: ваш подход несколько верен и может быть полезен для Сервиса-оболочки

Этот сервис объединит существующие одиночные вызовы в один метод на стороне сервиса. Делайте это, комбинируя вызовы от клиента к сервисной стороне и используя все отдельные, атомарные, спокойные вызовы, которые вы, вероятно, уже сделали.

Таким образом, вы по-прежнему будете получать выгоду от REST как возможность кеширования запросов.

Однако в конечном итоге все сводится к производительности инфраструктуры службы / сервера и клиентской среде, которая должна его потреблять.