August 21, 2005
@ 12:47 AM

Yesterday I was chatting with Matt after he reviewed the paper I plan to submit for the next Bill Gates Think Week and he pointed out something that had been nagging me about using REpresentational State Transfer(REST) as a model for building distributed applications.  

In the current Wikipedia entry on REST, it states

An important concept in REST is the existence of resources (pieces of information), each of which can be referred to using a global identifier (a URL). In order to manipulate these resources, components of the network (clients and servers) communicate via a standardised interface (HTTP) and exchange representations of these resources (the actual files uploaded and downloaded) -- it is a matter of debate, however, whether the distinction between resources and their representations is too Platonic for practical use on the web, though it is popular in the RDF community.

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering", another constraint of REST and a common principle in many other parts of information and networking architecture). Thus an application can interact with a resource by knowing two things: the identifier of the resource, and the action required -- it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML or XML document of some kind, although it may be an image or any other content.

Compare the above to the typical notion of service orientation such as that espoused in the article A Guide to Developing and Running Connected Systems with Indigo by Don Box where he wrote

In Indigo, a service is simply a program that one interacts with via message exchanges. A set of deployed services is a system. Individual services are built to last—the availability and stability of a given service is critical. The aggregate system of services is built to allow for change—the system must adapt to the presence of new services that appear a long time after the original services and clients have been deployed, and these must not break functionality.

Service-oriented development is based on the four fundamental tenets that follow:

Boundaries are explicit   A service-oriented application often consists of services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments...Object-oriented programs tend to be deployed as a unit...Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. While individual services are almost always deployed atomically, the aggregate deployment state of the overall system/application rarely stands still.

Services are autonomous   Service-orientation mirrors the real world in that it does not assume the presence of an omniscient or omnipotent oracle that has awareness and control over all parts of a running system.

Services share schema and contract, not class   Object-oriented programming encourages developers to create new abstractions in the form of classes...Services do not deal in types or classes per se; rather, only with machine readable and verifiable descriptions of the legal "ins and outs" the service supports. The emphasis on machine verifiability and validation is important given the inherently distributed nature of how a service-oriented application is developed and deployed.

Service compatibility is determined based on policy   Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.

The key thing to note here is that REST is all about performing a limited set of operations on an object (i.e. a resource) while SOA is all about making requests where objects are input and/or output.

To see what this difference means in practice, I again refer to the Wikipedia entry on REST which has the following example

A REST web application requires a different design approach than an RPC application. In RPC, the emphasis is on the diversity of protocol operations, or verbs; for example, an RPC application might define operations such as the following:


With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following two resource types

 User {}
 Location {}

Each resource would have its own location, such as Clients work with those resources through the standard HTTP operations, such as GET to download a copy of the resource, PUT to upload a changed copy, or DELETE to remove all representations of that resource. Note how each object has its own URL and can easily be cached, copied, and bookmarked. POST is generally used for actions with side-effects, such as placing a purchase order, or adding some data to a collection.

The problem is that although it is easy to model resources as services as shown in the example in many cases it is quite difficult to model a service as a resource. For example, a service that validates a credit card number can be modeled as a validateCreditCardNumber(string cardNumber) service. On the other hand it is unintuitive how one would model the service as a resource. For this reason I prefer to think about distributed applications in terms of services as opposed to resources.

This doesn't mean I don't think there is value in several aspects of REST. However I don't think it is the right model when thinking about building distributed applications.


Sunday, August 21, 2005 4:00:01 AM (GMT Daylight Time, UTC+01:00)
Dare, "unintuitive" is a rather subjective term. OOP is very unintuitive for those who have been writing JCL and Fortran-77 all their lives.

Your example has a rather simple RESTful model. All you need to ask is "what is a resource?" In this case, the resource is a collection of valid credit card numbers. So, all you do is a GET request, which specifies the card number and get either 200 or 404 status code, depending on whether the card is valid.

The main point is that REST is the architectural style that models what is really going in HTTP communication, which allows you skip reinventing the wheel every time. Just like with microformats, it's all about the baseline semantics.
Sunday, August 21, 2005 4:09:01 AM (GMT Daylight Time, UTC+01:00)
That's an interesting approach. Modelling every service that verifies the membership of an object in a particular set as a collection of resources which are valid members of the set does get the job done.
Sunday, August 21, 2005 11:41:43 AM (GMT Daylight Time, UTC+01:00)
Dare - Actually I'm surprise by your position on this, if I had to guess I would have seen you as a REST guy. Not sure what that means.

Dimitri is correct in that the architectural styles have 'connotations' of the underlying transport, with REST treating HTTP like an application protocol. I think it is very rare to think about a REST style outside the infrastructure we already have around the 'web. They is also additional mental baggage around the styles that Services can tend to mean a ‘let’s make it easy to use RPC style bindings’, while REST is obviously not OO and keeps the cost of the boundary ‘real’.

One thought is that Services can be modeled in a 'resource' way when appropriate too, i.e. 'entity services'? Perhaps all ‘Services’ aren’t the same style, just like real classes? If you wanted to provide a HTTP binding that is restful for the services then you can too, they are not entirely mutually exclusive approaches (as long as you start with Services I guess).

The thing that keeps me up late thinking about this (as a SOA 'advocate' with skin in the game) is that historically it is often the simplest solution that has won through in the end. Even enterprise architectures learnt HTML with 'View Source...'

What might happen is that the grass-roots or consumer level services in a HTTP/REST style will get 'industrialized' for the enterprise, rather than the other way around of the enterprise services being 'made easier' for general consumption.

The other thing about REST, as pointed out about Tim Ewald the other day, is that for two strangers to meet up and integrate without a priori information, then the chances are it will be HTTP first. One of key (unwritten) tenets of Services is to be transport-agnostic, which might not be the 80/20 case after all.

I've gone from firm conviction for SOA over the last couple of years to being aware of a few other styles now. Interesting times ahead.

- David
Sunday, August 21, 2005 6:44:18 PM (GMT Daylight Time, UTC+01:00)
Things aren't black and white. It is quite obvious to me that building services on the Web in a RESTful manner [or at least using POX] is preferrable to other approaches when it comes to increasing the reach of the service.

However I'm not sure actually modeling this services in a resource-centric manner as opposed to a service-centric manner sits right with me.
Sunday, August 21, 2005 7:03:56 PM (GMT Daylight Time, UTC+01:00)

Understood, I wasn't trying to imply one was better than the other, or that you didn't already see the 'Reach' argument.

I think my (albeit vague) point was that sometimes you can model both ways in the same app model, dependant on which part of the API/data you want to expose. This can lead to odd things like WS-Transfer, but is just another way of saying that, indeed, it isn't a black or white decision.

- David
Sunday, August 21, 2005 8:08:15 PM (GMT Daylight Time, UTC+01:00)
REST resources can be services as well. The only thing you have to grasp is that if you go REST, then if you make a HTTP request, the operation is either GET, HEAD, PUT, POST or DELETE. This may seem 'limiting' in some way, but it isn't.

POST means 'process this message'. The meaning of the message can be anything. So within the realms of POST, there are no contraints. You can go all RPC-nuts there if you like. :)

It's not the end of the world if you communicate through the POST operation only. The disadvantage is that clients you don't control can't make any assumptions of the consequences of a POST request. POST can mean anything.

Therefore, if you are able to say: Well, this request to my application won't change any data of my application, and doesn't commit the client to anything (i.e. it's 'Safe'), then you should use GET. Now, all HTTP clients in the world know that they can safely issue these kind of requests. This enables things like caching and indexing.

Data that is exposed through GET can be indexed by a generic indexing machine, data exposed through POST can not.

The value of an architecture lies in its contraints.
RPC is more general than REST, and therefore less powerful.

A restful service has more value than a non-restful service, because parts of a restful-service can be understood by many, many more clients.
Monday, August 22, 2005 10:39:46 AM (GMT Daylight Time, UTC+01:00)
That some technology is difficult to model does not seem to me to be a proper argument against using the technology. It could just as well be an argument against the modelling.
Monday, August 22, 2005 2:58:13 PM (GMT Daylight Time, UTC+01:00)
As far as I am aware neither SOA nor REST is a 'technology'. Secondly I don't see anywhere I argued against using either. I described a problem I have with modeling distributed applications as a collection of resources as opposed to a collection of services. That's all.

However Dimitri has pointed out an interesting way to model a class of services as resources in his comment.

Monday, August 22, 2005 3:14:59 PM (GMT Daylight Time, UTC+01:00)
Well, it depends on what kind of distributed application you are trying to build. Ironically, I've found SOA insufficient for distributed applications centered around XML documents as the primary resources (see:
and I personally think both architectures complement each other (and camp warefare isn't neccessary) and developers should think their application through before deciding which works for them.
Monday, September 26, 2005 2:49:40 PM (GMT Daylight Time, UTC+01:00)
Now that I've read about REST due to your article being published, never having heard of REST before, I must admit like REST much better than SOAP :-) State is naturally a resource. It all sits well with me. BestRegs -R
Comments are closed.