如果基于 REST 的事务无法实现，那么 REST 怎么可能真正有用? [英] If transactions over REST are unachievable, how can REST ever be really useful?

问题描述

当查看 REST 时，可能有人会注意到的第一件事是没有定义任何事务语义，有人说这隐含地反对 REST，而其他人则说任何尝试这样做都会导致污染"REST 系统.

When looking into REST one of the first things probably anybody will notice is there isn't any transaction semantics defined, some say this is implicitly against what REST is, whilst others say any attempt to do so would result in 'tainting' the REST systems.

但是为了争论，我们可以说 REST 确实成为了一种流行的api"选择，并且宇宙中的每个站点都开始公开 Restful 入口点.

But lets say for arguments sake that REST did become a popular 'api' choice, and every site in the universe started to expose restful entry points.

这些在没有事务行为的情况下究竟如何可用(我说的是非补偿性)?因为在我看来 REST 的好处之一是它分解了数据的组件，你会认为这让智能客户端可以从多个服务组合数据(并添加和调整这样的组合数据).但是，如果我不能以原子方式和孤立地对这种数据组合进行更改，那么使用 REST 就变得毫无用处.

How exactly are these usable without transaction behavior (and I'm talking non compensating)? because it seems to me one of the benefits of REST is that it breaks down the components of data, this you would think opens them up to having smart clients compose data (and add and adjust such composed data) from multiple services. But if I cannot do my changes to this composition of data atomically and in isolation then using REST becomes useless.

随着时间的推移以及对严肃数据公开的需求的到来，我们会想要这样的东西:简单(REST 胜出)，并支持事务行为，因此我们可以可靠地操作这些数据.

As time goes on and the need for serious data exposition arrives, we're gonna want something that is: Simple (REST wins there), and supports transactional behavior so we can manipulate this data reliably.

现在，我在我的研究中多次阅读了一个特定的论点，它与我们应该如何考虑 REST 中的事务有关，给出的示例是购物车，其中隐含了隔离因为购物车是你的.

Now, I've read a specific argument a couple of times in my research, and its related to how we're supposed to think about transactions in REST, and the example given is the shopping cart, where you implicitly have isolation because the cart is YOURS.

但是我不同意这个论点，首先，购物车的隔离只是方便，这不是事务隔离..如果我在应用程序的某些部分同时对我的购物车进行操作时会发生什么是从它读取数据吗?我不希望我的应用程序的读取部分看到仍在交易中"的数据.

However I disagree with this argument, firstly, the isolation a shopping cart has is merely convenient, this isn't a transaction isolation.. what happens if I'm simultaneously doing an operation against my cart whilst some part of my application is reading data from it? I wouldn't expect the reading part of my application to see data that is 'still in transaction'.

更不用说并非所有数据更改都具有隐式事务模型这一事实，跨多个服务的事务绝对没有.

Not to mention the fact that not all data changes have an implicit transaction model, transactions over multiple services definitely don't.

在我看来，事务需要发生，并且需要以一种使实际的 REST 调用无视事实的方式发生(添加到其余有效负载是一个很大的不，但添加标头是可以的).

It seems to me that transactions need to happen, and need to happen in a way that enables the actual REST calls to be ignorant of the fact (adding to the rest payload being a big no no, but adding headers being OK).

我已经阅读了一些关于如何通过 REST 创建事务模型的建议，并且正在编写的一些规范似乎是最新的.

I've read a few suggestions about how a transaction model can be created over REST, and some of the specifications being written seem to be very recent.

对此有任何真正的想法吗?不应该有比 REST 更更多"的东西，以便可以利用 REST 的简单性来对抗可靠的数据操作(酸性"事务).

Are there any real thoughts about this? shouldn't there be something 'more' than REST so that REST's simplistic nature can be harnessed against solid data manipulation ('acid' transactions).

如果不是，我们是否真的希望提高赌注，并告诉服务开发人员，如果他们想在纯数据世界中进行交互，他们需要支持一些可以说是单一的东西，比如肥皂?或者更糟糕的是，尝试将自己的自定义事务支持构建到 REST 之类的东西中，使每个服务都变得非标准并破坏 REST 的全部功能?

If not are we expected to really UP the ante, and tell service developers that if they want to interact in a pure data world they need to support something arguably monolithic like soap? or even worse try and build their own custom transaction support into something like REST, making each service non-standard and breaking the entire power of REST?

提前感谢您的任何想法.

Thanks in advance for any thoughts.

编辑，添加了简短的场景:

Edit, added brief scenario:

想象一个处理专辑创建的客户端表单，为了方便该专辑，而不是要求用户提供艺术家资源的 uri，他们可以从艺术家列表中选择(最有可能从艺术家目录).

Imagine a client form that handle creation of an Album, for convenience on that Album, rather than asking the user to give the uri for the artist resource, they can pick from a list of artists (most likely GET'd from the artists catalog).

为了可用性，客户端可以手动写入艺术家姓名，以便他们可以内联"创建艺术家..在发布场景中，客户端代码理解这一点，并且在发送创建专辑的请求之前，它首先尝试确定艺术家是否已经存在，如果存在，则获取该艺术家的 uri，否则创建艺术家并获取艺术家的 uri.

For sake of usability the client can write the artist name in manually so they can create an artist 'inline'.. in the posting scenario, the client code understands this, and before sending the request to create the album, it firstly attempts to determine if the artist already exists, if so, gets the uri for that artist, otherwise creates the artist and gets the artists uri.

然后客户端代码继续创建相册，这是比普通客户端更智能的客户端，它不是直接位于 REST 之上和愚蠢"的发布，而是有一些交互来处理更纯粹的 REST 逻辑.

The client code then continues on to create the album, this is the smarter than usual client, it isn't sat right on top of REST and 'dumbly' posting, but instead has some interaction that handles the purer REST logic.

然而，在这种情况下，最好保证艺术家不会被创建，除非专辑被创建，因为先创建了艺术家.

However in this scenario it would be nice to guarantee that the artist isn't created unless the album is, given the artist is created first.

这并不像事务所暗示的那样关键"，但它定义了客户端代码希望作为一个操作发生的一组工作(毕竟，它使这看起来像是对用户).

This isn't as 'critical' as a transaction would imply, but it defines a set of work the client code would prefer to be happening as one operation (after all, it IS making this look like a single operation to the user).

我所看到的针对这种情况的唯一指导是让客户在专辑创建失败的情况下采取补偿措施，并特别要求删除艺术家.但这似乎有问题，因为客户假设该艺术家是孤立的，尽管可能性很小，如果另一个客户已经看到"了该艺术家并分配给它，会发生什么情况?

The only guidance I've seen for this scenario is to have the client do compensating action in the event the album creation fails, and specifically call to delete the artist. But this seems problematic, because the client is assuming the artist was isolated, as unlikely as it may be, what happens if another client already 'saw' that artist, and assigns to it?

这些是我对进行数据更改的担忧，虽然肯定还有其他差距(谁说无论如何不能在以后删除艺术家)，但这些操作并不透明(即，这些操作不是由客户端自动执行的某些内容，但用户已明确要求的某些内容).

These are my concerns regarding doing data changes, and whilst there are certainly other gaps (who says the artist couldn't be just deleted at a later date anyway), those actions are NOT transparent (ie, the actions aren't something automated by the client, but something a user has specifically requested).

我希望这有助于阐明主题.

I hope that helps illuminate the topic some.

推荐答案

我假设当您谈论交易时，您谈论的是分布式两阶段提交协议.

I am going to assume that when you talk about transactions you are talking about a distributed Two Phase Commit protocol.

如果我理解正确，您正在尝试了解如果 REST 不能支持跨不同 REST 请求的事务，我们如何使用 REST 来执行跨越多个系统的操作.问题是您做出了一个潜在的错误假设，即我们应该使用事务来实现一致性.我们为使用它们付出了什么代价，以及存在哪些替代方案?

If I understand correctly you are trying to understand how we could ever use REST to perform operations that span multiple systems if REST cannot support transactions across distinct REST requests. The problem is you are making a potentially flawed assumption that we should be using transactions to achieve consistency. What price are we paying for using them, and what alternatives exist?

Pat Helland 曾经在亚马逊工作，现在在微软工作，写了一篇论文 分布式事务之外的生活.作者在论文中发表了以下声明:

Pat Helland who used to work for Amazon and is now at Microsoft, wrote a paper Life beyond Distributed Transactions. In the paper the Author makes the following statement:

不幸的是，程序员们努力解决电子商务等业务目标，供应链管理、财务、和医疗保健应用越来越需要考虑非分布式扩展交易.他们这样做是因为尝试使用分布式交易过于脆弱表现不佳.

Unfortunately, programmers striving to solve business goals like eCommerce, supply-chain-management, financial, and health-care applications increasingly need to think about scaling without distributed transactions. They do this because attempts to use distributed transactions are too fragile and perform poorly.

他的论文探讨了可扩展且性能良好的分布式事务的替代解决方案.

His paper explores alternative solutions to distributed transactions that do scale and perform well.

也许 REST 会成功，因为它不支持事务.这是罗伊·菲尔丁 (Roy Fielding) 的一句话，他发明了 REST 一词

Maybe REST will be successful because it does not support transactions. Here is a quote from Roy Fielding, the guy who invented the term REST

如果您发现自己需要分布式事务协议，然后你怎么可能说你的架构基于REST?一世根本看不到你怎么能从一种情况(使用 RESTful客户端上的应用程序状态和超媒体确定所有状态过渡)到下一个情况需要分布式协议事务语义，其中客户端必须告诉服务器如何管理自己的资源.

If you find yourself in need of a distributed transaction protocol, then how can you possibly say that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of transaction semantics wherein the client has to tell the server how to manage its own resources.

...现在我考虑休息交易"是矛盾的.

...for now I consider "rest transaction" to be an oxymoron.

这是 2009 年 6 月 9 日 REST 讨论列表上的一条消息.我无法提供链接，因为 Yahoo 群组没用.

This is from a message on the REST-discuss list from June 9th, 2009. I can't provide a link because Yahoo groups is useless.

这篇关于如果基于 REST 的事务无法实现，那么 REST 怎么可能真正有用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！