This content is part of the Essential Guide: Guide: When and how to use REST

What role does an ESB play in RESTful integration?

ESBs may move from the central integration hub toward a specialized role integrating new RESTful architecture with legacy applications.

While there may be some that compare REST with XML, they really aren't competing approaches. In reality, you can...

probably group most approaches these days into three categories:

  1. SOAP-based Web Services
  2. SOAP-less Web Services implemented using XML/HTTP, with or without a formal schema
  3. True REST-style services utilizing the HTTP methods, MIME types and HATEOAS (Hypermedia as the engine of application state)

From what I've seen, there are more and more services being placed into category #2. What makes things confusing is that this category is almost always referred to as RESTful services, when in reality, they aren't. They're just XML-based services sent using the POST HTTP operation, without the SOAP envelope and WSDL. These services are more easily consumed by a browser-based consumer using JavaScript than a SOAP-based service. These services may also be exposed using JSON/HTTP, rather than XML, for even easier consumption by browser-based consumers; however, they still tend to rely on the POST operation for most, if not all, functions.

The use of SOAP-based Web Services is still quite common in the enterprise. Many packaged products expose their services using SOAP-based services with WSDL for the excellent tool integration that a well-defined interface provides, but it is increasingly common to see these services also exposed as XML/HTTP, or even true REST-style services.

In my experience, category 3 is still the least common approach, at least in the enterprise, but with use trending upwards. 

The role of the ESB

So how do these trends impact the role of the ESB? If anything, the increased emphasis on HTTP actually encourages more use of an intermediary-based approach. Think of how many intermediaries already exist for the HTTP space. You can have caching appliances, load balancers, web security products, and more. The real question is whether you still need an ESB, or you can get by with the existing HTTP-based intermediaries that already exist in most enterprises. 

The challenge is that the closer you get to option 3, the less likely that you will have a formal specification of the messages involved. Option 1 clearly has WSDL files, option 2 may still have XML schemas, but option 3 may nothing more than developer documentation on what to expect in response to a GET request, or what HTTP parameters will be accepted on a PUT or POST. This doesn't prevent the use of an intermediary such as an ESB, but it may require a lot more work to get things done.

The most likely scenario is still to rely on an ESB for bridging the gap from systems that fall into categories 1 and 2 (SOAP/HTTP, XML/HTTP) to consumers that want something from category 3. For example, there's no reason that you can't take a SOAP Web Service that has a getOrder() operation, and then use an ESB to expose that as a REST service accessed via a GET request to http://rest-services/order?id=xxxxx. This puts the ESB squarely into the integration space where you want to expose REST services from a system that is incapable of doing it, rather than as a general purpose intermediary through which all traffic flows. 

So, in short, there's certainly a place for intermediaries in any of the three approaches that I describe. One only has to look at the use of an HTTP load balancer in virtually any Web-based system to understand that. As for ESBs, their role is likely to be relegated to mediating between the REST-style interfaces desired and the interfaces exposed by the underlying systems involved. If those systems can't be modified, you're going to need something in the middle to bridge the gap, and an ESB might just fit the bill.

Dig Deeper on Topics Archive