Can a SOA be designed with REST?

Question

I've been reading a lot about SOA's lately, but most of the content is SOAP-related and has a lot of "bureaucratic" stuff that belongs to C#/Java systems. Honestly, i think that such bureaucracy, specially SOAP, is a pain in the ass. So, i'm curious, can a SOA be designed with REST?

Right now in by Ruby applications i make all my controllers RESTful. My web interface (forms, etc) make GET/POST/PUT/DELETE requests to the core, which is a REST webservice. All other systems that use the core make RESTful requests to it. Is this a SOA?

Answer 1

At a high Level the answer is Yes, however not completely.

SOA requires thinking about the system in terms of

• Services (well-defined business functionality)
• Components (discrete pieces of code and/or data structures)
• Processes (Service orchestrations. Generally using BPEL)

Being able to compose new higher level services or business processes is a basic feature of a good SOA. XML, SOAP based Web Services and related standards are good fit for realizing SOA.

Also SOA has a few accepted principles - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

• Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
• Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
• Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world.
• Service reusability – Logic is divided into services with the intention of promoting reuse.
• Service autonomy – Services have control over the logic they encapsulate.
• Service granularity – A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
• Service statelessness - Services minimize resource consumption by deferring the management of state information when necessary
• Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
• Service composability – Services are effective composition participants, regardless of the size and complexity of the composition.

A SOA based architecture is expected to have Service Definition. Since RESTful web services lack a definitive service definition (similar to wsdl), it is difficult for a REST based system to fulfill most of the above principles.

To achieve the same using REST, you'd need to have RESTful Web Services + Orchestration (possible using some lightweight ESB like MuleESB or Camel)

Please also see this resource - From SOA to REST

---

Adding this part as clarification for below comment -

Orchestration is required to compose processes. That's what provides the main benefit of SOA.

Say you have a order processing application with operations like -

• addItem
• addTax
• calculateTotal
• placeOrder

Initially you created a process (using BPEL) which uses these operations in sequence. You have clients who use this Composed Service. After a few months a new client comes who has tax exemption, then instead of writing new service, you could just create a new process skipping the addTax operation. Thus you could achieve faster realization of business functionality just by re-using existing service. In practice there are mutiple such services.

Thus BPEL or similar (ESB or routing) technology is essential for SOA. Without business use, a SOA is not really a SOA.

Cross posted on my personal blog - http://blog.padmarag.com

Also check this new resource I came across - REST based SOA

Answer 2

Service in SOA terms is a component which solves a certain business problem. SOAP/WCF are more related to the interface/delivery part of SOA. REST approach can be used as well. Service contract, policies, versioning and other 'standard' SOA features can be also implemented with RESTful service.

Main RESTful problem is that it's CRUD-targeted, therefore it would be not the best choice for complex logic implementation. But if your business logic is completely CRUD (or converges to CRUD), then it should be all right.

Btw, looks like Microsoft added operations to WCF data services specially to emulate SOAP with REST.

Answer 3

The most important thing about SOA is the soft factors eg getting other people to use your services and visa versa to that end having a wsdl link from which you can build an easy to use proxy is almost esential. Services need to be composable .. but you do NOT need Orchestration , BPEL or a fancy bus to do this in and i would not recommend them when your starting with SOA. ( in fact having used these i think you can get better results without them but you do need events )

Note products like WCF allow you to create a service which exposes a wsdl , but besides SOAP you can also use REST/Json or even better binary TCP end points .. This is ideal since you use SOAP for simplicity and switch to binary ( which blows REST out of the water) when you need to.

As far as SOAP goes in 8 years of building high performance SOA systems with WCF i have never noticed SOAP was even there.. that is because i mainly work in C# and we have a good SOAP stack .. most other languages do not.