ActiveStorage：为什么不使用service_url而不是blob / variant / preview url（302重定向）？

Question

在Rails 5.2中，Active Storage使我们能够生成永久URL ，该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分钟？

Answer 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