In a recent InfoQ piece Stefan Tilkov attempts to address doubts about REST. I offer my reactions to his 10 items.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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).
9. 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.
10. 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

In reacting to my recent blog discussing the Uniform Interface as used in ROA via its reliance on REST, Roy Fielding posted a blog On software architecture. In it, Fielding states his opinion that people "don’t understand the differences between software architecture and implementation, let alone between architectural styles and software architecture." I'm not sure if that was directed at me specifically or not (I suspect it was), but I think it's unreasonable to introduce nuanced abstractions and then complain if people don't adopt them. Like any term of art, the meaning of "software architecture" is open to debate and individuals can propose their definitions and the community of practitioners will socialize what they find useful. But since the point was raised, I'm going to chime in and ask the question "what is software architecture" and I'm going to sketch my own answer. I don't see much value in abstractions above this, as there is too much vagueness at the this level alone.

My job title has "software architect" in it, so I do think I'm entitled to an opinion on what such terms mean. In an enterprise, an architect spends his time deciding what aspects of software and system design should be standardized across the organization and what things should be left to the judgment of individual implementations. Our goal, like that of anyone else in the business, is to deliver value to the company as efficiently as possible. When we decide to standardize, we have to spell out what is and isn't allowed, and we need to defend the value proposition associated with making rules over tolerating divergent solutions. I view an architecture as a set of principles, where a principle is a function that maps the space of designs into a binary space of "yes/encouraged/allowed/true/conformant/good" vs "no/discouraged/rejected/false/nonconformant/bad". When I use or hear discussion of architectural "constraints", I think in terms of such functions.

A business considers an architecture to be "good" if it leads to lower IT costs over time, balancing well between actually shipping working solution with a shorter-is-better look at development time. Since this is evaluated "over time" you have to include maintainability, adaptability, and so on. What makes an architecture "good" is dynamically changing: it depends on the habits and knowledge of the individuals in the organization, and it depends on the extent to which consensus has emerged. These things aren't perfectly knowable, and architectural leadership is as much about communicating and guiding as it is about deciding. I think my concepts here of software architecture align a lot with those of Martin Fowler, as described in his essay Who Needs an Architect?.

There is a classic debate between academics and applied practitioners as to the value of standalone theory. I'm an unapologetic applied practitioner. When we introduce nuances like the difference bewteen "architectural style" and "software architecture", I ask "who are you trying to communicate to?" When most people don't understand the distinction I wonder whose fault Dr. Fielding thinks that is and what we should do about it. At a minimum, I think it's fair to ask "why introduce a second level of abstraction?" Can't I reformulate a REST equivalent as a set of architectural principles in the sense I give above and take any proposed concrete design and say which, if any, of those principles it violates? Isn't the real problem here that we named the abstraction without having a few concrete architectures to justify it?

The use of language as a means to develop common understanding is an important step in the evolution of software architecture. Common understanding hopefully leads to communication about common experiences, and this in turn leads to consensus on what is or isn't a best practice worth standardizing upon. When I adopt language, I do so with this end in mind. I tried to sidestep the double abstraction by writing about ROA and not really about REST other than how it's used within ROA. I did this because over the past year or so, there has been an ongoing discussion influenced by Sam Ruby's book RESTful Web Services. Part of my job is to critically examine all sides of archictural trends. I, along with my fellow architects, need to guide my company on how and when to adopt architectural principles. In order to do that, I need a name for the set of practices we should consider adopting. All I can say is that continued confusion over terminology and concepts is not a good selling point for REST or ROA or whatever I should call the thing we could adopt is.

I note the Roy appears to lump me in as an "SOA advocate". I suppose it looks that way, but I'd like to make it clear that this is "for now" only. Again, what's "best" is a influenced heavily by human factors such as understanding, consensus, industry support, and so on. I'm no SOAP fanboy: there's a whole lot to dislike about SOAP and the lack of simpler solutions for SOA wastes endless sums of money across the IT industry. In my view the race is on to see if SOAP can simplify before some particular REST approach matures enough to displace it. I would not be surprised at all if specs like WADL or WSDL 2.0 help move a RESTful web services approach forward. But lots of REST advocates seem to have a philosophical opposition to these and my message to them is unambiguous: within the enterprise, REST won't matter without these. If nothing changes REST will continue be used to solve the problems of web communities. Solutions like Atom where a critical mass of people with a common problem collaborate on standards and tools will be the only arena where REST impacts. Inside the enterprise where programmers toil one or two at a time under deadlines to integrate the backends of systems in environments where politics exist, SOAP will be what people like me conclude we need to use. Again, I said "if nothing changes". I hope it will, and when it does you'll read about it here. Dr. Fielding reads this as "criticisms of [his] work". That's a glass half-empty view. A gap is an opportunity to improve, and closing this one would make it more useful in the space I happen to work in. That space is a big one, but it's not the only one. I wouldn't be discussing REST at all if it didn't solve some problem well. Please note that my Atom feed for this blog works great and is joyously RESTful.

Finally, I'd like to point out that Dr. Fielding essentially restated my main point when he says "REST constraints do not constrain Web architecture — they constrain RESTful architectures (including those found within the Web architecture) that voluntarily wish to be so constrained." It seems really odd to recognize the value of a set of voluntary constraints without immediately asking how to declare that you have volunteered, so that interacting parties can rely upon it. This of course, is exactly what a contract is. It would be nicer still, and downright useful, if there was an objective way to test that a site that declared itself to have some particular RESTful architecture actually did. In other words, its also useful to audit compliance to the contract.

Technorati Tags: architecture rest roa soa