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

Here's part 3 in my series comparing Service Oriented and Resource Oriented architectures. If follows part 1: Comparing ROA and SOA and part 2: ROA and SOA and Service Contracts. This article will focus on the second major difference between ROA and SOA from part 1: REST's uniform interface vs SOAP's rich operation sets (the other two being contracts and data/metadata differentiation). REST relies on the HTTP uniform interface, and prefers to do so with minimal overloading (ie don't put requested operations as parameters), whereas SOAP provides a rich set of domain specific operations, and requires an invocation POST to specify which operation from an endpoint specific set that is contractually specified.

My conclusion is: REST was supposed to define a set of architectural constraints, but nobody is constrained by the uniform interface and many don't implement it or worse violate it. To identify those resources agreeing to abide is a contractual determination, not an architectural one.

Let's review what a uniform interface is, and then what the ROA uniform interface is. As a simpleton definition, a uniform interface means that for all things capable of responding to a request, the language to invoke the request is the same (aka uniform). This means the language is a system invariant as opposed to something that must be specified per target. This is important because it means that intermediaries can attach to the system and the semantics of any observed requests are transparent to the intermediary. This explaination is my own spin and interpretation. Consulting the authoritative source is (to me, YMMV) like reading a political speech: it says much that is often repeated by adherents but uses too many nebulously defined terms that at the end of the day don't convey any precise meaning. The uniform interface, as described by Fielding, is defined by four interface architectural constraints: identification of resources via a URI, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state. Fielding later explains: "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." Generally, I agree there is tremendous value in having a standard set of operations with externally known, target-independent semantics. The idea in ROA is that all resources in the system can receive GET, POST, PUT, and DELETE. Unfortunately, very few people actually implement these faithfully, and there are other HTTP operations like TRACE, HEAD, OPTIONS, and CONNECT which are even less faithfully implemented. Almost all of the internet fails to implement the uniform interface. Browsers don't actually support PUT and DELETE, by the way. Lot's of resources even violate the normal meanings. As one example, ActiveMQ's is a message broker that allows HTTP GET to destructively dequeue a message. Is this "bad"? or useful?

I hate to come back to the contract question again, but how exactly do I declare that I do faithfully use the full uniform contract of ROA. How do I shout from the rooftops that my GETs are safe? I suppose somebody could publish an atom feed of all "know uniform" sites. The sad irony is that were such a way invented, it would express nothing more than that specific targets obey a particular interface (the uniform one). This is the problem with trying to avoid contracts - it doesn't work. The sad reality is that the uniform interface is not uniformly adopted. It'd be nice if it were, but alas, this is a pipe dream. It'd be nice if people wouldn't spam me, too.

Let's pretend that everybody gets religion and tries to follow the "spirit of the web". ActiveMQ only dequeues on DELETE. Even, then, there's the problem that POST doesn't actually have a standard meaning that can be predicted in a resource independent way. It's the operation with side effects, right? If that's all we can say about it, that's lame. It's also false: there's no guarantee that POST must have side effects on any particular invocation. The REST crowd cries with horror at the "abuse of the web" that occurs when somebody creates a SOAP interface and does a POST with an operation parameter of getPurchaseOrder to return a purchase order document. The offender is often lectured about the HTTP Spec, section 9.3 and 9.5 and the Axioms of The Web, and then referred to The REST Bible. Tim Berners Lee and Roy Fielding's contributions to the sciences and useful arts deserve respect, but only because they try to explain their points without the sophistry of appeal to authority, something lost on most REST advocates. Back to the point: there is nothing in the HTTP spec section 9.3 or 9.5 that implies you cannot embed a "GET equivalent" inside a POST, as SOAP often does. One of the (many) enumerated functions POST was intended to cover is that of "providing a block of data, such as the result of submitting a form, to a data-handling process" and " The actual function performed by the POST method is determined by the server ...". To the Turing machine at the other end of your POST there is no meaningful distinction between such an allowable data block and one that invokes "operations" via a string identifier.

When you look at TBL's document above, you do find this axiom that appears to forbid the practice. His argument for the axiom is that "The introduction of any other method apart from GET which has no side effects is also incorrect, because the results of such an operation effectively form a separate address space, which violates the universality." The axiom of universality in two parts states "Any resource anywhere can be given a URI" and "Any resource of significance should be given a URI." Keep in mind that resources in the semantic web can be "...anything - real objects, abstract concepts." The idea here is that since you are "obviously" just getting a resource, you should give it a URI and GET it.

Unfortunately, to denounce getPurchaseOrder relies on your desires as client rather than what I as the implementer have agreed to. How exactly how are you concluding from the name only, that "getPurchaseOrder" has no side effect? The WSDL doesn't specify that this is true and one of the SOA principles "autonomy" says the other details are encapsulated in a single point of control. Unless I explicitly gave you a commitment (and I didn't), you really you have no such guarantee. How do you know that my getPurchaseOrder implementation doesn't increment a counter somewhere as a side affect. How do you know it doesn't assign a random sales engineer's name from a rotating pool on each request? You want getPurchaseOrder to be side effect free, but that desire is all you have. Here's the problem: functionality changes over time. I may not be willing to commit to getPurchaseOrder being side effect free for now and all times. Even if it is truly side effect free, that's just for today. Will it stay that way? Maybe it wasn't put in a GET so that I can have the flexibility to change the operation's side effects next year when we get serious about Sarbanes-Oxley. The rule has to be that the operation is guaranteed to NEVER have side effects. The "axioms of the web" really don't contradict embedding GET in POST if the side-effect free guarantee isn't established. And that is 100% up to me as implementer to determine. You as client can never verify the call is side effect free, as I don't have to tell you everything I do when I receive your call, and you can never observe "all resources" because of the open world assumption on the web.

In summary, I wish the uniform interface of REST was actually adhered to by all HTTP resources. Even if it was, there is nothing nonconformant with SOAP. I think I could defend the proposition that SOAP is RESTful. Finally,in the real world, adherence to the uniform interface is not uniform, so there is no escaping the need for contracts to declare target specific interfaces.

Technorati Tags: rest soap roa soa web-services uniform-interface