Closed stephanstapel closed 1 year ago
hey hey,
sorry for the late reply.
TBH I don't like the event approach. I'd rather define an interface like so:
public interface IBricklinkRequestHandler
{
Task OnRequestAsync(HttpRequestMessage req,
HttpResponseMessage res,
BricklinkCredentials credentials,
CancellationToken ct);
}
Its important to pass the utilized credentials to the callback for server scenarios in order to assign the request to the actual user.
Then, allow the BricklinkClientFactory.Build method to pass any number of request handlers:
public static IBricklinkClient Build(HttpClient httpClient,
IEnumerable<IBricklinkRequestHandler>? requestHandlers = null)
{
//... code
}
Then deep in the client's code where the `HttpClient.SendAsync' method is called right after the response all the handlers must be awaited before parsing and returning the results.
This approach allows to implement any mechanism to persist the #of API calls / day no matter whether it is a simple text file or an async DB call using EF with Dependency Injection.
BR Jens
thanks for the feedback. Events were quite easy to implement and it was easy to attach handlers to it without further interface and classes though. I will think about it for https://github.com/stephanstapel/BrickOwlSharp
Hi Jens,
I added an experimental API call event to the little sister library BrickOwlSharp using one of the oldest .net concepts, Events. Is this what you also intended for BricklinkSharp:
https://github.com/stephanstapel/BrickOwlSharp/commit/ecff57df06f7fcdc02818042d4e5c2bfcbab62d1
If yes, I volunteer to port this. If you have a better idea, it'd be great to discuss :)