在查看REST时,可能任何人都会注意到的第一件事是没有定义任何事务语义,有人说这是隐含的反对什么是REST,而其他人说任何这样做的尝试都会导致"污染"REST系统.
但是,为了论证,REST确实成为了一种流行的"api"选择,并且宇宙中的每个站点都开始暴露出宁静的切入点.
如果没有交易行为,我们究竟如何可以使用(我说的是非补偿)？因为在我看来,REST的一个好处就是它打破了数据的组成部分,你会认为这会让智能客户端从多个服务组成数据(并添加和调整这些组合数据).但是,如果我无法原子地和孤立地对这种数据组合进行更改,那么使用REST就变得毫无用处.
随着时间的推移和对严肃数据展示的需求的到来,我们将需要的东西是:简单(REST在那里获胜),并支持事务行为,因此我们可以可靠地操作这些数据.
现在,我已经在我的研究中多次阅读了一个特定的论点,它与我们应该如何考虑REST中的事务有关,给出的例子是购物车,你隐含地因为购物车而被隔离是你的.
但是我不同意这个论点,首先,购物车的隔离只是方便,这不是交易隔离......如果我同时对我的购物车进行操作,而我的应用程序的某些部分正在读取数据,会发生什么从中？我不希望我的应用程序的阅读部分看到"仍在交易中"的数据.
更不用说并非所有数据更改都具有隐式事务模型,因此多个服务上的事务肯定不会.
在我看来,事务需要发生,并且需要以一种方式发生,使得实际的REST调用不知道事实(增加其余的有效负载是一个很大的不,但添加标题是正常的).
我已经阅读了一些关于如何通过REST创建事务模型的建议,并且编写的一些规范似乎是最新的.
有没有真正的想法？不应该存在比REST更多的东西,以便REST可以利用REST的简单性来处理固态数据操作('酸'事务).
如果不是,我们期望真正提高赌注,并告诉服务开发人员,如果他们想要在纯粹的数据世界中进行交互,他们需要支持像肥皂那样单一的东西吗？或者更糟糕的是尝试将自己的自定义事务支持构建到REST之类的东西中,使每个服务都不标准并打破REST的全部功能？
提前感谢任何想法.
编辑,添加简短场景:
想象一下处理专辑创建的客户表单,为了方便该专辑,而不是要求用户给艺术家资源uri,他们可以从艺术家列表中选择(最有可能从艺术家目录中获取) .
为了便于使用,客户可以手动编写艺术家姓名,以便他们可以在发布方案中创建艺术家'内联'..客户端代码理解这一点,在发送创建相册的请求之前,它首先尝试确定如果艺术家已经存在,如果是的话,获得该艺术家的uri,否则创造艺术家并获得艺术家uri.
客户端代码然后继续创建专辑,这是比通常的客户端更聪明,它不是坐在REST和"哑巴"发布之上,而是有一些处理更纯粹的REST逻辑的交互.
然而,在这种情况下,如果首先创建艺术家,除非专辑是,否则保证不创建艺术家将是很好的.
这不像交易所暗示的那样"关键",但是它定义了一组客户端代码更愿意作为一个操作发生的工作(毕竟,它使这看起来像是对用户的单个操作).
我在这种情况下看到的唯一指导是让客户端在专辑创建失败的情况下进行补偿操作,特别是要求删除艺术家.但这似乎有问题,因为客户假设艺术家是孤立的,尽管可能不太可能,如果另一个客户已经'看到'那位艺术家并分配给它,会发生什么？
这些是我关于进行数据更改的问题,虽然肯定存在其他差距(谁说艺术家不能在以后删除),但这些操作并不透明(即,操作不是通过客户端,但用户特别要求的东西).
我希望这有助于阐明一些话题.