11/04/07 :: [SOA] Stefan on REST [permalink]
Another group that wants to kill SOA is some of the REST folks. Stefan posted a pointer to one of his REST presentation. Since you don't see the slides in the video you may want to GET them ahead of time.
Ok, so I said, I won't participate in a REST debate again, I apologize, it is just that I respect Stefan a lot and at the same time I was very uneasy about his presentation. I read it as yet another attempt to kill Web Services and with it SOA, because if all we had was REST we would be unable to build a Service Oriented Architecture. As a starter, I'd like to disclose, I like REST, it's brilliant, surely enough the web would be very different if it had been designed on OO/Corba principles.
In his presentation, Stefan makes a very good point about resources vs services, REST sees the world as "un-gated" resources, while services are the gate to a parking lot full of resources. I fully support this view and this argument, but is it enough?
I start to part from him on the "application semantics". He ends his talk by saying "HTTP is good enough", meaning that all you'll ever need to do to construct a distributed application, you can do it with HTTP. I must admit I am an application semantics freak. I don't think people should be coding their breath away, I do think that application semantics should be defined to write as little code as possible (this does not mean zero code). I come from a NeXT background, that might explain why.
To illustrate how HTTP application semantics were enough, Stefan sent me a link that describes a "stock trader" application. For sure, the paper is full of "additional" semantics not directly supported by HTTP (in other words you have to code them in, each time) such as reliable messaging semantics or "operation hacking". The Reliable Messaging solution that is provided assume that the server talks to a "client".
Operation Hacking consist in mapping "business operations" to URI, here is a sample from the article:
Note, that I am making fun of this but I do believe that this is a great design pattern for SOA. I am making fun of it, because REST claims its opposition to SOA (resources first, smash the services -the ugly services lock the poor resources behind doors). But, how do I read the URI? Well there is an /acct service which has a getAccountByID operation,... because at the end of the day, this is really how you will end up implementing it, with a service (the system of record for this resource type), not one resource at a time. What Stefan is saying though, is that why do you need WSDL and WS-* when I can give you a URI and without anything else you can interact with the resource behind. Just like WSDL you don't need binaries, but since your agreed on most of the contract already (GET, POST, PUT, DELETE) you don't need to generate a client from the contract to get at the resource, your infrastructure can do it out of the box just with a URI. It's like being able to invoke the account service without having to expose and consume the "Business Interface". This is why he claims "HTTP can do it out of the box". Again, this is great, this is profound, but this is not "exposing" resources, this is a transcoding of operations into a mechanism that can invoke them without creating and using all this messy WS-* goop. IMHO, the /acct service is still there. REST does not introduce "magical semantics" that somehow remove the complexity of a business interface, it simply removes the need to use WSDL and SOAP to invoke a business operation. Nothing else. The business operation (and supporting semantics such as reliability, security, transaction -a.k.a. STAR ;-) still remains and must be understood "clearly" by all parties. In the Web 1.0, well we didn't really have "business operations". Roy's vision was to create "applications" from document navigations. Makes sense, this is a very important class of applications. Actually so important that all other types of applications are being dissolved in it (rightfully so). In other word, a business application + content is far superior to a business application alone. We all experienced that, we all know that. But does it really mean that the semantics of Web 1.0 are enough to write all possible applications? Is it the wholly grail of application models?
Frankly, I can see easily why WS-* will never make it to the browser and why PHP and the like don't care about it. But does this means that we should trash WS-* all together and re-invent (or worse not re-invent) a RS-* stack (granted that it is pretty much in place today and just needs a bit more formalism).
My answer to this question is three-fold:
a) not everything is a resource
Stefan claims that Google has an API that is now totally RESTful. I can easily admit the limits of my intellect, but I'd be curious to understand how you map a "search" operation to a resource. Is a search result really a resource? sure anything can be a resource if you say "as long as I can write a URI, it must be a resource", but semantically, is it really? I "searched" the example for a search method but could not find one.
Another example of "not everything is a resource" is this mashup I wrote to help my children learn how to read. My daughter had trouble in first grade and I came up with this idea of creating flash cards with the words she had trouble to read (not rocket science by any means). It was so effective for her and my son later that I put it on the web to use. The mash up is using Google pictures, a dictionary, sounds, wikipedia and other "resources" (spelling sheets. I feel that this little application shows well how the "everything is a resource" simply does not work. As a starter, what is a "word" in a flashcard for REST? a resource? but it is not, it is unique for sure. I can use a "word" to access resources such as a definition or say a spelling sheet for that word. Similarly, when I make a request to Google pictures from a word, do I really invoke the uniform interface to a resource? Do I really get a resource back? What are those semantics for REST? All I see is services with business operations.
The elephant in the REST room is "resource update". REST claims that PUTing or POSTing an updated resource representation back to the server is enough. But that's a pretty naive view of update, let alone a distributed transactional update. The reality is that the client does not hold necessarily a pristine copy of the resource representation like it would do of a web page and it does not know what's allowed to add to the resource representation. This handshake, including exceptions, can be very costly to implement. SDO (and ADO.Net) offer an elegant solution to the problem, REST does not have anything even close.
b) There is too much of a client/server paradigm embedded in REST
The REST folks are making too much assumptions on "one side" of the pipe is a browser. Even Roy himself explains that you need to "relax" the REST constraints to create a peer-to-peer relationship. Ok, you are going to tell me that WS-I Basic Profile forbids peer-to-peer relationships between services and only an heretic like me can claim that the world is not flat, (client-server), and is rather round (peer-to-peer). But, somehow, WS-* is ready for peer-to-peer. Except for one isolated vendor, nowadays, nobody else believes that peer-to-peer is useless.
Peer-to-peer is more than having a URI to call back to. True peer-to-peer is about creating an assembly of network accessible resources working together. In the REST model the consumer of the resource has no interface, it has no opportunity to expose an interface. It is not a resource from the server point of view. So if a client GETs a resource representation and somehow this resource representation needs to be updated by the server, you are out of luck (the client did not send you back the resource representation's URI on its side, it has no way to do that).
REST does not know what an "event" is either.
REST does not know what an intermediary is.
Do you know how much code worldwide is written to go around these three limitations (server can't talk to the client, intermediaries and events)? And I am not even throwing orchestration in the mix.
c) REST gives you a small piece of WS-* and it is not credible to think you can create a vast distributed system without further semantics
I am looking at the InnoQ's poster and this is what REST would need to do to really make its WSDL+SOAP short cut really worth while to the community, assuming events and peer-to-peer can somehow be embedded in the REST model
- REST-DL (I need so specify somewhere the schema of my resources)
- REST-DO (as in SDO)
- REST-Intermediary (can HTTP do that? so you might also need REST-OP at some point)
- REST-Security, Privacy, DSig
- REST-Orchestration Language (you don't need it today because you code everything by hand)
- REST basic profile to clean up all the previous specs
So overall, even though I see REST principles with the highest consideration and I have nothing to sell (I work for an IT organization). I am very skeptical about Stefan's rationale.
Does REST has a point? yes, is REST going to own the browser-service relationship at Google, Yahoo and Amazon, yes definitely.
Is the barrier of entry lower, well yes and no. Sure it looks really low compared to WS-*, but considering all your developers are going to code behind the scene, I am not sure that this is an accurate statement. They will shoot themselves in the foot faster that's for sure. But REST gives me a lot more reason to shoot myself in the foot.
So, I am sorry, I don't see why I would use REST for free when I would have to write so much code that I get with WS-*. The productivity of REST is simply not there for writing modern distributed systems. WS-* gives you true and modern application semantics to write complex distributed information systems.
Stefan, my conclusion is that both WS-* and REST have room to grow and make sense. It makes no sense to oppose them: they need to learn from each other. I don't think it makes sense to have them converge today either, maybe in two or three years we'll revisit the question.