研究REST时，任何人可能会注意到的第一件事是没有定义任何事务语义，有人说这与REST是隐含的，而其他人则说任何尝试都会导致REST系统的“污染”。 。
但为了争辩，可以说REST确实成为一种流行的“ api”选择，并且宇宙中的每个站点都开始公开宁静的入口点。
没有交易行为（我说的是非补偿性），这些功能到底有什么用？因为在我看来REST的好处之一是它分解了数据的组成部分，您可能会认为这使它们可以使智能客户端从多个服务中组成数据（并添加和调整组成的数据）。但是，如果我无法独立地原子地更改此数据组成，那么使用REST就变得毫无用处。
随着时间的流逝以及对严重数据公开的需求的到来，我们想要的是：简单（REST赢得了胜利），并支持事务行为，因此我们可以可靠地操作这些数据。
现在，我已经在研究中多次阅读了一个特定的论证，它与我们应该如何考虑REST中的事务有关，给出的示例是购物车，您在其中隐式具有隔离性，因为购物车是你的。
但是我不同意这种说法，首先，购物车具有隔离功能只是方便，这不是事务隔离。如果在应用程序的某些部分正在读取数据的同时对购物车进行操作，会发生什么情况从中？我不希望应用程序的读取部分看到“仍在事务中”的数据。
更不用说并非所有数据更改都具有隐式事务模型这一事实，而通过多种服务进行的事务肯定没有。
在我看来，事务需要发生，并且需要以一种使实际的REST调用不了解事实的方式发生（将剩余的负载添加为一个大的否定，但是添加标头可以）。
我已经阅读了一些有关如何通过REST创建事务模型的建议，并且正在编写的一些规范似乎是最近的。
有什么真正的想法吗？不应有比REST更多的东西，以便可以利用REST的简单性来抵制可靠的数据操纵（“酸”交易）。
如果不是，我们是否有望真正做到这一点，并告诉服务开发人员，如果他们想在纯数据世界中进行交互，他们需要支持诸如肥皂之类的单片产品吗？甚至更糟糕的尝试将自己的自定义事务支持构建到REST之类的东西中，从而使每个服务都成为非标准服务并破坏REST的全部功能？
预先感谢您的任何想法。
编辑，添加了简短的场景：
想象一下一个客户窗体，该窗体负责创建专辑，为方便该专辑，而不是要求用户提供uri的艺术家资源，他们可以从艺术家列表中选择（很可能是从艺术家目录中获取） 。
为了便于使用，客户端可以手动输入歌手姓名，以便他们可以创建歌手“内联” ..在发布场景中，客户端代码理解这一点，并且在发送创建专辑请求之前，客户端首先尝试确定如果该艺术家已经存在，则为该艺术家获取uri，否则创建该艺术家并获取该艺术家uri。
然后，客户端代码继续创建相册，这比通常的客户端更聪明，它不仅仅位于REST和“笨拙”的发布之上，而是具有一些处理纯REST逻辑的交互。
但是，在这种情况下，最好先确保不创建艺术家，除非创建了专辑，除非首先创建了艺术家。
这并不像事务所暗示的那样“关键”，但是它定义了客户端代码宁愿作为一项操作发生的一组工作（毕竟，它使用户看起来像是一项操作）。
在这种情况下，我看到的唯一指导是在专辑创建失败的情况下让客户端进行补偿操作，特别是调用删除歌手。但这似乎是有问题的，因为委托人以为艺术家是被孤立的人，尽管可能性不大，如果另一个委托人已经“看到”该艺术家并分配给他，会发生什么？
这些是我对进行数据更改的关注，虽然当然还有其他差距（谁说不能再以后删除艺术家），但是这些动作并不透明（即，这些动作不是自动进行的）客户，但用户已明确要求的内容）。
我希望这有助于阐明该主题。