可以使用REST架构限制实现购物车吗?
我想关注会话状态。在实现购物车的典型MVC应用程序中,最有可能的是,会话对象将在会话中管理,购物车将作为产品列表进行管理。
如果应用程序遵循REST架构,那么如何管理同一个购物车。 REST约束之一是状态管理是客户的责任。
购物车及其进度是否应由客户管理?任何例子?在简单的购物车或任何其他企业应用程序中管理客户端状态的任何缺点?
答案 0 :(得分:11)
将购物车作为资源存储在服务器上没有任何问题。应该存储在客户端上的会话状态。 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
。
关键是,处理请求所需的一切都应该在请求中。
答案 1 :(得分:4)
在REST应用程序中,会话状态完全由客户端管理,请求必须包含服务器要理解的所有必要信息。例如,如果服务器需要身份验证,则每个请求都必须包含凭据。
REST stateless constraint定义如下:
5.1.3无国籍
[...]从客户端到服务器的每个请求必须包含理解请求所需的所有信息,并且不能利用服务器上任何存储的上下文。因此,会话状态完全保留在客户端上。 [...]
但是,无状态约束并不意味着服务器不应存储任何数据。
在会话状态由服务器管理的应用程序中,这是将购物车数据存储在HTTP会话中的常用方法。但购物车不是会话状态。而且,它可能不应该完全由客户管理。
在REST中,购物车可以是由URL 标识的资源,例如/shopping-cart
,并且可以对其执行操作。所有购物车数据都可以保存到服务器上的数据库中。
Any information that can be named can be a REST resource,甚至是购物车:
5.2.1.1资源和资源标识符
REST中信息的关键抽象是资源。可以命名的任何信息都可以是资源:文档或图像,临时服务(例如“洛杉矶的今天天气”),其他资源的集合,非虚拟对象(例如人)等等。换句话说,任何可能是作者超文本引用目标的概念都必须符合资源的定义。资源是到一组实体的概念映射,而不是与任何特定时间点的映射相对应的实体。 [...]
您可以在购物车上执行以下操作:
GET /shopping-cart
:购物车。
POST /shopping-cart
:将商品添加到购物车(使用您要添加的商品和请求正文中的金额发送一些数据)。
DELETE /shopping-cart/1
:从购物车中删除ID为1
的商品。
PATCH /shopping-cart
:更新购物车(在请求正文中发送一些要更新的数据)。
PUT /shopping-cart
:替换购物车的全部内容(使用请求正文中的购物车内容发送一些数据)。
DELETE /shopping-cart
:移除购物车
POST /shopping-cart/order
:订购购物车内容
因此,请注意客户端不会随时存储有关购物车的任何信息。与购物车相关的所有信息都将存储在服务器中。
有关REST的更多信息,我建议您阅读Roy T. Fielding chapter 5的dissertation。
答案 2 :(得分:1)
存在很多关于REST的混淆,因为很多人都听说过REST约束,并且认为它们是除了将体系结构本身作为目的之外无其他原因而应用的规则。
你应该问的真正问题是为什么REST中存在无状态约束,以及你从遵循它有什么好处。请记住,REST是一种用于大规模分布式系统长期演进的架构风格。在单个数据库保存所有信息的小规模应用程序中,您根本不会遇到REST应该解决的问题。
无状态约束会导致可见性, 可靠性和可扩展性。可见性得到改善 因为监控系统不必超越单一 请求数据以确定请求的完整性。 可靠性得到改善,因为它简化了恢复任务 部分失败。可扩展性得到改善,因为没有必要 请求之间的存储状态允许服务器组件快速进行 免费资源,并进一步简化实施,因为 服务器不必管理请求之间的资源使用情况。
因此,无状态意味着客户端请求应该具有处理它所需的所有信息。
您的知名度有多重要?您是否希望在调试时能够从客户端请求中查看购物车的全部内容,或者您是否可以从数据库中获取该信息?
可靠性有多重要?您是否拥有包含多个服务器和数据库的大型分布式系统?如果您有一个大型分布式系统,其中购物车信息可能存储在不同的数据库中,具体取决于响应请求的确切HTTP服务器,如果服务器发生故障,则该组中的另一台服务器将能够完成请求并完成会话或来自其他组的服务器将强制客户端重新启动会话。如果请求中包含所有信息,那么任何服务器都可以执行此操作。
可伸缩性有多重要?如果您有一个分布式系统,并且您将购物车信息存储在一个数据库中,那么它就成为您所有请求的漏斗,并且您失去了可扩展性。如果将其存储在多个数据库中,则会失去可靠性,如上所述。
那么,您是否有雄心勃勃的长期目标,或者您的应用程序是否足够大以至于您将面临REST尝试解决的问题?如果您总是拥有一些服务器和一个数据库,并且您将在每个请求中使用它,那么无论您是否处于无状态状态都无关紧要。您可以拥有/shopping_cart
资源或类似内容,使用POST
请求添加内容,并在完成后关闭或删除它。
如果您将数据分片到多个数据库,许多HTTP服务器响应请求,缓存服务器等,并且您希望能够通过在需要时设置新服务器来动态配置容量并删除当负载减少时,然后充满无状态,并将购物车留给客户。
答案 3 :(得分:1)
是的,你可以,
购物车数据(添加的产品)可以保存在客户会话中,这不是问题。
然后,一旦用户点击/结帐,购物车应该保留在服务器上的数据库中。关于休息的关键是客户所做的每一次请愿都必须包含所有数据来识别自己,我建议阅读有关JWT或OAuth的一些信息。
应用程序本身可以像您看到的任何其他购物车应用程序一样工作,大部分都不会将数据库中的购物车保留,只需将其存储在客户端会话中。
答案 4 :(得分:1)
我认为有人为无状态概念选择了一个非常不幸的名字,这就是造成整个误解的原因。这与存储任何类型的资源无关,而是与客户端和服务器之间的关系有关。
客户:我将所有资源都保留在一边,并向您发送所有需要处理的重要项目的“清单”。做你的工作。
服务器:好的。让我负责过滤重要内容,以便给您适当的响应。
意思是,服务器是客户端的“奴隶”,每次请求后都不得不忘记他的“主人”。