在查看REST时,可能任何人都会注意到的第一件事是没有定义任何事务语义,有人说这是隐含的反对什么是REST,而其他人说任何这样做的尝试都会导致"污染"REST系统.
但是,为了论证,REST确实成为了一种流行的"api"选择,并且宇宙中的每个站点都开始暴露出宁静的切入点.
如果没有交易行为,我们究竟如何可以使用(我说的是非补偿)?因为在我看来,REST的一个好处就是它打破了数据的组成部分,你会认为这会让智能客户端从多个服务组成数据(并添加和调整这些组合数据).但是,如果我无法原子地和孤立地对这种数据组合进行更改,那么使用REST就变得毫无用处.
随着时间的推移和对严肃数据展示的需求的到来,我们将需要的东西是:简单(REST在那里获胜),并支持事务行为,因此我们可以可靠地操作这些数据.
现在,我已经在我的研究中多次阅读了一个特定的论点,它与我们应该如何考虑REST中的事务有关,给出的例子是购物车,你隐含地因为购物车而被隔离是你的.
但是我不同意这个论点,首先,购物车的隔离只是方便,这不是交易隔离......如果我同时对我的购物车进行操作,而我的应用程序的某些部分正在读取数据,会发生什么从中?我不希望我的应用程序的阅读部分看到"仍在交易中"的数据.
更不用说并非所有数据更改都具有隐式事务模型,因此多个服务上的事务肯定不会.
在我看来,事务需要发生,并且需要以一种方式发生,使得实际的REST调用不知道事实(增加其余的有效负载是一个很大的不,但添加标题是正常的).
我已经阅读了一些关于如何通过REST创建事务模型的建议,并且编写的一些规范似乎是最新的.
有没有真正的想法?不应该存在比REST更多的东西,以便REST可以利用REST的简单性来处理固态数据操作('酸'事务).
如果不是,我们期望真正提高赌注,并告诉服务开发人员,如果他们想要在纯粹的数据世界中进行交互,他们需要支持像肥皂那样单一的东西吗?或者更糟糕的是尝试将自己的自定义事务支持构建到REST之类的东西中,使每个服务都不标准并打破REST的全部功能?
提前感谢任何想法.
编辑,添加简短场景:
想象一下处理专辑创建的客户表单,为了方便该专辑,而不是要求用户给艺术家资源uri,他们可以从艺术家列表中选择(最有可能从艺术家目录中获取) .
为了便于使用,客户可以手动编写艺术家姓名,以便他们可以在发布方案中创建艺术家'内联'..客户端代码理解这一点,在发送创建相册的请求之前,它首先尝试确定如果艺术家已经存在,如果是的话,获得该艺术家的uri,否则创造艺术家并获得艺术家uri.
客户端代码然后继续创建专辑,这是比通常的客户端更聪明,它不是坐在REST和"哑巴"发布之上,而是有一些处理更纯粹的REST逻辑的交互.
然而,在这种情况下,如果首先创建艺术家,除非专辑是,否则保证不创建艺术家将是很好的.
这不像交易所暗示的那样"关键",但是它定义了一组客户端代码更愿意作为一个操作发生的工作(毕竟,它使这看起来像是对用户的单个操作).
我在这种情况下看到的唯一指导是让客户端在专辑创建失败的情况下进行补偿操作,特别是要求删除艺术家.但这似乎有问题,因为客户假设艺术家是孤立的,尽管可能不太可能,如果另一个客户已经'看到'那位艺术家并分配给它,会发生什么?
这些是我关于进行数据更改的问题,虽然肯定存在其他差距(谁说艺术家不能在以后删除),但这些操作并不透明(即,操作不是通过客户端,但用户特别要求的东西).
我希望这有助于阐明一些话题.
我将假设当您谈论事务时,您正在谈论分布式两阶段提交协议.
如果我理解正确,那么如果REST无法支持跨不同REST请求的事务,那么您正试图了解如何使用REST来执行跨多个系统的操作.问题是你正在做一个可能存在缺陷的假设,即我们应该使用事务来实现一致性.我们为使用它们付出的代价是什么,以及存在哪些替代品?
曾经在亚马逊工作并且现在在微软工作的Pat Helland撰写了一篇论文"超越分布式交易的生活".在论文中,作者发表以下声明:
不幸的是,努力解决电子商务,供应链管理,财务和医疗保健应用等业务目标的程序员越来越需要考虑在没有分布式事务的情况下进行扩展.他们这样做是因为尝试使用分布式事务太脆弱而且表现不佳.
他的论文探索了可扩展和表现良好的分布式事务的替代解决方案.
也许REST会成功,因为它不支持事务.以下是Roy Fielding的一句话,他发明了REST一词
如果您发现自己需要分布式事务协议,那么您怎么可能会说您的架构基于REST?我根本无法看到如何从一种情况(使用客户端上的RESTful应用程序状态和超媒体来确定所有状态转换)到下一个需要分布式事务语义协议的情况,其中客户端必须告诉服务器如何管理自己的资源.
...现在我认为"休息交易"是矛盾的.
这是来自2009年6月9日的REST讨论列表中的消息.我无法提供链接,因为Yahoo组无用.
如果你想在ReST应用程序中使用ReST API函数进行交易,通常是因为你仍然有你的技术人员服务人员googles.
让我们以另一种方式看待它.
Soap googles on:打开交易,创建客户记录,创建订单记录,提交交易.
ReST谷歌:询问服务器做什么.服务器说"创建客户资源",所以POST /客户.服务器说,"现在创建一个订单,如果你想",客户通过跟随表单创建订单.
在ReST中,应用程序协议以创建和操作的资源表示,而不是根据具有事务边界的数据表示.
如果您希望拥有一个跨越所有这些操作的长时间运行的事务,则决定启动它的服务器而不是客户端.
您仍然可以在服务器端实现长时间运行的事务.如果您尝试从客户端获取事务,那么您假设客户端已经知道它将执行的所有操作以及这些操作之间存在的事务边界.如果这是您对客户的期望,那么您已经放弃了休息架构的后期绑定,超媒体驱动的特性.
事实上,如果你没有做ReST并试图通过http适应RPC,你就会遇到没有交易的问题.
我认为通常需要交易的大多数操作都可以在没有它们的情况下重新编写.
例如,经典银行转帐.假设我想将100美元从账户A转移到B:
Begin Transaction /Debit A, $100 /Credit B, $100 Commit Transaction
这可以改写为:
/Transfer A, B, $100
通过这种方式,服务器可以分两步执行此操作,但来自客户端的操作是一个逻辑意义上的单个原子操作.
我确信有很多例子可以更方便地进行全部或全部的操作(我很好奇人们可以用它来解决它们),但我通常会以这种方式重做工作.