Stefan Tilkov 在这里发表演讲，他在其中描述了 REST 架构的核心。我还没有全部看完，但是在他谈到 REST 的 5 条原则的部分（幻灯片 12-19）中，他提到了通过资源（即 URI）维护状态。他的例子是购物车。通常您的购物车状态会在会话中维护，但他会发表评论（在此解释）这是一个不正确的接口实现，因为您无法将会话“发送”给同事，但您可以发送资源状态，然后它将在您的购物车中包含所有物品。我发现这个概念很有趣，我想知道是否有人有任何额外的信息、资源、链接、视频等，实际上讨论了这类事物的架构实现（最好是在 Java 中）。谢谢！
编辑：
抱歉，我将在这里做一个简短的编辑——我不是在谈论想要关于 REST 实现本身的信息，而是想要在会话/数据库状态上广泛使用资源状态的缺点/优点。
对会话状态的缺点最清楚的解释之一直接来自 Roy Fielding 的论文，他在论文中介绍了 REST。（重点是我的）
我们接下来为客户端-服务器交互添加一个约束：通信本质上必须是无状态的，如第 3.4.3 节（图 5-3）的客户端-无状态-服务器 (CSS) 样式，这样 从客户端到的每个请求server 必须包含 理解请求所需的所有信息， 并且不能利用 服务器上存储的任何上下文。
因此，会话状态完全保留在客户端上。
这种约束引入了可见性、可靠性和可扩展性的属性。
可见性得到提高，因为监控系统不必超越单个请求数据来确定请求的全部性质。
可靠性得到了提高，因为它简化了从部分故障中恢复的任务[133]。
可伸缩性得到了改进，因为不必在请求之间存储状态允许服务器组件快速释放资源，并进一步简化了实现，因为服务器不必跨请求管理资源使用。
Roy 继续说，这种约束的应用是一种设计权衡，这种选择会产生负面影响。
一旦您选择不在应用程序架构中使用会话状态，那么您就只能以两种方式之一来维护购物车之类的东西。购物车要么完全由客户端应用程序维护，要么存储为资源状态。使某物成为 Resource 的原因是它由 URI 标识，并且可以由接口的标准动词操作。如果您确实将购物车存储为资源，那么正如 Stefan 所说，您可以将资源的链接发送给同事。使用这种方法，可以像执行任何其他资源一样实现购物车。
我想知道是否有人有任何其他信息、资源、链接、视频等，实际上讨论了这类事情的架构实现（最好是在 Java 中）。谢谢！
就这一点而言，一个“友好的 url 控制器”就足够了。创建一个过滤器和/或 Servlet，它提取HttpServletRequest#getRequestURI()or HttpServletRequest#getPathInfo()，使用 REST 数据创建一些 javabean，使用命令模式采取相应的行动，最后转发到有问题的 JSP 页面以呈现数据。
请记住，URL 的长度受限于某些边界，这取决于所使用的网络浏览器和网络服务器。我建议不要超过 255 个字符。如果您确实需要在 URL 中存储更多信息，请考虑对其进行 GZipping 和 Base64 编码并将其附加到 URL 的末尾，例如http://example.com/cart/2j34hfg5jh2g5bnvcnb2vc452. 它不会使 URL 更具可读性，不，但它可以工作并且您可以传递大量信息。