I've been trying to evangelise REST a bit lately and have had mixed success. There is cautious interest. But there are also huge conceptual hurdles to be overcome. Pete Lacey said it best about enterprise IT folk when it comes to REST: They Can't Hear You.
One architect looked at the definition of a service interface I proposed and thought it a bit "bland". Perhaps it just needed a big WSDL file, lots of XML and SOAP faults!
Another common reaction to REST when it's presented is that "it's just CRUD", with the implication that it's just too fine-grained to be used to create good business services. I've been struggling to explain that just because REST uses four HTTP verbs that correspond roughly to CRUD operations, it doesn't necessarily mean that REST is a CRUD approach to manage data at a very low and detailed level. The resources on which the verbs operate can be arbitrarily coarse-grained. But what has eluded me so far is a succinct term that can drive the point home.
I think I've finally found it - "Polymorphic CRUD".
IT folk in the enterprise understand both polymorphism and CRUD, so the combined term should make sense. I want to drive home the point that a verb itself is neither coarse- nor fine-grained, it's how each resource interprets it. Fine-grained resources will interpret the REST verbs as CRUD operations. But more coarse-grained resources can interpret the verbs as any arbitrary business operation.
Accompanied by the appropriate payload, POSTing to the resource "/applications" is nothing but submitting an application. There's no need for a specific "submitApplication" method.
I've also realised that one can clear a process inbox by DELETEing a "/pending" resource, with a standard WebDAV status code in response (207 Multi-Status), indicating that different items encountered different status codes during the batch process.
It's the way the verb is interpreted by each resource that gives it its meaning in that context. Therefore the REST approach is to manipulate business objects of arbitrary size and complexity through polymorphic CRUD operations.
I hope that gets people to go "Aha!"
One architect looked at the definition of a service interface I proposed and thought it a bit "bland". Perhaps it just needed a big WSDL file, lots of XML and SOAP faults!
Another common reaction to REST when it's presented is that "it's just CRUD", with the implication that it's just too fine-grained to be used to create good business services. I've been struggling to explain that just because REST uses four HTTP verbs that correspond roughly to CRUD operations, it doesn't necessarily mean that REST is a CRUD approach to manage data at a very low and detailed level. The resources on which the verbs operate can be arbitrarily coarse-grained. But what has eluded me so far is a succinct term that can drive the point home.
I think I've finally found it - "Polymorphic CRUD".
IT folk in the enterprise understand both polymorphism and CRUD, so the combined term should make sense. I want to drive home the point that a verb itself is neither coarse- nor fine-grained, it's how each resource interprets it. Fine-grained resources will interpret the REST verbs as CRUD operations. But more coarse-grained resources can interpret the verbs as any arbitrary business operation.
Accompanied by the appropriate payload, POSTing to the resource "/applications" is nothing but submitting an application. There's no need for a specific "submitApplication" method.
I've also realised that one can clear a process inbox by DELETEing a "/pending" resource, with a standard WebDAV status code in response (207 Multi-Status), indicating that different items encountered different status codes during the batch process.
It's the way the verb is interpreted by each resource that gives it its meaning in that context. Therefore the REST approach is to manipulate business objects of arbitrary size and complexity through polymorphic CRUD operations.
I hope that gets people to go "Aha!"
12 comments:
Ganesh:
the problem is that the semantics of PUT are what they are (you replace the entire content of the resource).
REST (HTTP) is an application protocol from which you encode operations. The beauty of HTTP is that you don't encode all operations in two verbs (Send / Receive), you are a bit smarter about it, GETters are different than SETters, Deletes or Create.
Business operations are encoded mechanically:
login -> POST session
Pay claim -> POST payment
check Policy status -> GET /policy/123/status
...
However, REST (HTTP) has a fundamental problem, which is, REST is a distributed object technology and as such it is not Service Oriented.
You really have to reflect on how bad the coupling is between access and identity in a DO architecture. SO was invented because DO does not work.
I am not sure Polymophic CRUD is true.
JJ-
JJ,
On the contrary, it's my belief that REST is the technique that is more naturally Service-Oriented, not SOAP. A designer has to consciously make a SOAP-based interface service-oriented, because the usual lazy technique of generating WSDLs from Java classes makes it nothing more than a Distributed Object paradigm. So I think it's actually the other way around.
I've written about this before.
Regards,
Ganesh
With all due respect Ganesh, I think you are mistaken, the order in which you call does not matter:
myInstance.doSomething(withThis) is strictly equivalent to
doSomething /myInstance/withThis
I am still invoking the business logic attached/anchored to "myInstance", there is no level of indirection like in SO. SO has actually 2 levels of indirection before you hit the data: the service interface, the service implementation and then the data.
SO is about separating the business logic from the data, while OO/DO is about encapsulating the data with its access business logic.
REST is in the Distributed Object category, it does not flip any view point at all. The target of the call is the resource, it is always about the resource and only about the resource. REST does not give me any room to have more than one business logic version wrapping my data.
This is why SO is vastly superior to DO and why DO never succeeded and why DO will never succeed. This is this coupling that is wrong. Beyond that there are some "minor" details that OO can't do like bidirectional interfaces and asynchronous behavior (including dehydration/hydration).
Hi Ganesh,
Interpreting a verb in the context of a resource is definitely a Web-y thing. But not RESTful by default. REST has other constraints than the uniform interface alone.
@JJ is wrong when he calls REST distributed objects. It's not. It's an architecture for distributed systems. If you interpret resources as objects, you're sunk. Similarly if you expose objects through WSDL in classic SOA you're sunk.
As for bi-directional interfaces and asynchronous interactions, @JJ: RTFM.
Jim
The problem is not what is RESTful or not, the problem is what do people do with HTTP, what kind of semantics do they encode and how they encode them, everything else is just thin air.
JJ:
> myInstance.doSomething(withThis) is
> strictly equivalent to
> doSomething /myInstance/withThis
Well, no. In REST, the "doSomething" is a very specific, canned verb. You don't need to make one up for every occasion. The "withThis" doesn't have to be part of the URL. It can be part of the HTTP payload. And the "myInstance" you show in the URI is not an instance at all. It's the name of some logical "resource" that you think makes sense to be exposed to the client. The logical resource may not actually exist anywhere in the implementation. It has nothing to do with any domain class. Hence the service interface is fully decoupled from the domain model.
> SO has actually 2 levels of
> indirection before you hit the data:
> the service interface, the service
> implementation and then the data.
To coin a phrase, decoupling is an idempotent operation :-). One level of decoupling is enough, and REST does that pretty well. We don't really need two levels.
I used to be skeptical about REST, but I think I understand it much better now. It's definitely not distributed objects. In fact, its very discipline forces the designer to decouple the service interface from the implementation.
With SOAP on the other hand, you *can* build systems that are service-oriented and not distributed objects if you're conscientious, but many naive developers seduced by WSDL-generating tools end up doing distributed objects/RPC, which is completely anti-SOA.
You really should look at REST more closely. It has contracts and it has decoupling. There are simple design patterns that give you asynchronous behaviour and idempotence. There's really very little you can't do with a RESTful design. I would say it is in fact much closer to the spirit of SOA than you give it credit for.
Regards,
Ganesh
Ganesh:
this is a really interesting discussion as usual.
As I mentioned earlier the verb-noun is isomophic:
verb -> POST /resournce/noun
login -> POST /session
I was just saying that to be OO (or flip) requires more than shuffling the order between the operation invocation.
So:
POST /myInstance/withThis-do
is just as equivalent.
>> To coin a phrase, decoupling is
>> an idempotent operation :-).
>> One level of decoupling is
>> enough, and REST does that
>> pretty well.
unfortunately this is not exactly true. You need to decouple the consumer point of view from the service provider (REST does that with MIME type), you need to decouple business logic from DATA. These two levels are not indempotent and most SOA fail because people don't understand loose coupling and its relation to versioning.
REST is missing the decoupling between the business logic and data and this is deadly. This is DO all over, we have returned to 1991.
I've havent visited your blog in a while but when did you turn RESTafarian? :)
I have the same trouble convincing folks. Its one of those things, where something is sooooo obvious that it can be hard to get.
JJ:
> I was just saying that to be OO (or flip) requires more than shuffling the order between the operation invocation.
I think I haven't made myself clear, then. It's not shuffling the order that makes it a Viewpoint Flip. It's the very verb itself. You change the very verb so that it refers to what the service consumer does rather than what the object does. That's what changes it from OO to SO.
If we adopt this philosophy, we can no longer blindly generate WSDL from Java classes, because this does not change the verbs. With SOAP, the designer has to think from the service consumer's point of view and invent new verbs. With REST, those consumer-oriented verbs are readymade. That's why REST is Service-Oriented out of the box. SOAP needs some manual effort if it is to be Service-Oriented.
I'm not sure how to convince you that REST is emphatically *not* distributed objects. It's one of those points that is very clear to me but I'm not sure how to get across.
Ganesh
Dilip,
I wouldn't call myself RESTafarian. I see some very good aspects to REST. I like the resource-orientation.
However, I think the request-response paradigm is a bit of a limitation that inhibits easy notification scenarios. A messaging protocol with all the other characteristics of HTTP would be just the ticket.
And I'm not sure that all forms of statefulness are bad. We do need a limited form of statefulness if we want to achieve qualities of service (secure messaging, reliability, transactions, process coordination). I think these are generic enough to be pulled into the protocol itself (a uniform interface for QoS).
The problem is that REST-over-HTTP is the best we've got. It's conceptually ahead of every other distributed computing approach, but it's not perfect, IMO.
Ganesh
Hi,
Without going through all the comments and with due respect to all the responders involved in this conversation, just sharing the information to see help whether any better understanding is achieved. This is what Roy T Fielding putup as a link in his blog profile to explain REST - http://rest.blueoxen.net/cgi-bin/wiki.pl?RestInPlainEnglish
For those RESTafarian's, this is the original dissertation - http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Hi Ganesh,
Good to finally meet you at the Jim Webber session a month or so back. It was a great talk, certainly got me thinking.
On that vein I believe there is an opportunity to push development of some REST services within your company at present. We're looking to interface with a new web service being developed by your company on a certain project. At present the solution identifies that SOAP with be the protocol of choice. Sorry to be a little bit vague with the details but I'd rather not disclose our two respective employers without permission.
If you'd like to talk about it further please feel free to drop me a line.
Cheers,
Dave Kuhn
Post a Comment