ruby-on-rails - 事件存储 : Why not using service_url instead of blob/variant/preview url (302 redirect)?

Question

在 Rails 5.2 中，Active Storage 使我们能够生成永久 url，这些 url 在每次调用时通过唯一的签名 url 重定向到 Assets 。

html: <img src='/rails/active_storage/blobs/ey...' />

服务器:

Started GET "/rails/active_storage/blobs/eyJfcmFpbH...
302 Redirected to https://bucket.amazon/image.jpg?X-Amz-Algorithm=AWS4-HMA...

我想知道 Active Storage 添加到单体的 HTTP 请求数量，网页中的一个 blob_url = 对单体的一个额外请求，以便通过 302 重定向获得最终 Assets url。所以一页有 20 张图片 => 20 个额外的请求。 (但他们相当快)

所以我的问题是:为什么使用这个系统而不是直接使用最终 URL (.service_url):

<img src='https://bucket.amazon/image.jpg?X-Amz-Algo...'> ？

我正在考虑这些论点:(但还有其他论点吗？)

• blob_url 可以在服务器端缓存，因为它是永久(例如:片段缓存)
• blob_url 可以通过身份验证进行保护，这意味着唯一的 url 可以共享，但是有人需要身份验证才能看到 Assets ，例如(通过修改 rails blob Controller )
• 也许是第三个？更好地缓存浏览器端？浏览器是否能够使用永久 url 缓存图像数据？即使亚马逊网址有 5 分钟的有效期？

Answer 1

Active Storage默认为文件添加了一层抽象

Active Storage 开箱即用的行为是生成指向 Rails 应用程序的 URL。访问时，这些 URL 重定向到文件的实际服务端点。

这确实增加了对 Rails 应用服务器的请求数量，因为所有文件访问都需要通过那里。

间接有优势

在用户和文件之间放置 Rails 应用程序有几个好处(OP 中提到了其中一些):

• 文件可以通过身份验证来保护
• 缓存
• 镜像

来自Active Storage guide :

This indirection decouples the public URL from the actual one, and allows, for example, mirroring attachments in different services for high-availability.

关于直接访问文件的争论

有关通过 Active Storage Service API 抽象文件访问的优缺点的更多讨论，请查看此线程:

https://github.com/rails/rails/issues/31419