У меня есть проект Symfony, который дает возможность мобильному приложению получать статьи с изображениями через API. API защищен и возвращает список статей. Одна из деталей статьи - фотография, хранящаяся вне Document Root, поэтому она недоступна из веб-браузера. Photo uri - это ссылка на контроллер Symfony, который проверяет, может ли вошедший в систему пользователь загрузить файл. Если да, используйте заголовки, чтобы вернуть изображение.
API выглядит так:
[
{
"id": 7,
"title": "Test",
"photo": "https://mypage.com/user/files/ewr23r23",
"version: 2,
"status": "n"
},
{
"id": 9,
"title": "Foo",
"photo": "https://mypage.com/user/files/h24t54ef",
"version: 4,
"status": "m"
}
]
Таким образом, мобильное приложение запрашивает артикулы через API (1 запрос). Затем загружает фотографии. Итак, если у нас есть 10 статей, у нас есть 11 запросов. 10 для фотографий и 1 для API. Вы знаете какое-нибудь решение, которое бы это оптимизировало? Чтобы было меньше запросов? Мы используем управление версиями, поэтому при загрузке мобильного приложения через API изменяется не весь список статей, а только его.






Поскольку ваш API доступен для мобильного приложения, вы можете использовать расширение PHP ZIP (документация здесь), чтобы объединить все свои изображения в один Zip-файл, который вы затем загрузите и распакуйте с помощью клиентского приложения.
На мой взгляд, лучший способ сделать это - реализовать Контроллер, который будет принимать в качестве аргумента список изображений и возвращать zip-файл. Мы, вероятно, сможем кэшировать эти файлы (как на стороне клиента, так и на стороне сервера), чтобы сэкономить немного вычислительной мощности.
Вы могли бы объединить файлы «на лету» с контроллером, который принимает в качестве параметра список файлов, но вам нужно будет решить, какой вариант вы предпочитаете, чтобы оптимизировать количество запросов или нагрузку на сервер, потому что такая операция может быстро стать дорогим
Точно. Не знаю, что дороже за весь комплект ЛАМПЫ. 5 запросов для API (загрузить Symfony, проверить учетные данные с помощью запроса Doctrine) и 4 изображения или 1 запрос и заархивировать 5 файлов. А что насчет 100 изображений. Даже не знаю, как это проверить.
Если ваши изображения достаточно статичны, кеширование на стороне клиента - это хорошо, но, честно говоря, попытка уменьшить количество запросов в некотором роде контрпродуктивна, простой запрос файла - ничто для сервера, в то время как объединение и сжатие - это огромное дело.
Это был бы хороший вариант, если бы у нас был статический список статей. Но мы обновляем его, поэтому не загружаем все статьи каждый раз. Я обновил вопросы по этому поводу.