11/07/07 :: [SOA] The rEsT FALLACIES [permalink]
Mashups are a great concept (check mine), when you build an enterprise class solution you really have to mashup (federate) GUIs, processes and information. You would be passing on tremendous value if you would never use process or information federation.
IMHO, this pictures shows how much a loosing value proposition REST is. As Stefan pointed in his presentation introduction, REST is good if you are creating services (huh?) that need to scale massively in terms of consumers. I can appreciate why Google, Yahoo and Amazon love REST. I can see how REST services delivering web parts as resource representation can be so convenient to use and therefore why REST is here to stay.
However, when you have "real-world" problems, that do not require the kind of scalability that Google is looking for, then you WILL be confronted to the need to express:
- intermediaries: to help you perform security checks, routing or transformation at wire speed. You are not even on your own there, REST can't do it.
- interoperable reliability: REST has tricks, but not a spec. How to you do message ordering in REST? well you don't, you are on your own.
- contracts: how can you do versioning in REST? you are on your own. So if all you are doing is displaying an HTML fragment on your page, you don't care so much about versioning. You don't really care too much about the structure of what you are receiving, but in general, in the real world, you care about knowing when the "contract" has changed. You also care that the contract be machine readable so that you don't have to "implement" a service proxy on the client side, the proxy is generated for you to use within your business logic. What's a contract for REST? you have one contract per resource? no of course, per resource type? but there is no concept of resource type in REST. You are on your own for contracts.
- peer-to-peer: Roy fielding himself say REST can't do peer-to-peer it has to be "relaxed". You are not even on your own there, REST can't do it.
- Dependency of Injection: DofI of resources? no, not really, since REST does not have the concept of a service, you can't do DofI, you can't arbitrarily replace the root of URIs, on the fly. You are not even on your own there, REST can't do it.
- state alignment: what most people don't understand is that a transaction aims at aligning the state of two or more software agents. Meaning, at the end, each agent is in a state that is known without ambiguity by all the other agents (whether it failed or succeeded). To achieve state alignment, you need a state alignment protocol. This protocol is one of the hardest thing to design (talk to Eric Newcomer or Mark Little). You can't do one per project, all the time, I bet most of your developers (including me) wouldn't be able to design one. These people had years of discussion on this topic. Doing that own your own as you need it?
- pub / sub: that's an obvious one, REST simply forbids pub/sub all the way. You are not even on your own.
- Orchestration: the REST camp, with people such as Steve W. says, I can do with a little script. You simply have no idea what you are talking about. On average an orchestration reduces the amount of code by a factor of 100. Orchestration style code is hard to write, it is extremely stateful, need to handle correlation and concepts such as hydration and dehydration. REST can't even do correlation because it does not have a contract. There are no XSD associated to a resource, a resource is only defined by its URI. What a warm fuzzy feeling to be on your own to deal with correlation and dehydration/hydration.
- Resource update: it is completely naive to think that resource update can easily be modeled in REST. Since what you get on the client is a "resource representation" which most often is a partial view of the resource itself (and different clients could get different representation, not just from a format perspective, but from a structure perspective), how do you communicate updates back to the resource? you are on your own. SDO offers a "change summary" that clearly communicate what the client did to the resource representation. The client also gets instant feedback if it's trying to do an update that can be invalidated by contract. An update can of course still fail on the server after some business logic is applied. If you want to be able to do client side contract based validation, you are on your own.
- Choreography: this is probably too abstract for people to understand when you need it, so I'll let you get away with this one, but you are still on your own.
The REST fallacies are simply outrageous. The bottom line is that REST is a terrible web service model for the enterprise. Some people are trying to set you back ten years when it comes to building enterprise class (not Google class) distributed information systems. A lot of companies would like to have to deal with Google scale problems, but the reality is that they don't and will never need to do so. On the other hand they will deal countless times with process and information federation, not just mashups.
I'll repeat what I have said, I am not anti-REST, REST principles are great, REST style makes sense and you should apply it wherever your can. I am anti WS-Bashing. 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.
Good luck on your REST enterprise project !