假设您有一个完全超媒体驱动的 API。消费者必须通过跟随超媒体导航三个资源,直到他们能够获得他们想要的资源。客户端是否有任何原因无法临时缓存这些步骤并直接访问他们想要的资源?
我知道 REST 的目标是解耦客户端和服务器,但是如果您有 5 个 Web 请求在幕后进行,那么等待所有这些发生的用户体验可能会很差。
我能想到的最坏情况是缓存的 URL 被更改。因此客户端将再次从入口点开始并缓存这些步骤。
假设您有一个完全超媒体驱动的 API。消费者必须通过跟随超媒体导航三个资源,直到他们能够获得他们想要的资源。客户端是否有任何原因无法临时缓存这些步骤并直接访问他们想要的资源?
我知道 REST 的目标是解耦客户端和服务器,但是如果您有 5 个 Web 请求在幕后进行,那么等待所有这些发生的用户体验可能会很差。
我能想到的最坏情况是缓存的 URL 被更改。因此客户端将再次从入口点开始并缓存这些步骤。
对于许多性能良好的超媒体客户端来说,客户端缓存将非常重要。以下是直接来自菲尔丁论文的一些更具体的指导:
添加缓存约束的好处是它们有可能部分或完全消除一些交互,通过减少一系列交互的平均延迟来提高效率、可扩展性和用户感知的性能。然而,权衡是,如果缓存中的陈旧数据与将请求直接发送到服务器时获得的数据有很大差异,缓存会降低可靠性。
这是权衡,但如果缓存的时间短,将大大提高性能。理想情况下,超媒体 API 将提供缓存指导。这可以通过 HTML 缓存与浏览器以及 Expires 和 Cache-Control 标头一起使用的相同方式完成。
此外,如果资源已移动,则 API 应通过正确的 301 Moved Permanently 响应通知您。