Блог

Главная - Вопросы по программированию - Конечная точка REST для извлечения нескольких изображений

Конечная точка REST для извлечения нескольких изображений

#rest #http #mime-types

Вопрос:

Моему веб — приложению требуется конечная точка REST GET /products , семантика которой заключается в извлечении набора продуктов из каталога продуктов. Каждый продукт имеет набор атрибутов, включая изображение в формате PNG:

 [
    {
        productId: 123, 
        name: "boat", 
        image: "\x89504e470d0a1a0..."   <-- PNG retrieved from PostgreSQL bytea 
    },
    {
        productId: 456, 
        name: "helicopter", 
        image: ...
    }
    ... and many more
]

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

 [
    {
        productId: 123, 
        name: "boat", 
        image: { 
            href: "/product/123/image <-- GET response to this resource has Mime-Type image/png
        }
    },
    {
        productId: 456, 
        name: "helicopter", 
        image: { 
            href: "/product/123/image <-- GET response to this resource has Mime-Type image/png
        }
    }
    ... and many more
]

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

Существует ли наилучшая практика для встраивания нескольких изображений в один ответ json с правильным типом Mime?

Комментарии:

1. Накладные расходы на встраивание изображений в файл JSON будут намного хуже, чем просто использование большего количества HTTP-запросов. Браузеры повторно используют TCP-соединения с HTTP/1.1, и только 1 будет использовать TCP-соединение для многих запросов с HTTP/2. Это кажется ужасной идеей.

2. У вас проблемы с производительностью или вы думаете, что это возможно? Веб-сайты используют изображения, это нормально 😛

3. @Evert спасибо за подсказку с HTTP/2. Я помню, что в 2010-х годах объединение активов было обязательным для высокопроизводительных веб-приложений. С появлением HTTP/2, похоже, происходит обратное ( speedboostr.com/concatenation-case-study ). У меня пока нет проблем с производительностью, но мне нужно разработать систему, которая может обслуживать 10 одновременных пользователей, которые загружают 100 изображений продуктов (каждое ~ 100 КБ) менее чем за 2 секунды по мобильной сети со скоростью 10 Мбит/с (=1,25 Мбит / сек). Теперь, если я буду продолжать загружать изображения по одному, база данных может стать узким местом. Но 33% трафика из-за base64 тоже не очень хорошо

4. Я бы настоятельно рекомендовал вам делать все «правильно», прежде чем думать о стратегиях оптимизации, которые могли бы выжать из этого немного больше скорости в обмен на гораздо худший API. Измеряйте, улучшайте, повторяйте.

Ответ №1:

Существует ли наилучшая практика для встраивания нескольких изображений в один ответ json с правильным типом Mime?

Похоже, что вы ищете схему URL-адреса «данные» (RFC 2397), которая позволяет указать тип носителя как часть URL-адреса.

 data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ 5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7
Метки: