完全 RESTful（包括 HATEOAS）客户端能否在客户端状态下存储服务器提供的 URI？答案

【问题标题】：Can a fully RESTful (including HATEOAS) client store a server-provided URI in client-side state?完全 RESTful（包括 HATEOAS）客户端能否在客户端状态下存储服务器提供的 URI？
【发布时间】：2012-12-01 00:31:00
【问题描述】：

（注意：我假设一个 REST 服务使用 URI 来识别资源，我知道这并不是 REST 的严格限制）

根据我对 HATEOAS 的理解，除了初始入口点之外，客户端不应假设服务提供的 URI 结构（而应仅使用服务器以结构化方式提供给它的 URI）。这是否意味着客户端只能使用最新请求提供给它的 URI，或者客户端可以跟踪从同一会话的早期请求中收到的 URI？如果是前者，后者会违反哪个 REST 约束？

跟踪 URI 的两个示例：

在照片查看应用程序中，我遍历照片列表，将一些照片的 URI 保存到列表中。然后，我导航到“马赛克”功能并将保存的 URI 中的所有照片加载到马赛克中。
我浏览了一个产品列表并将一些产品添加到我的客户端购物车中。完成后，我在 Orders 资源中创建一个新元素，其中产品按其 URI 指定的顺序排列。

【问题讨论】：

标签： rest hateoas

【解决方案1】：

我不确定你的开场白是什么意思：

注意：我假设一个 REST 服务使用 URI 来识别资源，我知道这并不是 REST 的严格限制

你的意思是超链接不必是 URI 吗？或者超链接不必指向资源？前者在技术上是正确的，但在 Internet 上，URI 是超链接的唯一形式，因此除非您正在考虑完全不同的东西，否则它们就是 URI。如果您说 REST 不需要 URI 标识资源，那么这是错误的。这正是他们在 RESTful API 中所识别的。总是。

不管怎样，继续你的问题：

这是否意味着客户端只能使用最新请求提供给它的 URI，或者客户端可以跟踪从同一会话的早期请求中收到的 URI？

是的，客户端可以缓存以前的响应。如果它们是“新鲜的”（根据 Expires 或 max-age 标头），那么客户端可以立即使用它们。如果它们是“陈旧的”（超过最大年龄/到期时间），则客户端可以使用条件请求（例如 If-Modified-Since）重新请求资源，但它不必这样做。

您的示例均不构成 REST 违规。相反，它们都是系统简单性的绝佳例子！

【讨论】：

我的意思是超链接不一定是 URI，尽管我从未真正见过使用另一种资源识别标准的 RESTful 系统。
This is a series of hypertext documents 以抄本的形式发布。他们使用 ID 号和人类可读的关系进行导航。我已经使用 IANA 链接关系 + 一些自定义 rel 将一个转换为 XHTML（未发表的作品，因为我不拥有权利）。状态保存在客户端，并在每次请求时以 Cookie 的形式提交。服务器使用这个传入的状态来改变传递的表示，以隐藏不可用的选项。（例如，如果你从未拿起它，它不会让你“喝药水”。）