"RESTful" Transactions
The title may well qualify as an oxymoron, but I'm sure Mark Little disagrees:
So we originally created a student project to dust off the old REST transactions protocol(s) and implement them today. This started life before JAX-RS (again) but by the time something really happened JAX-RS (and RESTeasy) was around. Michael from the JBossTS team took this work on and did a great job. It's not finished (only the atomic outcome protocol has been implemented so far, for example). Plus the protocols haven't been changed at all since they were created back in 2000/2001. So there are still some things we need to look at and more interesting work ahead.
If I understand the protocol correctly, transactions become resources in their own right (which I like). Even though I have some misgivings about the details of the protocol (the verb-style resources, 401 instead of 405, lack of hypermedia usage, lack of discoverability …), I'm sure these could be addressed – it really comes down to the question of whether or not distributed transactions are needed or not in a REST/HTTP scenario.
Stefan:
is this URL RESTful? TC/begin?clientId={id} (http://www.jboss.org/community/docs/DOC-13311)
How about this one? TC/{txid}/commit and the like P-URL/prepare, P-URL/commit
Aren’t they just a bit too much VERBose? Shouldn’t you be talking about HTTP transactions, not RESTful transactions? Unless there is no more difference between HTTP and REST, and all that HTTP can do is RESTful by definition.
URLs are neither “RESTful” or not RESTful. But you are still right, which is why I put “RESTful” in quotes and referred to the “verb-style” resources.
Now I’d appreciate if you blame the folks who did this instead of shooting at the messenger :-)
Don’t forget “Plus the protocols haven’t been changed at all since they were created back in 2000/2001. So there are still some things we need to look at and more interesting work ahead.”
We’re looking at updating the protocol. It’s based on “best practices” and our (mis)understandings of things from nearly 10 years go. So give us a break ;-)
Oh and yes, you’re right, transactions become resources. Oh and of course you need transactions :-)
Stefan:
I don’t necessarily blame the messenger, I would like to ask you if we could not draw two important conclusions from this design (which is quite common amongst people using “REST”, let’s admit it): a) Actions are a fact of life, not artefacts of a programming model. Every resource has actions that drive its lifecycle. Using a programming model that ignores actions, inter-actions and trans-actions (as a state alignment capability) does not seem to be appealing to anyone, as every developer and their brother will eventually reinvent these semantics in a proprietary way.
b) Resource Orientation as a programming model does not exist. There is simply no evidence of it, as POST has the semantic of a message sent to the target resource. GET, PUT, Delete are not specific to Resource Orientation, they have CRUD semantics. Only POST, IMHO, could have made a difference at the programming model level. Unfortunately, there is no proof that POST is used with semantics other than sending a message to the target resource. Even if you disagree, the recent developments at Microsoft and IBM are re-eductating every developer that REST and WS-* are homothetic. You simply choose one over the other based on QoS requirement (including security, identity propagation, federated trust, runtime governance…), simplicity, evolution…
I am wondering if there is anything you see we could agree on?
No, I don’t agree with you here. We’ve been through this way too often, and I don’t think we’ll be able to convince one another.
Let me ask you in turn: Surely you agree that if a technology or architectural approach is misused, this doesn’t render it invalid?
You will find that there is vast agreement among REST proponents about what’s “RESTful” and what isn’t — way more so than for any other SOA or Web services topic.
hum…
Looks like you are conceding. Stefan, let’s be serious when the pattern of usage of “REST” is an homothetic mapping to WS-, then that means that either Resource Orientation does not exist or WS- is resource oriented, which we both know is not true.
HTTP has become just a choice over WS-* just because Microsoft and IBM said so. You can no longer define REST outside their definition of REST. In 2009, HTTP became part of the “middleware catalog/toolbox/landscape”. It is not exactly POX but not completely REST, it is somewhere in between, and the reason is simply because behind it there is a stubborn programming model that makes all middleware look the same. It is not until we change the programming model, like SCA has tried to do it, introducing concepts such as assemblies, bidirectional interfaces and orchestrations as key elements, granted that it could be augmented with resource orientation and event orientation concepts.
I’ll ask again the question in one year, see if you still see any Resource Orientation in the way people use HTTP. Note that I am just as sad as you, resource orientation has merit and should be a first class citizen of the programming model, then only then, the middleware would actually have to do something about it.
JJ-
Yes, let’s talk again in a year. I’m hopeful, as REST actually has a definition (as opposed to many other terms in this industry).