When to Use RESTful HTTP
JJ Dubray has written a post on “10 questions a solutions architect should ask before using REST”. Some good points, and worth commenting. You need to read JJ’s post since I’m not going to re-iterate everything here, just add my perspective:
1. Can the solution be constructed from a series of roughly autonomous webparts that have independent requirements in terms of scalability, security, evolution and ownership? Do you foresee that these webparts will be used in different solutions?
JJ sees REST as the solution here; I agree.
2. Is your solution also about implementing complex processes that are likely to change on sophisticated business objects such as a an insurance policy or claim?
I’ll happily agree that if you’re after a BPM-style solution, REST is not the first choice. I have my doubts that you’re so much better off using WS-* Web services, but clearly there’s no equivalent of BPEL for plain RESTful HTTP, nor is there much support for it from the big vendors. My guess is that 90% of the REST community don’t want to have any of this, but I could definitely imagine that there could be some very interesting solutions there. I agree with Mark Masterson and wish JJ would apply his intellect there.
3. Does your solution require peer-to-peer inter-actions?
I see no problem with peer-to-peer interactions using RESTful HTTP, provided you’re able to run a Web server on both sides. I see zero advantage on the Web services side.
4. What are the implications of reducing application semantics to a uniform interface on your solution?
This is the main discussion I’ve been having with JJ in numerous emails over the last few weeks, and we simply can’t seem to agree. I believe main benefit of the uniform interface — connectivity, accessibility, however you might want to call it — far outweighs the mental shift you have to make to become comfortable with mapping your semantics to it. (There’s also a strange misquote of one of Roy Fielding’s slides here, AFAICT - he wanted to show the effects of not using a uniform interface, the most significant one of which is the lost GET possibility. It also makes sense to look at the full content of the slide JJ mentions.)
5. What is the impact of using Uniform Resource Identifiers as business entity identifiers?
Not everything needs to be identified with a URI, only those things you want to expose as Web resources. For those that have different requirements, you can still use whatever means is appropriate. In the WS-* world, there is no concept of standardized identification. Who would consider this an advantage? Yeah, me neither.
6. Is query by example combined with media types enough for building your solution?
That’s actually a pretty good point. There is no standard way of specifying URI templates (but one is emerging), and there is no standardized query syntax. Both would be a good idea. In the end, though, you can of course use any query format you like by POSTing it, thereby creating a new resource (the search result). Again, this is more, not less than what the WS-* world has to offer.
7. Do you want XML to be your primary means of exchanging information?
JJ uses an older Mark Pilgrim article that, despite the title, is basically concerned with XHTML, or rather: with the way browsers handle XML. It’s utterly irrelevant to the discussion we’re having here, particularly as SOAP is XML, and SOAP over HTTP is thus plagued to the same degree by the same problems.
Whether or not you use XML is 100% orthogonal to whether or not you use REST. There is a huge benefit in not having to force everything into XML, as it means you don’t have to use idiocies like this or that.
8. How do you propagate user identity?
Security in WS-* is arguably handled better than in the REST/HTTP world. Whether it’s particularly user identity propagation that is problematic, I’m not so sure. In many cases, SSL is sufficient even in WS-* scenarios — at least that’s what 99% percent of the installations are using (just a wild guess).
9. Do you need transactions in your solution?
JJ claims there are no transaction capabilities in REST. True. Don’t use RESTful HTTP if you want to synchronize multiple requests in a 2PC manner (and thereby tightly couple your systems).
10. Do you trust the RESTifarians to come up with all the specifications needed to establish robust server-to-server inter-actions?
Most of the stuff that’s available in the WS-* world is of questionable value, and I see no need to copy it. There’s one very funny quote, though:
Hardly anyone in the REST community has experience with writing specifications and major vendors have not yet moved in
I’m sure Steve Vinoski, Mark Nottingham, Tim Bray, Joe Gregorio, and many many others are really looking forward to writing their very first specifications soon. Who knows, maybe even Roy Fielding may end up writing one?
JJ, in case you haven’t noticed, some of the most vocal REST proponents are authors of specs — sometimes even of those of the WS-* kind. My favorite quote from Mark Nottingham, former chair of the W3C WS-Addressing Working Group, illustrates this nicely:
Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.
Someone should ask Roy whether he wants to pitch in on the new HTTP IETF work so he can finally put “worked on a spec” on his resume. Err. Wait…
:-)
You can do 2PC transactions RESTfully. The RESTful Web Services book has an example. You’ll have more process and data coupling than a completely uncoupled Web resource, but less than any flavor of WS-Tx. You can make all the state changes driven by hypertext, for example.
You can also generalize that to business processes of arbitrary complexity.
It’s not something everybody needs to do, and the working examples and doc are pretty sparse (yet), but give it a year.
iIRC, the book shows how to do transactions - but they are not 2PC, ore at least not XA (which would be needed to gain the benefits of the many resource managers that support it). Other than that, I agree — I feel “classic” transaction models don’t have a place in loosely-coupled systems.
I think that JJ’s comments about the “lifecycle” of a resource is a red herring, and a post with more detail about it is brewing. Basically, I think that if a “resource” has a lifecycle, then it’s a design error — separation of concerns, division of responsibilities, etc. has misfired, and the “resource” with a lifecycle is really N resources, each representing a state or an activity.
But JJ’s tone has been so unpleasant that I’ve had no interest in responding. Holiday festivities were significantly more entertaining. ;)
You can do 2PC RESTfully just fine. You can’t use XA or any of the ACID transaction managers, you have to relax the ACID rules. In particular, you can’t lock for the duration of the transaction.
Pat Helland’s “Tentative Operations”, the solution in his “Life beyond Distributed Transactions” paper, are actually 2PC. OASIS BTP (http://www.oasis-open.org/committees/business-transactions/) calls it the Provisional-Final pattern. Several other names for this same pattern have been proposed.
Basically you mark the resources updated in the first phase as provisional (in any of several ways) and then if the transaction commits, you mark them as final. No transaction-spanning locks required.