REST API с изображениями

Question

Я нахожусь в процессе создания REST API приложения для изображений, которое будет использоваться Angular Frontend. API создается с использованием PHP. Все изображения надежно хранятся вне webroot.

Проблема в том, что я конвертирую все свои изображения в base64, это увеличивает полезную нагрузку, в некоторых случаях у меня отображается 40 изображений на странице, нередко ждать 30-40 секунд из-за огромной полезной нагрузки.

Каков наилучший способ представления изображений с помощью REST API? Я обыскал, нет ничего, что точно решает проблему. Код ниже. Изображения base64 увеличивают полезную нагрузку на невероятную сумму. Любые указатели, пожалуйста.

//create presentation array
$presentation_arr=array();
$presentation_arr["records"]=array();
$LargeImageName = $slideName;
$LargefileDir = $largefolder. $fileid . '/';
$Largefile = $LargefileDir . $LargeImageName;

if (file_exists($Largefile)){
    $b64largeImage = base64_encode(file_get_contents($Largefile));
    $datafullpath = 'data:image/jpg;base64,$b64image';
}

$presentation_item=array(
    "id" => $id,
    "smallimage" => $b64image,
    "largeimage" => $b64largeImage
);

array_push($presentation_arr["imagerecords"], $presentation_item);

Answer 1

Два подхода:

• Создайте конечную точку «обертки», которая является просто прокси для самого конечного изображения (например, выполняет readfile() внутренне, см. Это: https://stackoverflow.com/a/1353867/1364793)
• Размещайте изображения в статической, доступной через Интернет папке (или даже рассматривайте S3 как хранилище для статических ресурсов). Затем ваша основная конечная точка просто возвращает общедоступные URL-адреса для них.

Answer 2

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

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

Чтобы повысить производительность на стороне сервера,вы можете кэшировать закодированную версию;Вы можете записать $ b64largeImage на диск в том же каталоге, проверить, существует ли он, и отправить его клиенту.

Чтобы сократить время передачи, убедитесь, что на сервере включен GZIP;это должно сжать ваши данные.

Однако производительность на стороне клиента останется проблемой - ваши изображения, скорее всего, будут кэшироваться не на клиенте, а декодировать изображения (особенно если их 40).на каждой странице) может потреблять приличное количество ресурсов ЦП (особенно на мобильных устройствах).

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

Конечно, вы можете не захотеть, чтобы третьи лица встраивали ваши изображения на их страницы, или вы можете захотетьчтобы они не соскребали ваши изображения.

В этом случае вы можете сосредоточиться на том, чтобы URL-адреса трудно / невозможно угадать или срок их действия истек.Это повредит вашему SEO, так что это компромисс.S3 имеет URL-адреса с истекшим сроком действия, или вы можете создать службу, которая проверяет реферер для каждого запроса и обрабатывает только запросы изображений из доменов, занесенных в белый список, или создать собственную службу URL-адресов с истекающим сроком действия - но в каждом случае вы будете использовать JPEG / GIF/ PNG изображения, так что вы получите небольшой размер файла и ограниченное время декодирования.