This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - More on REST uses: Read more in this section
- REST architecture in health IT
- An ESB's role in RESTful integration
- Deploying RESTful services: Think like a developer
Explore other sections in this guide:
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:
- SOAP-based Web Services
- SOAP-less Web Services implemented using XML/HTTP, with or without a formal schema
- True REST-style services utilizing the HTTP methods, MIME types and HATEOAS (Hypermedia as the engine of application state)
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.