Adding REST to your Message Bus

If you are a veteran of messaging-based application design, you’ve gotten used to a rich set of services that help you get data where it needs to be. Messaging handles a diverse range of tough problems such as ensuring that information is received by each recipient once and only once, distributed to thousands of endpoints within microseconds or delivered even in the event that an application suddenly disconnects from the network.

Making HTTP and REST APIs “first class citizens” of your message bus opens up development and deployment options that let you can embrace everything that’s great about web and mobile programming without giving up the level of service you’re used to. Here are some examples:

• Zero client install: Anything with a browser, or a simple mobile app, can easily interact with back end services using HTTP, the most open and standard of protocols, without you needing to distribute your API in advance.
• Reach new endpoints: A related advantage is the ability to reach more diverse endpoints. Mobile phones, tablets, Internet of Things devices, web consumers – it’s hard for traditional message-based applications to connect with them because of the diversity of programming languages and operating systems you may have to port the API to. Have an Erlang application on an oddball IoT device? No problem, it can post to HTTP to initiate messaging. What about a cloud service written with Python in AWS? Yep, REST and HTTP will get you connected to the bus. This dramatically simplifies integration with back-end assets.
• Traffic flows through firewalls: REST/HTTP traffic can easily flow through firewalls, provided HTTP traffic is allowed (it almost always is). Sure, it’s possible to punch holes in the firewall to allow other traffic (like a messaging protocol), but many developers don’t have the support of operations to do so, or in many cases, don’t control the firewalls a client is behind.
• No copyright/licensing: Even if you were willing to take on the challenges of distributing client libraries and enabling protocols through firewalls, there are often legal or cost reasons why you may choose not to. Many commercial middleware products charge to distribute client libraries (Solace doesn’t), whereas REST/HTTP apps have none of these challenges.
• Rich third-party ecosystem: Just like you have your favorite test and management tools for your messaging system, web developers have an incredible array of open source or commercial choices to test, debug and extend their application function. This is one of the most powerful aspects of the web development movement, and these tools can now plug right into your message bus.

What has been a key up front decision – messaging or HTTP – is now really an unnecessary choice. Both architectures are good choices for solving a wide range of different kinds of problems. These two architectures are better together, each taking care of what it does best, and increasing the means to build the next generation of high volume and high value applications.

You may also want to check out this post on Bringing Messaging to REST applications for the complementary perspective, and this overview of what it means to offer REST support in a messaging middleware platform.