-
Notifications
You must be signed in to change notification settings - Fork 56
Philosophy and Goals
RestBus is:
Not in the SOA sense (although that is encouraged), but in the sense that you focus on developing and using your service endpoints, in your favorite web framework.
You don't waste time configuring your message broker or orchestrating a messaging platform.
Some benefits of having service endpoints in a web framework are:
- You can easily adhere to web service architectural styles such as REST.
- You can still consume your endpoints over HTTP or you can turn off the HTTP interface if you desire.
- You don't need to re-invent service constructs that already exist in HTTP, such as HTTP headers or verbs.
- You can plug in the bells and whistles provided by the web framework such as authentication, view engines, session, middleware, routing etc.
RestBus aims to make Message Oriented Middleware ridiculously easy to use in the most common scenarios.
If you can develop web applications with Web API, ServiceStack or ASP.Net Core and you are comfortable with .Net's HttpClient, then you can call your endpoints over RabbitMQ.
Your RabbitMQ installation does not need any configuration. RestBus will automatically create queues and exchanges as needed.
You know your service requirements and environment better than anyone else, so RestBus does not dictate how it should be used. There are no mandatory interfaces or serialization formats to follow. In fact serialization is completely optional.
Unlike most other messaging libraries, RestBus is not even interested in the datatype of your message.
You can send strings or binary objects to your service endpoint and RestBus is happy to transport them.
RestBus aims to be more like a library and less like a framework and is primarily concerned with providing a resilient, high performance, messaging layer. There are no higher level features like encryption, sagas or scheduling.
RestBus is lightweight and unopinionated.
The convenience of calling your service endpoints over a messaging layer should not require that performance is sacrificed.
RestBus uses a variety of high performance techniques and compares very favorably among other messaging libraries.
A long term goal of RestBus is to foster a service oriented, messaging ecosystem, where you don't worry about what message broker to use.
As an example, once Azure Service Bus is implemented (on the Roadmap), then you can switch your ASP.Net 5, Web API or ServiceStack service calls from RabbitMQ to Azure Service Bus and back, with relative ease and without modifying your services.
Similarly, once Nancy framework is supported (also on the Roadmap), you'll be able to call it from any supported broker.