02/26/08 :: [REST] What's Great About REST [permalink]
Interesting combination of posts on Stefan's blog: REST doubts and the announcement of Steve's interview at QCon.
Let me do with Steve first. Steve, we actually have a similar background, I am also an EE self-trained developer. I think I taught about 100 more classes in software engineering than I took. I just want to point out two things you said.
First, you say:
There's a problem if you have to define something in IDL just to know how to use it. That doesn't really work. No one takes an IDL and says: "Here's this method, I call this and I pass this. I just look at the IDL and I know what to do".
Nobody does that. IDL is really for code generation. If I want to know how to use a service whether it has IDL or not, I go talk and talk to the developers, if they're nearby; if they're not I look at their documentation.
Steve, could you consider just one second what an "assembly" is. Come on, you are an Electrical Engineer, how could this concept ever escape you? Can you create an assembly without an interface? Have you tried to wire "Natural Language Service Description" (p210 of the RESTFul Web Services book).
Second you talk about Erlang:
it has to fail over in case of problems with one of the nodes, or you need fault tolerance, all the reliability issues, and then the whole concurrency thing which is where you spend a lot of time just figuring out ...
Steve, Erlang is great at what it is doing, I can appreciate the exceptional activation model and the lack of shared memory, but do you really think this is the ultimate programming language (I don't think you do). My point is why not create a programming language from scratch that solve all these problems, specifically designed to build composite information systems? Isn't it time that we think of a programming model rather than programming languages on one side and middleware on the other? It made sense 20 years ago, but this view is completely outdated.
Before I take my final stab at REST, I would like to underline what I find great about REST:
- the resource concept: this is an integral part of the programming model
- resource representations as an interaction model between provider and consumer and media type mediation (though I like role mediation better than type mediation)
- extensible QBE interface
- safety and idempotence (that's a big one)
- consumer oriented error messages
- the programming model when the consumer is a client
- (Please note that I did not say that the URI concept was great)
The first 5 items can easily be emulated in the web services stack. QBEs are trivial to specify in WSDL and you can create forward compatible WSDLs by expanding the number of QBEs in your interface definition. Please note with SDO, WS-* has already a very advanced representation update mechanism.
Now, before I started this discussion I used to see REST with a good eye. I used to say "Use it where you can, and WSDL where you can't". I must admit that after reading the book RESTful Web Services (which I got at the King County Library), my recommendation is really don't use REST at all, and here is why:
a) when the consumer is a browser, Tuscany's latest widget bindings allow you use a "Service Oriented" model up to the browser. Jean-Sebastien gave me a demo of what the Tuscany team was doing. It is simply spectacular. I did not expect it would turn out that way, but IMHO, SCA signs the death of REST because it takes away the only competitive advantage REST has over WS-*: the browser-to-service relationship.
b) The REST community is thinking of REST as a CRUD-Oriented Architecture (you don't have to do it that way, but this model is so engrained that they can't think differently). This has been exemplified by the recent "Partial Update" discussion started by Joe Gregorio. It culminated with Joe concluding that it had to make "a variable" a "resource". Let me give you a piece of advice, when you create a programming concept that is based on the concept "foo" and you reach the conclusion: look ma', it is beeoutiful, everything is a "foo" even a variable is a "foo", then you are on the wrong path, you can end your work immediately.
c) REST is CRUD-Oriented because the REST community wants to manipulate the resource content and state from the consumer. Most of the REST community does not understand that there is a difference between expressing the changes you made to the resource representation and CRUDing the resource directly. This is what the old guard of architects have been doing for over 30 years and this is wrong. This is what Service Orientation is suggesting you don't do (though you can do CRUD-OAs with WSDL and SOAP just as well, this was the SalesForce.com API at some point -some people even built an ADO.Net adapter on top of their WSDL interface LoL).
You can see the CRUD spreading just about everywhere: here in RESTful Rails, or here in the RESTful Web Services book (p188):
The Controler code: the code that converts incoming requests into specific actions on the database.
In 2004 Thinking-out-loud (??) had already identified this problem:
I have seen several systems that on the surface appear to be doing the RightThang (tm), in that they are developing with the latest and greatest technologies and platfoms, e.g. J2EE or .NET, they are following iterative and incremental development processes, and all of their application interfaces are exposed via web services.
The problem is that they didn't know when to say when, and that led to basically a massive collection of CRUD-oriented interfaces on top of entity/domain class concepts, i.e. there ends up being a service per entity, say, for example, Employee, and the operations are basically CreateEmployee, SaveEmployee, FindEmployee, DeleteEmployee. The service should be defined at a business semantic that expresses a sense of acheiving a user/business goal. For the Employee example, for example, business operations might be Hire, Terminate, Promote, etc.
d) The REST community is "religious" about where the application state should reside. Let me quote Richardson and Ruby:
Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. (p86)
This could not be more wrong. This is why RESTians are CRUDing in all the time. All resources are "stateful" and as a mater of fact can participate in multiple "applications" simultaneously. A PO, an Invoice, a ticket, a trip... all have a lifecycle independent of the "application" that advance their state. This is IMHO, one of the two worst architectural mistake the REST community is making. Yes, a web page does not have a complex lifecycle and of course, this statement is correct in that very limited (yet widely abundant) scenario. Again, nothing says you have to do that, but the REST community will take years to understand why it is bad. Instead they prefer to CRUD the resource to death (LoL). Incidentally, Mark, calling "state" both the resource "content" and the resource "state" with respect to its lifecycle is not going to help you architect a solution the right way, it will simply encourage you to CRUD around.
e) The second worst architectural mistake is inherent to REST itself, it is the URI concept. This is the Achilles' heel of REST and this is deadly as soon as you go away from web pages and feeds and into the world of information systems. URI mixes the concept of identity and "accession" while "flattening" the accessor query language. There is no real concept of identity in REST and this is deadly. This bolts getters and putters to the resource and creates a versioning nightmare. Not to mention that it prevents you to compare two resource representations. URIs are QBEs. Nothing less, nothing more. You would be creating a huge mess if you let them "hang" around in "consumer state" longer than they would otherwise stay in a browser. URIs are a lot more transient (in the real world) than the REST community want you to believe (of course, again, in the case of a web page or a feed, it works).
f) All this and Stefan's list as well could be fixed. The problem is that the REST community has made fun of the ebXMLers and WS-Starers. They never appreciated how difficult it is to write a spec. It requires giving a lot of yourself, a tremendous amount of energy and focus. Not to mention that there are always a couple idiots that want to derail the spec to match their inferior product, get a (hidden) consulting gig... or simply out of ignorance.
Guys, I like you, I respect you, you are smart and want to do good things and deliver value. I have no doubt of that. But please, be honest: fix REST or ditch it and relax...