Почему код загрузки blobstore имеет URL перенаправления

Я полагаю, что процесс использования blobstore для сохранения изображений заканчивается тем, что сохраняет ключ blob в хранилище данных. Итак, в следующем коде, который должен быть в моем бэкэнд, почему мне нужен URL-адрес перенаправления, так как у меня уже есть ключ blob? Почему бы мне не просто сохранить ключ blob в моем хранилище данных, а затем вернуть его?

public class Upload extends HttpServlet { private BlobstoreService blobstoreService = BlobstoreServiceFactory.getBlobstoreService(); public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { Map<String, BlobKey> blobs = blobstoreService.getUploadedBlobs(req); BlobKey blobKey = blobs.get("myFile"); if (blobKey == null) { res.sendRedirect("/"); } else { res.sendRedirect("/serve?blob-key=" + blobKey.getKeyString()); } } } 

Этот код из учебника: https://developers.google.com/appengine/docs/java/blobstore/overview#Complete_Sample_App

Solutions Collecting From Web of "Почему код загрузки blobstore имеет URL перенаправления"

Поскольку Google хранит изображения на другой службе (также используется Picassa). Целью является оптимизация хранилища и предоставление разработчику некоторых инструментов для легкого управления этими изображениями.

См. Эту ссылку в документации, чтобы узнать, что вы можете сделать: https://developers.google.com/appengine/docs/java/images/overview

Чтобы избежать перенаправления, вы должны использовать этот метод для обслуживания изображений: getServingUrl ()

Из документации:

Метод getServingUrl () позволяет вам создавать стабильный выделенный URL-адрес для обслуживания эскизов изображений в Интернете. Вы просто сохраняете единственную копию исходного изображения в Blobstore, а затем запрашиваете высокопроизводительный URL-адрес для каждого изображения. Этот специальный URL-адрес может служить для изменения размера и / или обрезания изображения автоматически, а обслуживание с этого URL-адреса не несет никакой нагрузки на процессор или динамическую нагрузку на ваше приложение (хотя пропускная способность по-прежнему взимается, как обычно). Изображения подаются с низкой задержкой из высоко оптимизированной, без печей инфраструктуры.