问REST购物车

EN

将购物车作为资源存储在服务器上没有任何问题。它是应该存储在客户端上的会话状态。https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

为了实现无状态，购物车URI应该能够识别唯一的购物车，而不需要依赖任何会话信息。

例如，除非在整个应用程序中只有一个购物车，否则/shopping-cart可能是不够的。

很可能，每个用户至少会有一个购物车。所以，你可以使用像/user/1234/shopping-cart或/shopping-cart?userID=1234这样的东西。

更有可能的是，每个用户可能需要多个购物车。因此，您需要为购物车提供一个惟一的ID，如/user/1234/shopping-cart/5678或/shopping-cart/5678。

重点是，处理请求所需的一切都应该在请求中。

在REST应用程序中，会话状态完全由客户端管理，请求必须包含服务器能够理解的所有必要信息。例如，如果服务器需要身份验证，则每个请求都必须包含凭据。

REST stateless constraint的定义如下：

5.1.3无状态

..。从客户端到服务器的每个请求都必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。因此，会话状态完全保留在客户端上。..。

然而，无状态约束并不意味着服务器不应该存储任何数据。

在会话状态由服务器管理的应用程序中，在HTTP会话中存储购物车数据是一种常见的方法。但是购物车不是会话状态。而且，它可能不应该完全由客户端管理。

在REST中，购物车可以是由/shopping-cart之类的URL标识的资源，并且可以在其上执行操作。所有购物车数据都可以持久化到服务器上的数据库中。

Any information that can be named can be a REST resource，甚至是购物车：

5.2.1.1资源和资源标识符

REST中信息的关键抽象是一种资源。任何可以命名的信息都可以是资源:文档或图像、时间服务(例如“今天洛杉矶的天气”)、其他资源的集合、非虚拟对象(例如人)等等。换句话说，任何可能成为作者超文本引用目标的概念都必须符合资源的定义。资源是到一组实体的概念映射，而不是在任何特定时间点对应于映射的实体。..。

您可以在购物车上执行以下操作：

• GET /shopping-cart：获取购物cart.
• POST /shopping-cart：将项目添加到购物车中(发送一些数据以及您正在添加的项目和请求中的金额body).
• DELETE /shopping-cart/1：从购物cart.
• PATCH /shopping-cart：中移除具有id 1的项目更新购物车(发送一些要在请求中更新的数据body).
• PUT /shopping-cart：替换购物车的整个内容(发送一些数据和购物车的内容在request body).
• DELETE /shopping-cart：中删除购物车，订购购物车cart
• POST /shopping-cart/order：

因此，请注意客户端在任何时候都不会存储有关购物车的任何信息。所有与购物车相关的信息都将存储在服务器中。

有关REST的更多信息，我建议您阅读RoyT.Fiding的dissertation的chapter 5。

关于REST存在很多混淆，因为许多人听说过REST约束，并认为它们是应用规则，除了遵循体系结构本身作为目的之外，没有任何原因。

你应该问的真正问题是，为什么REST中存在无状态约束，以及遵循它有什么好处。请记住，REST是一种架构风格，用于大规模分布式系统的长期发展。在一个只有一个数据库保存所有信息的小规模应用程序中，REST应该解决不了的问题。

无状态约束具有可视性、可靠性和可扩展性。可见性得到了提高，因为监视系统不必为了确定请求的完整性质而查看单个请求数据之外的内容。可靠性得到了提高，因为它简化了从部分故障中恢复的任务。可伸缩性得到了提高，因为不必在请求之间存储状态，从而允许服务器组件快速释放资源，并且进一步简化了实现，因为服务器不必管理跨请求的资源使用情况。

因此，无状态意味着客户端请求应该具有处理它所需的所有信息。

可见性对你有多重要？您是希望在调试时能够从客户端请求中看到购物车的全部内容，还是愿意从数据库中获取这些信息？

可靠性有多重要？您是否有一个具有多个服务器和数据库的大型分布式系统，这很重要？如果您有一个大型分布式系统，其中购物车信息可能存储在不同的数据库中，这取决于响应请求的确切HTTP服务器，如果服务器发生故障，则只有该组中的另一台服务器能够满足请求并完成会话，或者另一组中的服务器将强制客户端重新启动会话。如果所有信息都包含在请求中，那么任何服务器都可以这样做。

可伸缩性有多重要？如果您有一个分布式系统，并且您将购物车信息存储在单个数据库上，那么它将成为所有请求的漏斗，并且您将失去可伸缩性。如果您将其存储在多个数据库中，则会失去如上所述的可靠性。

那么，你是否有雄心勃勃的长期目标，或者你的应用程序是否足够大，以至于你将面临REST试图解决的问题？如果您总是有几个服务器和一个数据库，并且您将对每个单独的请求使用它，那么您是否变为无状态并不重要。您可以只拥有一个/shopping_cart资源或类似的东西，使用POST请求向其添加内容，并在完成后关闭或删除它。

如果您希望跨多个数据库、大量响应请求的HTTP服务器、缓存服务器等对数据进行分片，并且希望能够通过在需要时设置新的服务器并在负载减少时删除它们来动态提供容量，那么完全无状态，并将购物车留给客户端。