Thank you for your contribution to this. There are definitely things here that we need to incorporate into our code before publishing our alpha release.

However, the decisions you are making here needs to align with our principles and standards.
For instance, we need to think of everything in terms of Brokers, Services, Exposers (Clients) with a common protocol between them all which are the Models.

Creating things like Handlers and DependencyInjection in it's own classes doesn't quite align with our standards.

I highly encourage you to go through the contribution links learn about The Standard, The C# Coding Standard and The Standard Team - these docs will help you tremendously have a heavy contribution in this project.

Delegating Handlers are extremely useful in order to intercept and put something inside the request or do logging in a cleaner and concise way. Why should brokers contain such code that could be repetitive but not the part of the core business logic? Besides it's a MS recommendation. It acts like a HttpInterceptor in Angular.

Useful Links:

• HttpClientFactory and HttpClientHandlers in .NET Core
• Use DelegatingHandlers to centralize cross-cutting concerns in ASP.NET Core
• Delegating Handlers, Handlers and HTTP Interception with HttpClientFactory

Closes #106

Allowed consumers of Clients (Exposures) to implement

• Retry Pattern (Retry with or without Delay: Retry N times, put delay of x between each retry)
• Circuit Breaker Pattern with Exponential Backoff (after how many failures it should keep the circuit open and for how much time it should keep it open)
• Timeout Pattern (request times out if the operation is not completed within the specified timeout)

*** added seconds and milliseconds as the unit to measure the durations.
*** users can use string or numbers to specify the durations: 5, "5", "5s", "5ms" (default is millisecond)

Closing this due to inactivity