Це гарна ідея об'єднати кілька запитів HTTP, щоб зберегти пропускну здатність?

Я готую додаток на одній сторінці, який інколи використовувався б через повільний мобільний зв’язок. Деякі його частини є досить важкими з точки зору запитів API (отримання десяти різних ресурсів для нового екранного екрану).

Тепер, чи гарна ідея об'єднати ці служби з послугами, що надають усі необхідні дані, але не настільки "чисті" з точки зору принципів REST? Чи варто очікувати значного підвищення продуктивності?

Однією з переваг REST є можливість кешування запитів за допомогою традиційних кеш-адрес http (якщо припустити, що це кешовані запити).

Коли у вас є поодинокі, більші, рідше використовувані та, можливо, різні запити (я збираюсь отримати предмети на a,b,c,dцей раз та предметиa,b,d,e наступні рази), ви зробите цей запит більш імовірним пропуском кешу і закінчується термін дії кешу, який може бути сидячи десь між вами та джерелом.

З огляду на два набори запитів, згаданих вище, другий запит може мати 75% частоти звернень до кеш-пам'яті і бути значно швидшим вилученням просто e, ніж усі чотири речі.

Зауважте, що це може виявитись не відразу людям, які використовують його, оскільки особа, яка робить перший набір запитів пропустити кеш, все одно матиме пропуски кешу.

Це не означає, що було б ідеально підключення до мобільної мережі, де менше шансів отримати не локальні кешові звернення. Але для гарячих точок або інших ситуацій з Wi-Fi хіти кешу можуть бути набагато кориснішими.

Значна частина цього, знову ж таки, залежить від того, як працює ваша програма. Це запитує всі ці дані при запуску? чи ми говоримо про завантаження сторінки, де очікування часу відгуку різні?

Ідеальною справою було б перевірити це, щоб побачити, як ваша програма працює в різних ситуаціях. Подумайте про те, щоб налаштувати ситуацію, коли ви прив’язали свій мобільний пристрій до локальної мережі Wi-Fi, яку ви можете відстежувати (це лише перший удар у google) та імітуєте невдале підключення до Інтернету, щоб побачити, як все насправді працює (чи ні) і яка з них найкраща.

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

Є одне велике застереження - ви можете отримати занадто прискіпливий характер, і ваші дзвінки та відповіді роздуються. Наприклад, може мати сенс здійснити один великий дзвінок, коли ви вперше потрапляєте на сторінку, а потім отримуєте потік оновлень меншими шматочками, а не примушувати оновлення великої сторінки щоразу, коли вам потрібні дані.

Або ви хочете зробити це обома способами, по всій ймовірності.

Ознайомтеся з цією статтею Blog Blog про Dropbox Tech .

Там вони докладно описують, чому і як саме вони реалізували рішення, яке ви запропонували для отримання ескізів для всіх ваших фотографій. Слід сказати, що вони вимірюють продуктивність, щоб побачити, чи варто турбуватися, і, мабуть, це так.

Короткий підсумок:

На веб-сайт Dropbox потрібно завантажити сотні мініатюр. Через обмеження в деяких браузерах не всі ескізи завантажуються паралельно (запити стоять у черзі). Вони хотіли використовувати SPDY , але не змогли цього зробити, оскільки частини їх системи ще не підтримують його. Зрештою, вони використовували пакетні запити через HTTP, які повертають кілька ескізів на відповідь у стислий формі. Загальне поліпшення часу завантаження сторінки склало 40% за їх результатами.

Коротше кажучи: Ваш підхід дещо правильний і може скористатися послугою обгортки.

Ця послуга поєднує наявні одиничні дзвінки в один метод обслуговування. Робіть це, комбінуючи дзвінки від клієнта до сервісної сторони та використовуючи всі одинакові, атомні, спокійні дзвінки, які, напевно, у вас вже є.

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

Однак у кінцевій точці все зведеться до продуктивності сервісної / серверної інфраструктури та клієнтського середовища, яке повинно її споживати.