It is infrequent for me to react with a level of consternation rather than agreement or disagreement that I felt upon reading [SOA] Boris on Service, Web and REST by Jean-Jacques Dubray. Not because I disagreed strongly with the arguments presented. It is that, I disagree substantially with the assumptions on which these arguments are made. And yet, as I recollect my own thoughts a year ago – a few months post my journey into REST, I realised that there was a time that I did actually believe some of these assumptions. I also realised that it is likely that many others who are dealing with a transition from SOA to REST are also likely to be perhaps sharing similar assumptions. Without much ado let me quickly get to the central assertion of this blog post.
Service orientation is neither essential for, nor is it the intention of REST.
Not only is REST not service oriented, service orientation is irrelevant for REST
There. But why was it so important to state that ? Allow me to quote from the blog post I referred to.
I say not surprisingly because RESTafarians have no clear position on “service”, they just say REST is the right way to build a Service Oriented Architecture. Yet, REST has no concept of “service” anywhere, just resources and their shiny uniform interface, links and bookmarks. Indeed there are no services in REST. Just read the thesis.
and it further goes on to state
But I digress, let’s go back to “services”. Even Bill, in this REST-* proposal is talking about creating a RESTful interface to non RESTful services. That certainly begs the question, how can a service be non RESTful since REST is all about SOA and replaces in its entirety WS-*.
The essential issue here is the flawed assumption that REST attempts to be service oriented or it is all about SOA. Its not. And why so ? Since it is resource oriented. And whats the difference ? Read on, because that’s what this post attempts to address.
Service
Wikipedia describes a service as follows :
the term service refers to a set of related software functionality, together with the policies that should control their usage.
OASIS (organization) defines service as “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.”
Now lets attempt to understand a service in a little more dumbed down fashion. Lets hark back to the good old construct of flow charts and process charts. In these charts one basically divided an overall set of functionality into discrete set of functionalities and chained them together through some sequences and decision points. As an example if we were to consider a simplified retail outlet system, it would consist of steps that would support (a) ordering items, (b) receiving and reviewing items, (c) selling items. In a SOA world, these could be mapped into a Ordering Service, Receipt Service and Sales Service (you could of course come up with better names and further decomposition). But each service is essentially one of the decomposed tasks of a larger workflow. If the interface to such service could be standardised and documented it would help it to be reusable across multiple contexts. And to the extent such services are reusable across multiple workflows, the advantage of Service Orientation become obvious. And finally if such a service interfaces are exposed over the web – it is a web service. At the end of the day, each service is a reusable, composable task (or tasklet) performer.
Resources
But REST does not attempt to be service oriented. Thats because it does not view the process as a sequence of tasks to be performed. It views it as a sequence of resources under modification. To put it differently, it views the process as a set of actors who exchange resources (or documents for better visualisation) and carry out activities based upon receipt of such resources. Though not as equally apt as a process chart, the analogy here would be a data flow diagram. And what might such resources be ? Well in the above scenario, there’s a Purchase Order, a Goods Receipt and an Invoice. Those are the essential abstractions that REST focuses on. These are Resources. Just like Services where there’s no one valid set of abstraction of services, one could work out a different set of resources rather than those I listed. But the bottom line is that the essential abstractions are resources *not* services.
How are they different ?
You could build a system either way – as services or resources. In terms of being able to successfully build, deploy and maintain a piece of software, both REST and SOA are likely to be equally successful at building the software. But the essential vocabulary through which they decompose their various parts (and therefore describe their interface elements) will be different. And how is that different ?
Let us imagine the ordering service we talked about above. One way to build a SOA ordering service is to establish a interaction procedure which combines an overall protocol and a series of steps (Service API). To reduce potential errors, there is a document upfront which describes in adequate detail how such an interaction should be conducted, what are the data elements to be exchanged at each stage, and what are the necessary sequencing requirements between various steps for such interactions to be concluded successfully (WSDL). The focus here is the tasks being done and the protocol for the task instructions. In case of REST the essential construct will be exchange of one Purchase Order. The purchase order would have sufficient in band instructions about the fact that it is a purchase order and the attributes it has (in-band metadata), and formal documentation if any would be restricted to the structure of the purchase order and its data than than to the sequencing, flow or any protocol level activities. (Thats why sometimes REST looks deceptively simple to be treated as just another CRUD).
More often than not when called upon to describe a service, the description will describe what the service does, and the service interface will mirror the steps required to perform the activities. Resources on the other hand will simply describe themselves and anyone who looks at a resource description will be none the wiser about what processing exactly happens behind the scene.
Thats why I believe even if both REST and SOA can be used to build software effectively, the essential focus on resources as the central abstraction makes REST much easier to use for the clients. But thats just my opinion – you may form your own.
You cheated! REST meets the service orientation definitions you listed above
Yeah, kind of (in theory). There is one way where REST over HTTP is service oriented. Imagine a document service which could store, update, fetch or delete documents. Now replace document with resource in the earlier statement. Thats your typical HTTP service that REST works off of to implement a resource management service – but thats just a single service which is standardised for REST over HTTP. And all REST implementations will be service oriented to that extent. However the sheer simplicity and ubiquity of this service makes the associated service orientation of REST rather uninteresting and thus largely ignorable.
So next time one wants to debate the merits for REST and/or SOA – feel free to add to the tons of stuff thats already written. But don’t measure REST based on service orientation. Service orientation is largely irrelevant for REST. And that per se does not make one better than other – it just makes them different.
Note: There were many other points in the blog post I referred to that I would want to offer different opinions on. But in this case, I believed it was important to keep this post focused on an essential thought that I really wanted to emphasize.
Related posts: (Automatically Generated)
Dhananjay,
thank you for your response. I am glad we are in agreement that REST is not service oriented, and it is not because REST IS-A Service (not sure everyone would agree with that) you can build service oriented solutions from it.
As you may know the relationship between BPM and SOA is one of my dearest topic and the main reason for expressing so much negativity about REST. BPM has been crippled by extremely naive visions of what a business process is and unfortunately REST is pushing BPM further back. I have written an article explaining the relationship between BPM, resources and service orientation. I have even created a concept called WSPER to support it. Here is a link to the article: http://www.infoq.com/articles/seven-fallacies-of-bpm
When you describe a process in REST
>> The focus here is the tasks being done and the protocol for the task instructions. …
I am not sure you ever wrote one using the REST principles you describe. In case you have not noticed, and that’s the major lalaland argument of RESTafarians, the exchange of arbitrary metadata between two software agents without an a priori agreed upon meaning of this metadata is at best dangerous if not plain stupid. You either need a shared taxonomy or you need an out of band negotiation of the meaning of “data structures, actions,…” saying “I just ship metadata from A to B and automagically B understands what to do” does not make any sense. This is what -ALL- the RESTafarians are claiming. It (kind of) works when B is a human using a browser, it always works for sure when REST is limited to be the “Web Page CRUD Service” for which it was originally designed, but it is criminal to drive scores of people to believe that metadata can be exchanged without any a priori agreement.
As soon as you understand this point you realize all that is missing in REST to make it useful for anything as you build an Enterprise Solution, and frankly it is the main reason why RESTful examples are limited to simple, often CRUDish data access APIs because these don’t require much metadata exchanges.
Jean-Jacques,
Great to start off with an agreement on the fact that resource orientation and service orientation are two very different ways of approaching a problem, and REST does not emphasise service orientation. However this agreement quickly fades when we get to the remainder of your comment.
I cannot recall any single reasonably formal documentation about REST which asserts what you state above. What REST recommends is that you ship in band information so that apriori meaning of data is not mandatory – which is entirely different than saying that it precludes any apriori agreement. The tolerance to lack of apriori information is a function of the client agent sophistication – and we shall see agents with a variety of sophistication levels. I cannot imagine in the short run, sites offering REST APIs without offering documentation on the resource metadata. Thats why many sites which to offer REST / REST like API offer documentation wikis which break down that information about media types in some level of detail. REST precludes mandatory aprioriness (eg. as required by WSDL), it does not preclude aprioriness per se. Such apriori communication is really outside the scope of the agents and usually through simple wiki pages today. In the context of HATEOAS, there again is required some apriori information on the link types and media types. The apriori information that is not required is the URIs themselves. If you really look at it carefully – the aprioriness exists here too, its just been driven higher by one level of abstraction. Thus when agents can be built to a sophisticated level of capabilities, REST allows a mechanism of in band metadata communication that is not supported by WS-*. Thats the real difference. I think the danger and stupidity you state is a result of a misunderstanding that should be corrected.
Thats inconsistent with my understanding. REST examples are CRUDish because of the uniform interface imposed by HTTP. In fact I dwell in a fair detail on the topic in my earlier post CRUD is not only good for, but is the only consistent way to build REST over HTTP. Just like I made the distinction between service orientation vs. resource orientation, I would like to make another distinction between using CRUD for data access (as conventionally understood) and CRUD for resource access (as usually used in REST). The apparent simplicity of the CRUDish APIs is actually a strength when you view CRUD from a resource orientation perspective.
You are probably not reading the scriptures of Tim Bray, Steve Vinosky, Stefan Tilkov, Bill deHora, Bill Burke and so many others.
>> REST precludes mandatory aprioriness (eg. as required by WSDL), it does not preclude aprioriness per se.
We agree violently again. So why don’t we make all that very clear and you ask/convince your RESTafarians colleagues to stop making these lala claims that metadata automagically flows and HATEOAS can be used serendipitously in server-to-server scenarios.
>> it does not preclude aprioriness per se.
What is the point of using “documents” when you can have a machine readable artifacts? You think that “hand coding” is better than tool generation?
>> CRUD is not only good for, but is the only consistent way to build REST over HTTP.
CRUD is the worst coupling you can establish between two software agents, even between a human and software agent.
“This is what -ALL- the RESTafarians are claiming.”
Not me. That’s why I worked on RDF, which has an actual formal semantics. It happens to use URIs for identifiers but that’s not critical to the model theory. So given that mistake, the rest of your post doesn’t need refuting.
By the way, does the BPM family have semantics, or is it still scripting hooks doing the real orchestration work? That’s no more or less lala that saying a client can transition application state by traversing links.
Hello guys.
One think I learned long, long ago is nobody is totally right or wrong.
I do agree partially with Dhananjay (still disagree with the CRUD vision), and also partially with Jean-Jacques.
For instance, one of my opinions in SOA is that it is a myth that BPM is the natural couple of SOA. It treats SOA as a component that supports BPM. This is also converting SOA into an artifact that has no much value on its own if not used to support BPM. Furthermore, many BPM implementations are so focused on the IT part that forget BPM is all about business.
(This and other myths about SOA I presented in a short video in the Architecture Journal from Microsoft, in case you wonder)
So, getting back to the discussion of contracts, it is clear to me that there should be a shared knowledge, implicit understanding of concepts, a glossary (think IANA as a repository). As a user reads a login form and understands what to do, so an agent should be able to get a content type and know how to read it. It is like playing a chess game: not two games are equal, but you can play since you know how to move the pieces.
REST is extremely difficult to catch. HATEOAS is the least understood. That is what the goal is, at least to me: discuss until everybody is in the same page.
One thing is clear, and both of you got it right: SOA is not REST, and Services are not Resources. Now, SOA and REST are not aimed to the same goal either.
REST is a networked, hypermedia oriented style.
SOA is a business, message oriented one.
I would not have much problem to choose one of them
And If I need BPM, I would think first how is my solution architected. I would never replace BPM with REST, that makes no sense to me!
Cheers!
[...] for achieving SOA goals. One of the reactions he got on a previous post on this topic states that REST and SOA are incompatible, as REST is not about services but about resources or documents (with a standardized [...]