Problem solve Get help with specific problems with your technologies, process and projects.

Integration methods: The pros and cons of REST integration with SOA

There isn't a shortage of success and failure stories with any integration method. Here's a look at when REST integration with SOA may be best.

What are the pros and cons of REST integration with SOA?

Todd BiskeTodd Biske

Before I delve into the details of the question, there is a point I want to clarify off the bat: Representational State Transfer (REST) and service-oriented architecture (SOA) are not competing integration methods. There are people that immediately identify SOA with Simple Object Access Protocol (SOAP), but the truth is, SOA doesn't specify any particular technology. SOA is simply an architecture of services; how you choose to have those services interact is completely up to you, and REST is certainly an option.

On the positive side, one of the uniform interface constraints of REST calls for all resources to have a uniform resource identifier (URI) and respond to the hypertext transfer protocol (HTTP) operations of GET, PUT, Power-On Self-Test (POST) and DELETE. These operations are roughly equivalent to the CRUD (create, read, update, delete) thinking of manipulating data. While POST and UPDATE aren't exactly equivalent, they certainly could be viewed that way.

Why REST is a good integration method

Why is this a good thing? In my experience, the vast majority of an enterprise's services are normally all about retrieving data. Rather than defining a bunch of custom application program interfaces of the form getThisAndThat(...), the HTTP GET operation can be used. It's not simply the use of the GET operation, it's the combination of the GET operation and URIs that make it work.

The URI gives you a unique key for a particular resource. If that resource has relationships to other resources, like an Order that is associated with a Person, the URIs are effectively the foreign keys that can be used to traverse those relationships. Because REST leverages hypermedia as the engine of application state (HATEOAS), all the consumer needs to do is extract the URI from the representation of the resource and perform an HTTP GET to access that information.

Simply removing WSDL and SOAP does not give you REST.

Using HATEOAS is also key to flexibility. What happens when the structure needs to change? If the traversal path to these relationships is dynamically specified through links in the response, your consumers may not change. Also, by not having a rigid interface definition and validation, elements can be added as needed. If a consumer cares about them, they'll have coding changes, but that will be the case with any technology.

HATEOAS is very important, and unfortunately frequently forgotten. Many people think REST just means getting rid of the SOAP envelope and the Web Services Description Language (WSDL), and that's not true. REST doesn't require an interface description language like WSDL, and is perfectly happy to work with not just Extensible Markup Language (XML), but also with JavaScript Object Notation and any other media type you choose to support.

This is a big strength, as it makes things very presentation-layer friendly, whether it be a desktop, Web or mobile application. But simply removing WSDL and SOAP does not give you REST. In the Person and Order example, returning XML for an Order that has an element called <PersonID> doesn't make it RESTful if the consumer can't just perform an HTTP GET on the value for that ID. Simple XML/HTTP does not give you REST.

The downside to REST

The biggest thing when looking at integration methods is to recognize that REST is much more aligned with a resource-oriented model than a function-oriented model. When I hear the word "service", my tendency is to think of function, and I've seen that same tendency in many other people, as well. When I heard the word "resource", my tendency is to think of data. As soon as you run into a service that is more function-focused than resource-focused, it may be tricky to determine how to represent that in a REST approach.

For example, what's the right way to expose calculation logic? In a more function-oriented model, like SOAP, you'd create a calculate operation. In REST, the right approach may be to focus on getting the value that is the result of the calculation, such as GET /order/12/price. While this example was easy to resolve, you will likely run into more challenging ones. Additionally, that resource-oriented model means you have to create that solid resource model. That is not an easy exercise. Of course, neither is coming up with a solid functional model.

Another challenge with REST is that it can lead to a more fine-grained model. When do you provide a link in your responses versus populating the actual data from a relationship? On the positive side, it is a design choice that you can make. There's nothing saying you can't return a link to follow, as well as some of the data itself. Think of it as doing a join, but also returning the foreign key so more data can be retrieved.

Finally, while the simplicity of REST can be quite attractive, it also means it's a little more challenging to create tooling to support it. If you think of tooling around SOAP or XML-based services, having WSDL or XSD (or both) is critical to enabling those tools.

With REST, it's a different story. There is certainly tooling that can take POJOs or a relational schema and expose it via REST. Likewise, there's nothing saying you can't define an XML schema for an XML representation returned by a RESTful service, and use something like JAXB to convert to Java. Just realize that reliance on these files, especially if the schema is leveraged at run time, create additional constraints that may make supporting change more expensive.

Overall, I'm glad the question was posed in the manner it was, rather than as a SOAP vs. REST debate. In decisions like these, there are pros and cons, and no absolutes. Anyone who has worked in IT knows there is no shortage of religious beliefs about approaches, and there are plenty of examples of both successes and failures with any given approach. It's more important to match the strengths and weaknesses of each approach to the strengths and weaknesses of your organization.

About the author:
Todd Biske is an enterprise architect with a global publishing company, working out of their office in the St. Louis Metro Area. He writes a blog about BPM and SOA and is the author of SOA Governance from PackT publishing.

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

Dig Deeper on Enterprise application integration