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

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

的HTML：

服务器：

Started GET "/rails/active_storage/blobs/eyJfcmFpbH...
302 Redirected to https://img.php1.cn/3cd4a/1eebe/cd5/2fdc212433a29829.png?X-Amz-Algorithm=AWS4-HMA...

我想知道Active Storage正在向整体中添加HTTP请求的数量，网页中的一个blob_url =向整体中的另一个请求，以便通过302重定向获取最终的资产url。因此一页包含20张图像=> 20个附加请求。（但它们很快）

所以我的问题是：为什么使用此系统而不是直接使用最终URL（.service_url）：

？

我在想这些论点：（但是还有其他吗？）

blob_url可以在服务器端进行缓存，因为它是永久的（例如：fragment caching）

blob_url可以通过身份验证进行保护，这意味着可以共享唯一的url，但是有人需要进行身份验证才能看到资产（例如，通过修改rails blob控制器）

也许是第三个？在浏览器端更好地缓存？浏览器是否能够使用永久URL缓存图像数据？即使亚马逊网址的有效期为5分钟？

Carlos Ramir.. 5

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

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

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

在用户和文件之间使用Rails应用程序会带来很多好处（在OP中提到了其中的一些好处）：

可以通过身份验证保护文件

快取

镜射

从Active Storage指南中：

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

有关通过Active Storage Service API提取文件访问的利弊的更多讨论，请查看以下线程：

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

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

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

在用户和文件之间使用Rails应用程序会带来很多好处（在OP中提到了其中的一些好处）：

可以通过身份验证保护文件

快取

镜射

从Active Storage指南中：

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

有关通过Active Storage Service API提取文件访问的利弊的更多讨论，请查看以下线程：

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