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 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.
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.