【问题标题】：ActiveStorage : Why not using service_url instead of blob/variant/preview url (302 redirect)?ActiveStorage：为什么不使用 service_url 而不是 blob/variant/preview url（302 重定向）？
【发布时间】：2019-02-11 17:57:07
【问题描述】：

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

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 重定向获取最终资产 url。所以一页有 20 张图片 => 20 个额外的请求。（但它们很快）

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

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

我正在考虑这些论点：（但还有其他的吗？）

blob_url 可以被缓存在服务器端，因为它是永久的（例如：片段缓存）
blob_url 可以通过身份验证来保护，这意味着可以共享唯一的 url，但有人需要身份验证才能看到资产，例如（通过修改 rails blob 控制器）
也许是第三个？更好的缓存浏览器端？浏览器是否能够使用永久 url 缓存图像数据？即使亚马逊网址有 5 分钟的过期时间？

【问题讨论】：

还能够在不杀死所有缓存存储的情况下切换提供程序（aws、google、azure）

标签： ruby-on-rails http http-headers cache-control rails-activestorage

【解决方案1】：

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

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

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

间接有优势

在用户和文件之间使用 Rails 应用程序有几个好处（其中一些在 OP 中提到）：

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

来自Active Storage guide：

这种间接方式将公共 URL 与实际 URL 分离，并允许例如在不同服务中镜像附件以实现高可用性。

关于直接访问文件的争论

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

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

【讨论】：