Is REST the Future of SOA?

It seems like everywhere we turn we keep hearing that SOA’sfuture is REST. There are a lot of publications comparing REST toSOAP and WS*[1], but such comparison seems to be toosimplistic. There are two main approaches that have emerged lately– true REST and REST as a technology approach for services (akaREST Web Services[2]). In this article I will try to discusswhether either of these approaches can improve SOAimplementations.

True REST for SOA

A true REST is effectively an implementation ofResource-Oriented architecture and not a pure technology decision.So the right question to ask when discussing true REST is whetherits underpinning – ROA - is a good fit for your SOAimplementation.

In order to assess the problem correctly, let’s first recallthat the SOA architectural style [2] is based on a functionaldecomposition of enterprise business architecture and introducestwo high-level abstractions: enterprise business services andbusiness processes. Enterprise business services represent existingIT capabilities (aligned with the business functions of theenterprise). Business processes, which orchestrate businessservices, define the overall functioning of the business.

REST, on another hand, is a set of architectural guidelines [3]expressed as Resource-Oriented Architecture (ROA). ROA is basedupon the concept of resources; each resource is adirectly-accessible distributed component that is handled through astandard, common interface. So, the foundation of ROA is aresource-based decomposition[3].

In order to assess the applicability of true REST for theimplementation of SOA, the real question that we need to answer is“What is the relationship between a service and a resource?”

Services vs. Resources

What is a service?

In the simplest case, a service can be defined as aself-contained, independently developed, deployed, managed, andmaintained software implementation supporting specificbusiness-relevant functionality for an enterprise as a whole and is"integratable" by design. A “Service” is defined by a verb ( Forexample, “validate customer’s credit score”, whichdescribes the business function it implements.)

A service is not a programming construct or a set of APIs, butrather an architectural (unit of design, implementation, andmaintenance) and deployment artifact used for implementation ofenterprise solutions. The service functionality is defined by aservice interface (specific for a given service), which can besupported by multiple implementations. There are two basic ways ofdefining a service interface – RPC-style and messaging-style.RPC-style implementations use service invocation semantics and aredefined through a set of parameters in the service interface. Inthe case of messaging style, a service interface is effectivelyfixed – it essentially performs “execute” - with an XML document asinput and output (much like the GoF command pattern). A servicesemantic, in this case, is defined by the semantics of the inputand output messages[4].

Historically, services are often defined as a collection ofmethods, but as explained in [2] these methods are independent fromeach other[5] and such collection serves as a namespace,simplifying the management of the services.

What is a resource?

In the simplest case, a resource can be defined as adirectly-accessible, independently-developed, deployed, managed andmaintained software artifact supporting specific data. A resourceis defined by a noun for example, “doctor’s appointment”that describes the data provided by the resource. A resource canalso relateto other resources and provide a reference (link) tothem. In effect, a resource is similar to an object[6], but with a predefined (CRUDish) interfacesemantic.

The semantics in REST are based on the set of HTTP operationsand looks as follows [5]:

• createResource - Create a new resource (and the correspondingunique identifier) - PUT
• getResourceRepresentatio<wbr>n - Retrieve the representation of theresource - GET</wbr>
• deleteResource - Delete the resource (optionally includinglinked resources) - DELETE (referred resource only), POST (can beused if the delete is including linked resources)
• modifyResource - Modify the resource – POST
• getMetaInformation - Obtain meta information about the resource- HEAD

A resource is defined by its URL and definition ofinputs/outputs for every operation supported by a resource[7]. Unlike a service, where methods arecompletely independent and can be deployed as independentendpoints, methods on a resource follow OO semantics, which meansthat all of them (except createResource) have to exist onthe underlying resource (same URL).

Basic differences between Resources and Services

Based on the above definitions of resources and services, itseems intuitively obvious that they are very different. Let’s delveinto these differences first, and then discuss how they can impactresulting architecture.

As stated in [6]:

“Not only is REST not service oriented, serviceorientation is irrelevant for REST”

And [7] goes even further explaining the differences between thetwo as:

“If WS-* is the RPC of the Internet, REST is the DBMS ofthe internet… Traditional SOA based integration visualizesdifferent software artifacts being able to interact with each otherthrough procedures or methods. REST effectively allows eachsoftware artifact to behave as a set of tables, and these artifactstalk to each other using SELECT, INSERT, UPDATE and DELETE. ( or ifyou wish GET, PUT, POST, DELETE). And where exactly is the businesslogic? Is it in the stored procedures? Not Quite. It’s in thetriggers.”

Here we will use a slightly different analogy, one based onJ2EE. We can think of services as stateless session beans andresources as entity beans.

Services – session beans – serve as controllers allowingexecution of a required operation, regardless of the underlyingresource. For example, a debit account service might take theaccount ID and the amount and debit required account. A singleservice can debit any of the existing accounts.

Resources – aka entity beans – serve as a data access mechanismfor a given instance of given data type. For example, in order todebit a certain account, it is necessary to find a resourcerepresenting this account and then update it to debit the requiredamount. An additional caveat here is that unlike an entity beanwhich can implement any required method, a REST resource has only asingle modify resource method. This means that the actualbusiness operation, the debit, has to be encoded as part of therequest.

What does this mean?

Based on the above, it is impossible to build an SOA systemusing true REST. It is possible to build a system, but it won’t beSOA. Both will start with the business-aligned decomposition, butbecause they are using very different decomposition approaches theywill result in completely different architectural styles[8] based on different set of components andconnectors.

Just because they are trying to solve the same problem –business/IT alignment and are both based on business drivendecomposition does not mean that the result will adhere to the samearchitectural style.

Another question is whether it is possible to build a completesystem using true REST. Based on the above, it is a question ofwhether it is possible to build a complete system using only adatabase or entity beans. Certainly you could, but it would requireadding procedural code in the form of stored procedures(overwriting the meaning of the methods) or triggers (doing postprocessing based on the data changes). The same is typically truefor a true REST implementation – you have to change the meaning ofthe modifyResource method (often using command pattern) to do morethan data update.

As a result, a REST-based implementation is rarely true REST; ittypically includes at least some elements of REST Web Services. Sowhat does it mean to be a REST Web Service?

REST Web Services

The REST Web Service approach is an approach for using RESTpurely as a communication technology to build SOA. In this case,services are defined using SOA style decomposition and REST-basedWeb Services[9] are leveraged as a transport.

Although commonly referred to as REST, this approach has nothingto do with true REST and is similar to POX (plain old XML overHTTP), with the difference being that in addition to XML, itsupports multiple other data marshalling types ranging fromJavaScript Object Notation (JSON) to ATOM to binary blobs andleverages additional HTTP methods, compared to POX, which istypically based on GET and PUT.

Using JSON became a very popular approach due to the advances ofWeb and wide-spread adoption of Ajax technology; the majority ofmodern browsers have built-in support for JSON. Since it is anon-trivial task to process XML (especially with multiplenamespaces) in JavaScript, it is much easier for web-basedimplementations to use JSON-based REST Web Services. Theproliferation of REST Web Services for Web interactions lead to theincreased popularity and wide spread of these technologies.

What is the real difference?

Publications describing differences between SOAP and RESTtypically point to the following advantages of REST Web Services,for example [11]:

• “Lightweight – not a lot of extra xml markup
• Human Readable Results
• Easy to build – no toolkits required”

Although these differences are important (I will discuss them indetail later in the article), the main difference between SOAP andREST is the fact that while REST is implemented directly on top ofthe HTTP protocol, SOAP introduces an abstraction layer (SOAPmessaging), that can be implemented on top of any transport.Standardized SOAP bindings currently exist for HTTP, SMTP and JMS,but non-standard bindings have been implemented for other transportsolutions. This additional abstraction layer that providesdecoupling between existing transports and SOAP-basedimplementations is the root cause of major differences between SOAPand REST Web Services.

The opinions about this abstraction layer vary significantlydepending on whom you talk to. The REST camp considers it to beover-engineering and claims that it does not provide any realvalue. They claim that HTTP already provides all of the featuresrequired for implementation of services interactions. The SOAPcamp, on the other hand, will argue that HTTP is not the onlytransport that is typically required for service interactions(especially inside the enterprise) and having a portable,extensible[10] abstraction layer is necessary forbuilding robust, feature-rich service interactions.

Although both points of view have their merits, in my experiencetrying to limit SOA implementation to a single transport – HTTP -rarely works in practice. Yes, HTTP is ubiquitous and its usagetypically does not require any additional infrastructureinvestments, but it is not reliable (HTTP-R is not widely adopted),synchronous only[11] (creating temporal coupling), does nothave transactional semantics and so on.

Additionally, even if HTTP is the only transport used inimplementation, the SOAP envelope can become very handy for a cleanseparation of business (SOAP Body) and infrastructure orout-of-bound (SOAP Headers) data in SOAP messages. And finally, ifyour original implementation does not require any infrastructure orout-of-bound data, the overhead of the SOAP envelope is minimal –two tags, but provides a well-defined way for adding such data asthe need arises.

So, at the end of the day, data enveloping with separation ofbusiness and infrastructure concerns is a very powerful paradigm,which is often used even in the REST Web Services implementations.Whether to use a standardized SOAP or a custom envelopingschema[12] has to be decided by a specificimplementation.

Other differentiators

Let’s take a moment to discuss some of the other differentiatorsbetween SOAP and REST Web Services often cited in publications.

Simplicity

A popular opinion is that REST is much simpler then SOAP.According to them, REST simplicity stems from the fact that RESTdoes not require WSDL or any interface definition. Such statementsare naïve, at best. No matter which technology is used forcommunications between service consumer and provider, they muststill agree on both syntax and semantic of their message exchange(interface)[13]. This means that in the case of REST, oneof two approaches is possible:

• Defining an interface in a text document and “manually” codingof data marshalling/unmarshalling based on a common interfacedefinition described in the interface document. Although such anapproach is often promoted by REST advocates, it rarely scalesbeyond 10 - 15 elements, which is not typical for coarse grainedREST services. Besides, such an approach is very error prone and asa result, most of the available REST frameworks have abandoned itin favor of the next approach.
• Defining an interface on the XSD level and generation of thedata marshalling/unmarshalling based on the preferred framework(for example, JAXB or Castor in the case of XML payload or Jackson,in the case of JSON payload). Such an approach is, in effect, aminimalistic version of WSDL and requires about the same amount ofeffort as SOAP-based implementations. In fact, exactly the sameapproach is often used in the SOAP-based implementation, leveraginga single interface and a command pattern for service execution. Theextension of this approach is usage of WSDL2.0 [13] and/or WADL[14] for REST.

Another common complaint about SOAP is perceived complexity ofWS* standards [15]. Although there is no single spec that lays outthe key WS*standards and their interrelationships, there is astandard for a majority of service interaction use cases. Granted,the choosing of an appropriate WS*standard and its usage mightrequire some extra understanding/implementation time, but [16]:

“Arguing simplicity versus standards is ridiculous in the warbetween REST and SOA because simplicity without standards is justas detrimental to the costs and manageability of an application“

So, with the exception of the most simplistic examples like“temperature converters”, REST is not any more simple thanSOAP.

Lightweight

Another reason why many REST proponents are advocating REST asan alternative to SOAP is the fact that in REST, both requests andresponses can be short. There are two main reasons for this:

• SOAP requires an XML wrapper around every request and response,which increases the size of a message. Although this is true, theimportant thing to consider here is not how many bytes thewrapper adds, but rather the percentage of overhead itcreates. Because the wrapper size is constant, this percentagedecreases as the size of the message grows, eventually becomingnegligible. Considering that a typical service is fairlycoarse-grained, the size of the request and reply is fairly largeand consequently the overhead of a SOAP envelope is rarely anissue.
• SOAP is XML-based messaging, which uses verbose encoding. REST,on the hand, provides a more lightweight messaging alternative –JSON[14]. Although this is true, usage of theMessage Transmission Optimization Mechanism (MTOM) [17], supportedby most SOAP frameworks, allows for splitting of messages intominimal XML-based SOAP Envelope/Header/Body parts and additionalparts containing message content that can be encoded as any MIMEtypes, including JSON, binary streams, etc.

Although in theory, REST is lighter-weight compared to SOAP, inpractice, with some advanced SOAP design techniques, the differencebetween size of realistic SOAP and REST messages can be mademinimal.

Easy to build – no toolkits required

Because REST is based on HTTP, one of the claims of itsproponents is that one can use familiar technologies like the Javaservlet API and Java HTTP support to write REST servicesimplementations and clients without any specialized toolkits. Thisis true if one wants to “manually” implement building input/outputmessages and data marshalling. The same can be done for SOAP WebServices as well. However, people rarely want to write suchboilerplate code and as a result use toolkits for both SOAP andREST [18].