从可扩展性、性能、
我只是想知道我关于 REST 的想法是否正确。假设我们有一个购物网站。使用传统方法，购物车将存储在用户会话中，以便服务器必须管理用户的许多项目（用户#1：项目1，项目2，项目3；用户#2：项目A，项目B，项目3，...） 。因此，如果有超过一千个用户浏览网站并将商品添加到购物车，则服务器必须拥有大量内存/计算能力。
在 REST 方法中，没有会话，因此客户端拥有有关购物车中商品的所有信息。这意味着服务器不需要这么大的内存要求，我可以轻松扩展它。
现在，如果我将非 REST 方法中的一个项目添加到购物车中，它将直接进入会话。另一方面，如果我在 REST 方法中添加一个项目，我必须更新数据库中的实体 (/shoppingcart/1234/)，这将需要更长的时间，因为我必须更深入一层（客户端- >服务器->数据库）。
到目前为止这是正确的还是我遗漏或误解了一点？
I just want to know if my thoughts concerning REST are right. Let's imagine we have a shopping site. With a conventional approach the shopping cart would be stored in the users session so that the server has to manage many items for user( User#1: item1, item2, item3; User#2: itemA,itemB, item3,...). So the server has to have lots of memory/computing power if there are more than a thousand users browsing on the site and adding items to their shopping cart.
In a REST approach there is no session, so the client has all information about the items in the shopping cart. This means that the server doesn't need to have such big memory requirements and I can easily scale this.
Now if I add an item in the non-REST-approach to the shopping cart it would go directly into the session. On the other hand, if I add an item in the REST-approach, I have to update the entity in the database (/shoppingcart/1234/) and this would take a bit longer since I have to go one level deeper (client->server->database).
Is this correct so far or am I missing or misunderstanding a point?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
REST 无状态约束并不意味着客户端需要跟踪购物车中商品的所有信息（请不要这样做）。但这确实意味着购物车的状态是可寻址的（客户端拥有服务请求所需的所有信息）。
考虑以下 URL：
/shopping-cart/john.howes
我对无状态约束的理解是，如果我或你或任何人导航到该链接，我们将获得相同资源的一些表示（假设我们有权查看它） ）。它可能是 XML、JSON 或 HTML，也可能是英语或法语，但底层资源是相同的。如果我将该 URL 加入书签并稍后在另一台设备上查看它或通过电子邮件将其发送给朋友，我们将获得相同的资源（假设它仍然存在并且我们有权查看它）。
因此，因为我有一个指向 /shopping-cart/john.howes 的链接，所以我拥有了满足该请求所需的所有信息。
我认为，无论您是否使用 REST，向会话状态添加大型对象都会导致灾难（对于可维护性、可扩展性和完整性）。所以，我会硬着头皮使用数据库。我认为你基本上是对的：REST 并没有过多说明数据如何存储在服务器上，但它确实意味着你不会将用户会话的当前状态存储在 Web 服务器的内存中。我认为您有很多优化性能的选择。让一切都在会话中并不是一个很好的选择。
我希望这有帮助。
约翰
The REST statelessness constraint doesn't imply that the client needs to keep track of all information about the items in the shopping cart (please don't do that). But it does mean that the state of the shopping cart is addressable (that the client has all the information needed to service the request).
Consider the following URL:
/shopping-cart/john.howes
My understanding of the statelessness constraint is that if I or you or anyone navigates to that link, we will get some representation of the same resource (assuming we have the authorization to view it). It may be XML or JSON or HTML, and it may be in English or French, but the underlying resource is the same. And if I bookmark that URL and view it later on another device or email it to a friend, we would get the same resource (assuming it still exists and we have authorization to view it).
So, because I had a link to /shopping-cart/john.howes, I had all the information needed to service the request.
I think, whether you're using REST or not, adding large objects to session state is a recipe for disaster (for maintainability, scalability, and sanity). So, I'd bite the bullet and use a database. And I think you're essentially right: REST doesn't say much about how data is stored on the server, but it does imply that you don't store the current state of a user's session in memory on your web server. I think you have lots of options for optimizing for performance. Keeping everything in session is not a very good option.
I hope this helps.
John
在 REST 中创建购物车有两种不同的方法。一种是您实际上将购物车设为资源并为其分配一个 URI，如您所描述的。另一种是购物车中的内容一直保留在客户端上，直到用户下订单为止。
两种方法都有优点和缺点，是的，将购物车存储为资源需要将购物车存储在数据库中（不过它可能是内存数据库！）。
但是，我认为尝试在使用会话和存储购物车作为资源之间进行这方面的性能比较并不是特别有价值。
There are two distinct ways of doing a shopping cart in REST. One is where you actually make the shopping cart a resource and assign it a URI, as you describe. The other is where the contents of the shopping cart are kept on the client right up until the point where the user places the order.
There are pros and cons to both approaches and yes, storing the shopping cart as a resource will require storing the shopping cart in a database (it could be a in memory database though!).
However, I don't think trying to do a perf comparison on this aspect, between using sessions and storing carts as resources, is particularly valuable.