Monday, 24 March 2008
Tilkov on Doubts About REST
« What is Software Architecture? | Main | RESTful Service Descriptions »
In a recent InfoQ piece Stefan Tilkov attempts to address doubts about REST. I offer my reactions to his 10 items.
- REST may be usable for CRUD, but not for “real” business logic I agree with Tilkov, that REST actually doesn't map cleanly to CRUD, and I agree that if your only goal is to wrap resource access with business rules, REST can work just fine. I think Tilkov would have made a stronger point if he discussed the paradigm of "hypertext as the engine of application state" as part of workflow business rules. This highlights the fact that security often needs to be a maintained statefully, but this is another question.
- There is no formal contract/no description language Tilkov gives three answers. First that you can RESTfully access constrained XML documents. That's a weak answer because there's no way to know or discover beforehand what the XML schema at a given URL will be. And if it changes, there's nothing to confront the service provider with to say "look, you don't comply with your contract". Second, he says you don't need contracts as you'd have to read documentation anyway. That's laughable. All those WSDLs we use daily for SOAP, we don't need. OK. The third answer is WADL and WSDL 2.0. This, of course, disproves the previous two answers, except that they are both extremely young and need to mature. You can't answer the first two ways and the third way simultaneously! The problem with WADL and WSDL2 is that most REST advocates believe the other two answers and aren't creating tooling around these standards. They have this unreasonable fear that embracing contracts will take them on the path towards WS-* hell.
- Who would actually want to expose so much of their application’s implementation internals This one is batted down pretty handily. With REST you still control what is exposed and what is not.
- REST works with HTTP only, it’s not transport protocol independent I don't buy this answer. The talk about HTTP vs TCP is downright strawman-ish. You actually are starting to see things like SOAP over JMS occasionally, and when AMQP delivers true platform independence, I expect messaging based SOAP will take off.
- There is no practical, clear & consistent guidance on how to design RESTful applications This is a cultural thing with the REST community. Somebody should write a REST Cookbook. There are too many arguments about how this or that is not RESTful with no base of examples that are RESTful. Atom is not enough. Tilkov's strawman comparison to WSDL/SOAP is weak. There are plenty of books that take you step-by-step on how to design a SOAP service. They don't have to agree: "best" practices can be written in stone when the space stops evolving.
- REST does not support transactions It's agreed that distributed transactions often (even usually) aren't needed. But I shouldn't have my web services architecture decide this for me. There ARE cases where architects want to use these. Global consistent data is very important is many inventory or financial systems. It's also often needed for reliable messaging as discussed in the next bullet. That said, if I need transactions, I usually switch from SOAP to JMS to avoid the WS-* yuckies.
- REST is unreliable Well, I actually think WS-ReliableMessaging is weak. It's support by various SOAP stacks is spotty. When I want reliability, I usually move to JMS, often dumping SOAP in the process. WS-Death-* is SOAP's weakness. That said, idempotency is not a solution, come on. These require the client to rely on behavior from the server to verify the message is received. You need contracts to do that in an automatic way. The other solutions are an attempt to start creating WS-* equivalents. Technically it could work, but these are curiosities, not standards with widespread adoption. Really, the moment you have contracts (see #2) you have a mechanism where you don't need human intervention at design time.
- No pub/sub support This one is bunk. He gives Atom as proof. With some standards, there could easily be ways to POST or PUT a callback url, too, for peer to peer interactions. Also see the next question. Contracts to allow discovery would be nice (see #2).
- No asynchronous interactions He should mention Comet. But POST or PUT of a callback URL could work for peer-to-peer interactions, or simply hand the client of the URL to poll. His idea to use response code 202 is a little weird. Contracts to simply declare support for a particular standard would be nice.
- Lack of tools He's right that if you use XML formats, you have all the same tools. HTTP is otherwise pretty universally embraced. However, full access to all the HTTP methods besides GET and POST is occasionally problematic. REST lags far behind when it comes to service contracts, of course. In fact, I predict it will be the SOAP stacks that first close this gap for REST when they embrace WSDL 2.0. There need to be better client side tools for operating on particular contract standards, too. For example pub/sub is easy if your client knows how to post its callback URL because it sees a standard pub/sub mechanism is declared. Tooling means making these standards and making clients that use them transparently. REST can hopefully skip some of the WS-* hell, but it can't skip all of it. In summary, I still think REST contracts need to mature (but it looks like progress is starting). Once this happens, standards and tooling can deal with the rest. It's not clear how REST can avoid the WS-* debacle that SOAP went through. But many of the ten doubts really have been dispelled.
Technorati Tags: rest soap
Posted by at 3:36 AM in the internet, web, web 2.0 and beyond
[Trackback URL for this entry]
