feat: add aiohttp support

[aarcex3]

Summary

Added support for aiohttp as api client

Question

Since the aiohttp.ClientResponse has different names for common attribute (status for status_code) and also they are async attributes (e.g response.json), maybe implement a generic Response and fill it up depending on the type of client?
E.g here it will fail or give an error since aiohttp doesn't have a status_code attr, idem here for json.

Related Issue

#4

PD

I didn't implement tests since there aren't tests for the other clients

[martinn]

Thank you for this! I'll have a look soon.

[martinn]

Hey @aarcex3 - thank you again for this and apologies for the delayed response.

Since the aiohttp.ClientResponse has different names for common attribute (status for status_code) and also they are async attributes (e.g response.json), maybe implement a generic Response and fill it up depending on the type of client?
E.g here it will fail or give an error since aiohttp doesn't have a status_code attr, idem here for json.

That sounds like a good idea. I'm also thinking whether it would be best for the BaseHttpClient to be a protocol as well, so it can provide a bit more flexibility. What do you think?

I didn't implement tests since there aren't tests for the other clients

There are some tests for the requests client here and here (the rest all use httpx by default). At some stage I would like to re-look at tests to ideally have one core set of tests that can be easily "parametrized" to use the different http client and serializer libraries, reducing a lot of duplication. But that's a job for another day.

[aarcex3]

That sounds like a good idea. I'm also thinking whether it would be best for the BaseHttpClient to be a protocol as well, so it can provide a bit more flexibility. What do you think?

I think we can try that

[aarcex3]

I dunno what it should look like though.

[martinn]

I dunno what it should look like though.

All good. I can have a look at that separately. It doesn't need to affect this PR.