7 reasons service oriented architecture and REST are perfect together

It's not a question of either/or with SOA and REST. It's a matter of how the two design approaches can be brought together.

Service oriented architecture and REST -- which is seen more with cloud and social applications -- are actually highly compatible approaches. SOA and REST have a lot in common, and it's time the two started interacting. 

It's not a question of either/or. Organizations would be best served adopting SOA and REST in tandem. "Both SOA and REST are commonly described as distinct architectural styles, each with its own design approaches that is carried out to attain specific design goals," relates a new book, SOA With REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST. "On the surface, it may appear as though we need to choose one architectural style over the other, depending on our own individual preferences and goals. However, that is not the case."

The book, co-authored by Thomas Erl, Benjamin Carlyle, Cesare Pautasso, and Raj Balasubramanian, makes the point that one is the medium by which the other can be implemented:

"The choice is not between SOA and REST but rather whether REST is the correct implementation medium for a service-oriented technology architecture, or whether service-oriented architecture is the correct architectural model by which a REST architecture should be formalized. The answer to either question depends on the business requirements that need to be fulfilled."

Erl and his colleagues draw distinctions as well as similarities between the two approaches, while noting that "there are no conflicts between REST and service-oriented computing goals:"

  • Service oriented computing goals are strategic and business-centric.
  • REST goals are technology-centric and can help achieve strategic or tactical business goals.
  • While not all REST design goals are relevant to each sercice-oriented computing goal, most REST design goals are directly supportive pf service-oriented computing goal.

The book describes common design goals for SOA and REST:

  1. Increased intrinsic interoperatability: "All of the REST design goals directly or indirectly support and enhance the interoperability potential of services within a service inventory."
  2. Increased federation: "Both REST and service oriented architecture have similar effects on federation. While the application of REST constraints can lead to consistency across service contracts with freedom from business context, service-orientation can add architectural layers that can drive an organization to achieve federation over a broader scope."
  3. Increased vendor diversity options: "Both service-oriented architecture and REST-style architecture advocate abstracting away service implementation details from service consumers to avoid negative forms of coupling that can inhibit vendor product independence."
  4. Increased business and technology alignment: This is the foundation of SOA, and the primary means by which REST can support this goal is in its emphasis on building flexibility into technology architecture."
  5. Increased ROI: SOA "has a primary focus on achieving return on investment through reusability, normalized service inventories, and mechanisms that enable the effective composition and re-composition of services. Reusability is one of the aspects of the modifiability design goal in that REST advocates leveraging reuse as a means of modifying, evolving and adding solution logic."
  6. Increased organizational agility: While organizational agility -- the holy grail of SOA -- is not a business-centric goal not directly addressed by REST, "each REST design goal can directly contribute to improving an organization's responsiveness. The REST constraints that directly contribute to agility on an organizational level are those that support abstraction, evolvability, and unforeseen change."
  7. Reduced IT burden: SOA subdues IT burdens by breaking down departmental silos, reusing and composing services, and decoupling services from their consumers so they can be upgraded independently. REST constraints make scaling services more efficient, individual services more reliable, and service upgrades more efficient."