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:
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.