My post on Why I Prefer SOA to REST got some interesting commentary yesterday that indicates that I probably should clarify what I was talking about. The most interesting feedback actually came from email from some evangelists at Microsoft who had a bunch of criticisms from the fact that I dared to use Wikipedia as a definitive reference to pointing out that SOA is a meaningless buzzword. So I'll try this again without using links to Wikipedia or the acronym "SOA".

My day job is designing services that will be used both within MSN by a number of internal properties (Hotmail, MSN Spaces, MSN Messenger, and a lot more) as well as figuring out what our external web services story will be for interacting with MSN Spaces. This means I straddle the fence of dealing with building distributed applications in a primarily homogenous intranet environment and the heteregenous World Wide Web. When I talk about "distributed applications" I mean both scenarios not just Web service development or enterprise service development.

Now let's talk about REST. In Chapter 5 of Roy Fieldings Dissertation where he introduces the concept of Representational State Transfer (REST) architectural style he writes

5.1.5 Uniform Interface

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6). By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. These constraints will be discussed in Section 5.2.
...
5.2.1.1 Resources and Resource Identifiers

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

The REST architecture describes how a large interlinked web of hypermedia works which is what the World Wide Web is. It describes a way to build a certain class of distributed application, specifically one where you are primarily interested in manipulating linked representations of resources where the representations are hypermedia.

On to service orientation. The canon of service orientation are the four tennets taken from 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 lastthe availability and stability of a given service is critical. The aggregate system of services is built to allow for changethe 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.

One thing I want to point out at this point is that neither REST nor service orientation are technologies. They are approaches to building distributed applications. However there are technologies typically associated with both approaches, REST has Plain Old XML over HTTP (POX/HTTP) and service orientation has SOAP.

My point from yesterday was that as far as approaches go, I prefer to think of building distributed applications from a service oriented perspective than from a REST perspective. This is completely different from endorsing SOAP over using POX/HTTP as the technology for building distributed applications. That is a discussion for another day.


 

Tuesday, August 23, 2005 5:04:37 PM (GMT Daylight Time, UTC+01:00)
"My point from yesterday was that as far as approaches go, I prefer to think of building distributed applications from a service oriented perspective than from a REST perspective."

I think that REST (as an architectural style) doesn't give as much guidance in distributed application development as the 'SOA-philosophy' laid forth by Don Box. However, nothing in the quoted piece of Don Box excludes the use of an Uniform Interface, which in today's practice comes down to using HTTP methods appropriately.

I think it's wrong to think that if you fully make use of HTTP , all the rest 'comes naturally'. Fielding's disstertation, nor the HTTP spects give a complete view of distributed application development.

However, services with uniform interfaces are more valueable than services without them, and that's one thing you don't learn from Don Box piece (or the rest of the 'SOA (as in SOA+RPC) crowd'), but which can be learned from Fielding's dissertertation, or other pieces on REST.

I think you can have a SOA while sticking to the REST architectural style. They're not mutually exclusive.
Saying that you 'prefer SOA over REST' makes me think you prefer the 'freedom' of the RPC architectural style, so you can make up your own (non-uniform) interfaces.

If that's so, my question for you is: Why would you want to give up the advantages of exposing your service functionality through a uniform interface? What do you gain by making uo your own interface?
Meryn
Tuesday, August 23, 2005 5:24:33 PM (GMT Daylight Time, UTC+01:00)
Meryn wrote
"Saying that you 'prefer SOA over REST' makes me think you prefer the 'freedom' of the RPC architectural style, so you can make up your own (non-uniform) interfaces."

Going over the four constraints of REST in my excerpt from Fieldings paper

(i) identification of resources;
(ii) manipulation of resources through representations;
(iii) self-descriptive messages;
(iv) hypermedia as the engine of application state.

I think I agree that (i), (iii) and even (iv) are good ideas when it comes to building distributed applications.

You are right that the part I question is (ii) specifically in attempting to constrain the ways that resources can be manipulated. If the REST zealots are taken seriously then the only application protocol we need is HTTP and even WebDAV is heresy. Of course, you can always tunnel rich operations through POST in your REST application which is what protocols like SOAP and XML-RPC do but then you have an inconsistent interface where some actions are directed via HTTP methods and others via message payloads.
Tuesday, August 23, 2005 6:27:02 PM (GMT Daylight Time, UTC+01:00)
How about:

For read-only data, I do a GET with a querystring and get some data back, probably formatted in XML.

For writes, I do a POST of key/values or XML and get some data back, probably formatted in XML.

Done.
pwb
Tuesday, August 23, 2005 10:04:58 PM (GMT Daylight Time, UTC+01:00)
Thanks for explaining your position a bit further. Allow me to
elaborate.

"the part I question is (ii) specifically in attempting to constrain the ways that resources can be manipulated."

I can understand that position, because you should always weigh the advantages of contraining yourself (higher, possibly 'web-scale' interoperability) against the costs (extra development time, harder to understand API, less effective communications, etc). Those disadvantages are mostly felt when designing a non-CRUD service. Otherwise, you can quite easily map to the HTTP methods. Sometimes it's possible to model a non-CRUD operation as a combination of CRUD operations, but this can make things much harder to design and understand than just interpreting POST as 'process this message'. Just say what you want to do, and you're done.

I hold the position that you get the proverbial 80% of the benefit with 20% of the effort if you use GET for all safe requests, and leave the rest of the domain to POST. Today, there isn't much interesting (web-scale) stuff done on the base of PUT and DELETE. Yeah, things like the ATOM API use it, but that API wouldn't have been much worse if it had used POST. Generic (application-independent) support for PUT and DELETE is hard to find.

GET made the web possible. Just that one thing: being able to ask for the representation of a particular resource, indentified by a URI. Think about that.
Do you want your service to be on the web or off the web?
That's the question.

Yes, sometimes it doesn't matter if you're service is off the web. Sometimes you control all clients connecting to your service. Then they can be sure of the consequences of each and every request. No need for a uniform interface.

(Note: the web has grown on just to verbs: GET and POST. PUT and DELETE were not necessary. The key thing was the distinction between safe and non-safe.)

One thing too important to leave out.
Just using GET is good for things like crawlers, proxies and caching, but you also need a standardized representation format which at least supports linking, but preferabluy has standardized semantics. If you go the REST route, it would help enormously if you support a (X)HTML representation. Search engines can't do much with generic XML.

Just like you can't expect all clients to learn about a non-uniform interface, you can't expect clients to learn about a representation format with no standardized semantics.

"Of course, you can always tunnel rich operations through POST in your REST application which is what protocols like SOAP and XML-RPC do but then you have an inconsistent interface where some actions are directed via HTTP methods and others via message payloads."

In my view, that's NOT inconsistent. You make a clear distinction up front: you can either GET a resource representation, or you can POST a message to a (service-) resource, which will be interpeted by the server. You're doing a good job by making such distinction up front.

From http://www.intertwingly.net/blog/2005/07/22/REST-vs-API :

"At some point, you need to question the wisdom of having an API which abstracts away that which is important."
That's a great quote.
Meryn
Wednesday, August 24, 2005 1:26:49 AM (GMT Daylight Time, UTC+01:00)
(ii) isn't a bad idea, either. It's just that you have to know when to break it. I'm concerned that you think (ii) implies a limited set of verbs. That's something many "REST zealots" get wrong. REST has nothing to say about that, but it does imply that it's a bad idea to use a new verb when you mean "GET". The typical SOAP example "getStockQuote" is a classic anti-pattern.

WebDAV is "heresy" to some degree because of PROPFIND (GET for metadata) and other operations that don't treat things as discrete resources. This was a conscious decision--latency was the primary issue. WebDAV is not heretical because of MOVE, COPY, LOCK, etc. Those are extremely uncommon operations and it's not worth optimizing for them.

Lastly, the most common mistake "REST zealots" make is twisting the meaning of a common verb into something that doesn't fit its definition. For example, refining PUT as a partial update would change the definition of PUT (a diff payload is not the new state of the resource). What's really needed is POST or PATCH.
Comments are closed.