Why RestBus?

RestBus lets you easily send messages asynchronously or queue items using RabbitMQ.

Other messaging libraries make you define endpoints as methods that must follow a certain structure and can only respond to a predefined data transfer object. This forces the programmer to develop their service against the messaging library. Things have to be done the way the messaging library prescribes; potentially altering your application's design.

With RestBus, your endpoints are regular web service endpoints in a choice of frameworks (ServiceStack, Web API and ASP.Net Core).
You design your service like any other web service and call them via RabbitMQ. The message is routed from the RabbitMQ server directly into your service, without hitting the HTTP transport.

This comes with many advantages:

• Design and develop your services without worrying about the messaging interface.
• Easy to design and develop message driven RESTful services.
• Use features available in your favorite web framework like routing, middleware, logging etc.
• Take advantage of solutions from the HTTP world for well known service problems, such as versioning or batching.
• Developers do not need to learn a new framework to write message driven services.
• Migrate all your existing service endpoints to a message driven architecture with a few lines of code.
• Scaling your service horizontally is as easy as launching a new instance of the service.

Still not convinced?

The messaging architectural style championed by RestBus was envisioned by John O'Hara, the originator of the Advanced Message Queueing Protocol(AMQP) in a 2007 ACM Queue Article "Toward a Commodity Enterprise Middleware".

The key excerpt is:

"Web services has four basic parts: service description, XML message content, service discovery, and transport. The transport is commonly presumed to be HTTP, but it does not have to be. Enterprises often use XML over messaging middleware as the transport for all the benefits that brings. Having done this, enterprises find they have created the problem they wanted to avoid: running an open architecture over a proprietary transport. Combining Web services with AMQP as a transport gives the richness an enterprise needs with the openness it craves in its core architecture."