Writing a client library for a web service

[curoli]

Hello,

I need to query some data from Ensembl, a popular web service to look up genomic data, so I'm writing some Rust code to do that.

And then I thought that maybe, just maybe, I might turn my code into a library and share it. So I'm wondering how to deal with the choice of HTTP client and async versus blocking.

• I could pick an HTTP client library like reqwest, choose to make it async, and just build on top of that. That would make writing it easier, but force users to deal with async and it would pull in all reqwest dependencies.

• I could pick reqwest, but make it blocking, which would make it easier to use.

• I could try to support both async and blocking, but that would make it more complicated, and I'm wondering whether I need feature flags.

• I could try to be agnostic of client library and async versus blocking and focus on building the URL/URI and turning JSON trees into more suitable data objects (or vice versa for POST), and leave the choice of HTTP client and async versus blocking to the user. That would give users flexibility, but also some extra work. Also, I'm not sure whether there is a standard way to provide a validated URL/URI or a JSON parser.

Any advise? Thanks!

Best, Oliver

[semicoleon]

I know rspotify does the switching between blocking and async code so it might be worth looking at how they do it and how much work it appears to be.

I would say if you were planning on using a blocking client, you can just release a blocking version. It's relatively trivial to bridge blocking code in an async context and the vast majority of use cases won't benefit all that much from having an API client in "native async" anyway.

If you were planning on using an async client to make your requests anyway it might not be as much extra work to support both.

[curoli]

Thanks for the advice, I think I'll start with a blocking client.