Todd Biske: Outside the Box

Some of the blogs I follow have been simply giddy about the recent statements on REST from Anne Thomas Manes of the Burton Group. About the only thing I agree with on some of the comments is that Anne is extremely smart. Beyond that, this is a case of people seeing what they want to see. Of course, some will accuse me of doing the same, but that’s okay. All of our blogs are simply forums for stating our own opinions, so that’s what it should be!

First, let’s call out where the debate exists. The debate has been around REST versus WS-*, not REST vs. SOA or ROA (Resource Oriented Architecture) vs. SOA. Even there, you could narrow it even more, which was eloquently captured by Erik Johnson in a comment on Stefan Tilkov’s blog (which came to my attention courtesy of Don Box’s blog).

“It seems to me that people attracted to REST (in whatever form) are rebelling against interface-based programming more than WS-* itself — at least that’s my excuse.”

There have been endless debates in the blogosphere and mailing lists over whether or the message payload is part of the interface or not. Clearly, REST is all about having a uniform interface, and if you include message semantics in that interface, it seems that it would be a difficult thing to achieve. The uniform interface is GET, PUT, POST, and DELETE. There’s been some recent discussion about media types and their role in implying message semantics, however, the WS-* proponents will argue that there’s a huge gap between application/xml and having XML Schema (courtesy of WSDL).

Anyway, back to the statements from Burton Group. While most of the bloggers are commenting on this news story at SearchWebServices.com, I first caught wind of this directly from the source via the Application Platform Strategies Blog at Burton Group. My take on this is that Anne first recognizes that REST isn’t going away anytime soon, as is increasing in mindshare. No arguments here, and there are plenty of REST bloggers out there popping champagne bottles over this statement.

The piece that I feel is getting lost in some of this discussion is that, as Anne points out in the APS blog:

REST is not the same as “plain old XML” (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don’t wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.

This is probably the biggest myth right now. There are lots of people that are using XML over HTTP, thinking that they are using REST, when in fact, they aren’t. Again, Anne nails it with this statement:

REST is not simply technology–it’s an architectural style that’s fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.

This is where I’d like to see some constructive conversations. When we’re talking about SOA, we’re talking about services. Services represent capabilities. Capabilities are typically associated with verbs. REST is resource-driven. To me, that would mean that I should apply it where I need a resource oriented architecture, not a service oriented architecture. The question is where is this appropriate? Clearly, there are many calls that do nothing more than retrieve data, and it would seem that a REST-based approach for this would work very well. The question, however, is whether a resource oriented view is sufficient.

One of the things I like about SOA is that it can help establish better lines of ownership, which theoretically, can allow IT to operate more efficiently. Because these are based on services, however, they are more likely to be aligned along functional boundaries rather than on resource boundaries. Resources are shared across functional boundaries, so if my unit of composition is at a resource level, how do I deal with these concerns? I’m not suggesting that it can’t be done, but I think this is where there is lots of room to grow, as Anne points out. In the SearchWebServices example, Anne provided a light bulb example, which (pun intended) should turn on the light bulb for people on what they’re getting into:

“A REST application to turn on and off the lights in your building will require you to design a URI for every light bulb and then you send it on/off messages,” she explained. “It’s not like I have a single service that manages all my light bulbs. It’s a very different approach to designing a system. And it’s going to be really hard for developers to get their hands around it.”

So what is my opinion on all of this? If it’s doesn’t come across from my blog, I tend to very pragmatic. I think there are places for both WS-* and REST, and that will continue for the foreseeable future. REST makes lots of sense to me when we’re dealing with browser-based clients (e.g. AJAX). WS-* makes lots of sense to me for service-to-service interactions. I do fall more on the side of formal interfaces, and as a result, I want to learn more about WADL. I’ve yet to see a solution that is doing REST by the book, most examples I’ve been fall more into the POX/HTTP category, or using an HTTP GET with query parameters to return data as XML (all read only). That doesn’t mean they don’t exist, I just haven’t seen them. In any case, debates such as these keep things interesting. There’s always risks that it will strictly be a battle of religions rooted in opinions (which never get resolved). Involvement of people like Anne Thomas Manes and others that fall into the pragmatic group in the middle can ensure that the debate progresses to appropriate application of these approaches to where we leverage the strengths of both, and minimize their use in areas where the weaknesses are exposed.