01/01/08 :: [SOA] The 10 Questions a Solutions Architect Should Ask Before Using REST[permalink]

I think the discussions with the RESTifarians need to come to an end, as Stu suggested.

It find it difficult to swallow that I am just "hand waving" when all that Steve Vinoski says:

there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really

If this is not hand waving, what is?

So, since we can't agree on some basic concepts such as a "resource has an identity, some content and states described by a lifecycle" or "the most commonly adopted way to transition a resource from one state to another is a well defined action".

I want to point out that the RESTifarians have also made it clear to me several times that:

SOA reuse is a pipe dream for most organizations because they are not willing to change their investment evaluation windows or mindset about the economics of software. Most are just looking to improve their agility -- which is about the way we design interfaces & interactions, not about reused logic.

They use this argument to neutralize the need for a "composition" mechanism. It goes as follows, "since people write code that can't be reused, why bother?". Stu offers here a variation of this argument "The enterprise can't take decisions that will lead to the realization of reusable components, therefore there is no need for a composition mechanism". Since REST does not offer any composition mechanism at the component-component level, this is not a problem, they want to convince you that "you don't need it".

And, of course, it is well known that nothing can be done and no technology can be used to prepare for future evolutions of the business logic (be it in terms of scalability, security or functionality) and we are always forced to take all the functional and architectural decisions even before the first line of code is written. It is of course a much better architectural approach to keep hacking your way into the code especially when there is not even an interface and explicit data structures to refactor and all familiar application semantics such as data structures, queries, states, actions, inter-actions, trans-actions, events or exceptions... are reified behind HTTP, i.e. four verbs, Uniform Resource Identifiers (URIs), "media types" and hypermedia as an invocation mechanism.

It is also well known that Enterprise Software Vendors have no control over the "economics of software" and they have been charging fair market prices for absolutely rock solid products that enable IT to meet the need of the business easily and efficiently. I forgot to mention that the abysmal picture of the "economics of software" is only due to the fact that IT architects, like me, and developers are stupid and don't know how to use these rock solid, well tested, cheap, fully functional, scalable, secure infrastructure products. This is why vendors keep changing the technology on us and why it took 8 years for these vendors to develop a decent WS-* stack, and now some of these vendors or at least individuals from these vendors are telling us, well, it is again time to change as it appears they have found a technology that can match our limited intellect after 30 years of intense trial and "errors".

Enough hand waving at each other, I am talking to my fellow IT architects today. I would like to share my stupid understanding of REST as a set of questions every solutions architect should ask himself or herself before using REST in any capacity.

#1 Can the solution be constructed from a series of roughly autonomous webparts that have independent requirements in terms of scalability, security, evolution and ownership? Do you foresee that these webparts will be used in different solutions?

If you answer yes, you are lucky, you may now enter the elite and seek the well deserved admiration from your peers: REST is the technology of choice, it will go a long way to meet the needs of your organization. I recommend that you take a deep look at Amazon's architecture and get familiar with REST, you will be able to apply every bit of it. My favorite article on REST was written not surprisingly by Stu Charlton.

If the answer is no, or not quite: your solution cannot be factored just in terms of web parts. Then I would ask myself the following questions.

#2 Is your solution also about implementing complex processes that are likely to change on sophisticated business objects such as a an insurance policy or claim?

I recommend that you read this article that I wrote last month on modern BPMS architecture based on Web Service technologies and compare it to what REST has to offer. The concept of "resource"  (or more exactly in REST terms Network Data Object) is at the foundation of both architecture style but their factoring is widely different. I would argue that both styles should be unfamiliar for most of you and I would strongly recommend that you become familiar with both. I strongly believe that both styles are complementary and in general, most solutions will exercise both styles. To help you decide on which style to apply when I would recommend that you ask yourself the following questions.

#3 Does your solution require peer-to-peer inter-actions?

REST was developed to guide the design of HTTP 1.1 and therefore is mostly based on a client / server model where the client is a browser used by a human. Roy Fielding himself says that REST constraints need to be relaxed (Slide 31) (you may prefer listening to Roy) in server-to-server interactions. REST style itself was not designed for peer-to-peer interactions.

This is what Roy says on slide 31:

What happens when we let servers [not browsers] make requests?
• lose implementation simplicity due to listening, additional parsing requirements
• potential for confusion with mixed-protocol intermediaries
• unknown: does it impact session state?

#4 What are the implications of reducing application semantics to a uniform interface on your solution?

This is the main credo of the RESTifarians. For Roy, I don't think he means "use a uniform interface everywhere, all the time". Slide 30 explains the main benefit:

URI is no longer sufficient for resource identification
- lose benefit of URI exchange (assumed GET)
- require resource description language

I have also written a post that explain why a uniform interface creates such a high level of loose-coupling in the case of a browser-to-server scenario and contrary to RESTifarian beliefs, such a high level of strong coupling in a server-to-server scenario. The reason is simply what Roy calls "additional parsing requirements".

#5 What is the impact of using Uniform Resource Identifiers as business entity identifiers?

A very subtle concept to understand is the concept of URI and what URI points to: resources. The first point to understand is that URI are coupling identification and access. Access is the location of a resource at a given point in time (locations can change, not access). In essence, REST does not have the concept of unique identifiers, so I can't conclusively infer that two URIs are not pointing to the same resource, all I am -kind of- guaranteed if the resource owner does not play tricks on me is that I will access the same resource using the same URI, but I can't compare URIs.

#6 Is query by example combined with media types enough for building your solution?

HTTP supports (it is not really specified in HTTP) a basic query by example mechanism. This is why all REST article or design documents feature some form of mapping QBEs to a URI syntax. In this article Joe Gregorio defines the QBE of a bookmark application managing the bookmarks for a group of users:

Resources in the Bookmark Service






A single bookmark for "user"



The 20 most recent bookmarks for "user"



All the bookmarks for "user"



The 20 most recent bookmarks for "user" that were filed in the category "tag"



All the bookmarks for "user" that were created in a certain year [Y] or month [M]



A list of all the "tags" a user has ever used


You will notice that all mappings are parameterized using []: this is QBE. It means that all resources are retrieved following a QBE pattern regardless of how they are stored in the database of the file system. You would admit that not using a pattern to retrieve your resources would be impractical. The "representations" column points to the media type which basically describes the structure expected by the consumer of the resource representation.

First, QBE is no SQL and maps directly to an interface definition, even though the RESTifarians refuse to use an interface definition language. If you use REST, I would recommend that you use an interface definition language to communicate, keep track and version these mappings. Not using an IDL, here, is the most ludicrous recommendation made by RESTifarians, but I am just hand waving here, of course.

You will also note that Joe is using proprietary semantics only known by him to express a wildcard: [user]/bookmarks/all/

Second, the media type has no structure and needs to be agreed upon somewhere, in some form. Please not that REST does not enforce a common syntax (for good reasons) to express the representation (PDF, ASCII, PDF... are all perfectly valid syntax). If you ever need a different "view", i.e. resource representation in REST terms, you will have to create a different media type. All these media types will proliferate and REST does not provide a way to manage them easily within an organization. A (private) registry could come handy, I don't see people publishing their media types to the Web.

Third, you can't navigate to related resources without first GETing and parsing the resource representation of  parent element for the reference, unless you create some QBE joins such as: [user]/bookmark/[id]/ otherwise you first get all the bookmarks for a user: [user]/bookmarks/ and then you navigate to: bookmark/[id].

At the end of the day, you will notice that all REST application assume a hierarchical data model because of the XPath-like syntax used in the QBE mapping. If, for some reason, you want to navigate to the user information based on a bookmark then you start having multiple URI pointing to the same resource: bookmark/[id]/user and [user] both point to the same piece of information.

I want to emphasize that there is nothing wrong with QBE and XPath-like syntax. You simply want to ask yourself the question whether it meets your need, or at least the benefits outweighs the cons.

#7 Do you want XML to be your primary means of exchanging information?

Mark Pilgrim explains the idiosyncrasies of using HTTP with XML. I suspect that this is news to many people and it probably explains why RESTifarians do not see XML as their primary common technology neutral syntax. It may also explain why they are pushing JSON which is not as widely adopted as XML in server-to-server communication and does not even come close on schema capabilities and extensibility as XML.

#8 How do you propagate user identity?

REST is relying on HTTPS as its primary security mechanism which implements a single identification mechanism. So if a user interacts with a resource and this resource implementation modifies another resource on behalf of this user, you have no way to propagate the user credentials in a standard way, let alone establish trust boundaries and trust federations.

#9 Do you need trans-actions in your solution?

A trans-action simply represents a state alignment between two or more resource. That is, at the end of the trans-action all the actions invoked on the resources will in effect change the states of the resource or if any error occurs, all resources states will be reverted to the states they had prior to the beginning of the transaction. Different quality of service can be provided. For instance "isolation" might be important in some cases, in other words, you do not want to expose any state changes until the trans-action is complete. Juval Lowy discusses here some question around durability.

REST has no trans-action capabilities.

#10 Do you trust the RESTifarians to come up with all the specifications needed to establish robust server-to-server inter-actions?

You get the idea, there are a lot of "things" provided by the Web Services technologies from contracts, to transactions, to security, to reliable messaging, to eventing, to assembly and orchestration languages... The RESTifarians have invented their own version of the "Emperor has not clothes" story: in the REST world, the "Emperor does not need as many clothes". Which can or cannot be true, again it is all a question of tradeoffs, pros and cons.

The RESTifarians have quietly started to develop REST-*. To give you a glimpse of how difficult this task is, just consider:

a) how long did it take for Atom Publishing Protocol to become a specification

b) The kind of discussions they are having on problems such as reliable messaging

c) Hardly anyone in the REST community has experience with writing specifications and major vendors have not yet moved in

d) The only boundary they acknowledge is a "resource" (i.e. a record or business entity instance)

So if you need something like REST-* you will have to wait between 5 to 10 years at best. Assuming that they don't realize that they need an interface definition language to deal with the server-to-server scenario.

Ok, I am done, I think I have raised enough question to help IT architects respond to the WS-Bashing and help them in their day-to-day job. This was my only goal. I am very sad that irresponsible people feel that it is "fun" to "kill" the work of others for their own benefit. In the process, they attempt to sway scores of people in dead-end directions.

I hope that you realize that people like Tim Bray and Mark Baker have lost their mind, and that people like Steve Vinoski -who, based on their own admission, have been wrong at what they were doing all their career- are wrong again when they talk about REST.

IMHO, Remoting has no future, any kind of remoting of traditional application semantics, including one based on REST, has no future. The future is a programming model designed for specifically presentation, process and information composition, factored for inter-actions and based on a programming language where inter-actions are primary citizen of the language (unlike Java or .Net that have the slightest idea of what an inter-action is).

Happy new year 2008 !