Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Making the choice: How to choose between REST and SOA applications

Whether REST or SOA applications should be used depends on where development started and component type.

Software architects have long been vying to create compostable applications from multiple linked components. This model offers better development economy and easier application lifecycle management (ALM), but it raises a question of the software model for componentization.

Should applications be based on the lightweight Web-model representational state transfer (REST) or on the business-proven service-oriented architecture (SOA)? The answer depends on where the development began, the nature of the components and the extent to which the applications are likely to be linked to thin-client applications.

Key differences between REST and SOA applications

Man choosing between two directions

The greatest difference between REST and SOA applications is likely the mechanism with which they control state, which is the context of a given message in the overall flow of processing a worker transaction or request. The software design needed to support these two state-control strategies is very different. The first question an architect has to ask is whether software in place has already made the REST versus SOA choice by default. With SOA, state control typically rests with each of the components. The relationship between components has to be maintained through a logical process so individual messages aren't interpreted out of context. With REST, state is transferred from component to component as part of the message.

The second most significant difference between REST and SOA applications is that the latter typically has a more robust facility for describing the interface between components and binding based on interface and functional capabilities. While it's possible to manage component binding in RESTful processes, and even to have browsing and dynamic binding, the facilities are more limited and far from standardized. That means that for highly dynamic component workflows, SOA may be better.

Adapting applications based on legacy design

As recently as 2010, companies reported that most of their business applications had evolved from designs and code developed at least five years ago. Their software practices were modular in execution but not componentized, and thus there was no particular consideration given to issues of componentization and workflow steering. Even where later work created components and workflows, companies report that basic application logic has remained largely intact.

Where an application is largely based on legacy design, it is almost certain the application was written with stateful components. This means adapting the application to REST would be considerably more difficult. SOA, on the other hand, can easily accommodate stateful components.

Stateful Web services can usually be created from legacy applications without serious reworking. If an application is relatively mature, it can be assumed SOA componentization should be used unless there is a clear need to redesign the application.

Where new applications or new components are being developed, the burden of legacy design is less likely to make a REST versus SOA choice for you. Here, the question may be the nature of the interactions among components. There are two things to look for: the need for horizontal scaling or cloudbursting and the need for multi-phase commit or reliable transaction processing.

Implementing REST and SOA application hybrid designs

The greatest difference between REST and SOA applications is likely the mechanism with which they control state.

Since RESTful interfaces between components carry necessary state information with the messages, it's easy to spawn additional copies of a component to accommodate changes in workload, or to spin down one or more copies when work lightens. With SOA, this type of scaling is more complicated because a new component may not inherit processing state correctly and thus process messages in the wrong context. Generally, the more Web-like or cloud-like an application is, the more likely it should be built with RESTful interfaces.

Where transactions must update multiple databases, however, SOA may shine. Multi-phase commit -- the finalizing of a transaction only when all the impacted databases have been updated -- is easily handled in SOA, but will require some design finesse in REST. It's not possible to do reliable transaction processing without some stateful component, so a hybrid of REST and SOA applications is needed at the minimum, and possibly a complete SOA implementation.

Hybridization could be a useful notion for anyone going through the REST versus SOA decision process. It's possible to build a componentized application using both approaches. In fact, this is often done when Web-server front ends are employed with more traditional application servers. 

Computational tasks and database access can be made into RESTful components that can horizontally scale as needed. Where strict transaction reliability is mandated, workflow could shift to a SOA-based interface to permit precision control of state even during a component or network failure.

Determining the need for dynamic binding

The need for dynamic binding in applications is difficult to assess. Some users say they rarely need or use SOA facilities to describe interfaces in a catalog for selection, where others feel it's a helpful capability. SOA binding definitions may be valuable in ALM itself where :

  • an application crosses company boundaries with workflow;
  • a high degree of componentization is expected;
  • a high level of component reuse is anticipated; and
  • many developers may be working with a common set of components.

For general applications, one must consider how often binding of components will change.

The final issue is the data presentation question: whether the application will support dynamic-based client devices, such as would be the case for mobile empowerment. Mobile connections are less likely to be reliable.

Careful transaction control will be important, but SOA interfaces to mobile devices are rarely used. This creates a distinct REST-SOA front- and back-end model. If application development is on the front end (or presentation side) then REST is the preferred choice. But if so, SOA or some form of transaction recovery will be critical on the back end.

Best practices should always give a nod to current practices, too. A company with considerable SOA experience and little experience with RESTful interfaces should think twice before shifting for a single application, and vice versa. The team's skills are the final decision-maker.

About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.

Follow us on Twitter @SearchSOA and like us on Facebook.

Next Steps

Choosing between REST and SOAP

REST or SOAP for mobile apps?

SOA e-commerce app uses REST and SOAP

Dig Deeper on REST, SOAP and API protocols

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Which do you use more often?
well , actuaIIy i didn't decide,i'm a developer and develop existing system.I didn't have knowledge about Rest but now because of start developing Floodlight project i have to use REST.
REST Developer
SOA and REST are in no way mutually exclusive. I would argue that RESTful applications are better suited to an SOA environment because you are eliminating the burden of maintaining state on the client side. I wonder if the author is treating these concepts with some "proprietary" semantics.
SOA can be accomplised by either RESTful services or SOAP based services.
Good point about the legacy application. SOAP is based off of "action based interfaces" - "Get PO" or "Update Customer" and so on which is a traditional implementation pattern on legacy applications. So, it is easy to move from legacy to SOAP based services towards SOA adoption. As SOAP based services emphasize heavily on messaging styles, learning curve for organization is significantly smaller compared to REST implementation. REST needs different kind of thinking - treating your assets as resources and providing APIs for that. Two very different strategies.