Bringing Messaging to REST Applications

If you’re an enterprise developer of mobile or web applications, you’ve probably used HTTP and a RESTful API to post data into your app server which in turn connected to a message bus for distribution to back-end assets. Getting data flowing back and forth is the tip of the iceberg – the real work lies in making it performant and resilient, and of course testing the heck out of it. That’s where direct easy access to a message bus can seriously accelerate your coding by taking care of those tedious parts of building, testing and deploying bulletproof services.

Here are some examples of what you get when a fully featured message bus is available to your application development:

• Publish/Subscribe: Your applications can use REST/HTTP to post information to a message broker which reliably delivers it to any number of recipients, from a few to many thousands.
• Fire and Forget: Once your application has posted whatever data to a message bus, it can take responsibility and guarantee that the information gets everywhere it needs to go. If any recipient is congested or disconnected, the broker will store (persist) the message and forward it once it’s available and every application that needs the information has received it.
• High Availability: Some message brokers (like Solace) have built in redundancy that makes it easy to achieve “five 9s” uptime.
• Disaster Recovery: With web applications it can be hard to set up your system so it keeps running without any message loss even if an entire datacenter goes offline, but a message bus like Solace can make that a simple matter of connecting and configuring brokers in each datacenter.
• Integration with legacy apps: Many existing back end systems are already connected to a message bus, so connecting your REST-based web applications to that same system lets them inherit integration with those assets.
• WAN optimization: Some message buses can compress and stream data over WAN links or the internet (again, with just configuration) to improve performance and bandwidth utilization, and keep WAN costs low.
• Simplified test and operations: Even with a messaging system in the mix you need to test before deploying, but the broker eliminates most of the tricky corner cases you’d normally need to address in your own code.

Web application design has revolutionized rapid prototyping and accelerated the delivery of services, and REST/HTTP have proven to be a flexible way to connect clients and servers across such an architecture. Bringing the power of a message bus to these applications makes it faster to develop advanced functionality, integrate from client to rich back end services and simplifying operations.

You may also want to check out this post Adding REST to Your Messaging to understand what those used to traditional messaging middleware get out of REST/HTTP from their perspective, and this overview of what it means to offer REST support in a messaging middleware platform.