stefan tilkov在这里做了一个演讲，他描述了rest架构的核心。我还没有看过全部内容，但在他谈到rest的5个原则的部分（幻灯片12-19），他提到了通过资源（即uri）维护状态。他的例子是购物车。通常你的购物车的状态是在会话中维护的，但是他评论说这是一个不正确的接口实现，因为你不能将你的会话“发送”给同事，但是你可以发送资源状态，这样你的购物车中就会有所有的项目。我发现这个概念很有趣，我想知道是否有人有任何额外的信息、资源、链接、视频等，来讨论这类东西的体系结构实现（最好是用java）。谢谢！
编辑：
抱歉，我将在这里做一个简短的编辑——我不是想了解rest实现本身的信息，而是想了解实际广泛使用资源状态而不是会话/db状态的缺点/优点。
2条答案
按热度按时间p1iqtdky1#
我想知道是否有人有任何额外的信息、资源、链接、视频等，来讨论这类东西的体系结构实现（最好是用java）。谢谢！
关键是，一个“友好的url控制器”就足够了。创建一个过滤器和/或servlet来提取
HttpServletRequest#getRequestURI()或者HttpServletRequest#getPathInfo()，使用rest数据创建一些javabean，使用命令模式采取相应的操作，最后转发到相关的jsp页面以显示数据。请记住，url的长度仅限于特定的边框，这取决于所使用的webbrowser和webserver。我建议不要超过255个字符。如果您真的需要在url中存储更多信息，请考虑gzip和base64编码，并将其附加到url的末尾，例如
http://example.com/cart/2j34hfg5jh2g5bnvcnb2vc452. 它并没有使url更可读，不，但它可以工作，你可以传递很多信息。rkkpypqq2#
会话状态的缺点的一个最清晰的解释直接来自royfielding的论文，他在论文中介绍了rest(重点是我）
接下来，我们将为客户机-服务器交互添加一个约束：通信本质上必须是无状态的，如第3.4.3节（图5-3）中的客户机无状态服务器（css）样式，这样从客户机到服务器的每个请求都必须包含理解请求所需的所有信息，并且无法利用服务器上存储的任何上下文。
因此，会话状态完全保留在客户机上。
这个约束会产生可见性、可靠性和可伸缩性等特性。
可见性得到了提高，因为监视系统不必为了确定请求的全部性质而超越单个请求数据。
可靠性得到了提高，因为它简化了从部分故障中恢复的任务[133]。
可伸缩性得到了改进，因为不必在请求之间存储状态，服务器组件可以快速释放资源，并进一步简化了实现，因为服务器不必跨请求管理资源使用情况。
罗伊继续说，应用这个约束是一种设计权衡，这种选择有负面影响。
一旦您选择在应用程序体系结构中不使用会话状态，那么您就只能通过以下两种方式之一维护购物车之类的东西了。购物车要么完全由客户机应用程序维护，要么存储为资源状态。使某物成为资源的原因是它由uri标识，并且可以由接口的标准 predicate 进行操作。如果您将购物车存储为资源，那么正如stefan所说，您可以向同事发送指向该资源的链接。使用这种方法，购物车可以像实现任何其他资源一样实现。