refactor(async): refactoring async client and minor documentation improvements

[oleonardolima]

Description

It builds on top of #95. Applies minor improvements on some docstrings, and Cargo.toml standard.

The main change is adding the common HTTP methods for the AsyncClient, it removes duplicated code from each Esplora API request, and follows the approach done for BlockingClient.

It makes it easier to extract these methods into an AsyncEsploraClient trait (to be done in another PR, initially done here 9cbc3873c2a56258e13cb36e0e8c32039f0947a7), which the user can implement with any HTTP client of its choice. Also, makes it simpler to rebase and update the AsyncAnonymizedClient from #67.

Notes to the reviewers

It has some commits from #95, as it builds on top of it and should be merged afterward. Please let me know what you think about the proposed changes and approach.

Changelog notice

• Applies minor improvements on documentation.
• Add common get_response and post_request methods to AsyncClient, previously duplicated through the esplora API calls. It follows the approach done for BlockinClient.

Checklists

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines
• [x] I ran cargo fmt and cargo clippy before committing

[coveralls]

Pull Request Test Coverage Report for Build 10530778457

Details

• 104 of 123 (84.55%) changed or added relevant lines in 2 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+1.3%) to 88.792%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/async.rs	102	121	84.3%
<!--	Total:	104	123	84.55%	-->

Files with Coverage Reduction	New Missed Lines	%
src/lib.rs	1	97.08%
<!--	Total:	1		-->

Totals
Change from base Build 10514244019:	1.3%
Covered Lines:	1014
Relevant Lines:	1142

---

💛 - Coveralls

[ValuedMammal]

A recent PR #87 exposed a get_request method for the blocking client that returns a new Request, would you want to do a similar thing for the async client?

[oleonardolima]

A recent PR #87 exposed a get_request method for the blocking client that returns a new Request, would you want to do a similar thing for the async client?

IIUC exposes a get_request because it does not have a minreq client as a field on BlockingClient, as minreq does not have this "strategy" as reqwest has :think

I think it could be helpful to get exposed in async/reqwest too, I'll check it.

[ValuedMammal]

A recent PR #87 exposed a get_request method for the blocking client that returns a new Request, would you want to do a similar thing for the async client?

IIUC exposes a get_request because it does not have a minreq client as a field on BlockingClient, as minreq does not have this "strategy" as reqwest has :think

I think it could be helpful to get exposed in async/reqwest too, I'll check it.

Ah ok so maybe not necessary since you can already get a handle to the reqwest::Client?

[oleonardolima]

A recent PR #87 exposed a get_request method for the blocking client that returns a new Request, would you want to do a similar thing for the async client?

IIUC exposes a get_request because it does not have a minreq client as a field on BlockingClient, as minreq does not have this "strategy" as reqwest has :think I think it could be helpful to get exposed in async/reqwest too, I'll check it.

Ah ok so maybe not necessary since you can already get a handle to the reqwest::Client?

Yes, that's what I thought.

[oleonardolima]

ACK 9cb662a

Overall this looks great.

In 9cb662a

refactor(async)!: add common GET and POST methods

Maybe I missed it but I didn't see how this change is API breaking in any way?

Sweet! I updated the commit message, and add a new one applying the same style on other methods.

[oleonardolima]

I rebased this one on top of master, as #95 got merged. It should be ready to go now.

[oleonardolima]

fyi: I'm attempting to fix the code coverage CI step issue on #96.

[evanlinjin]

@oleonardolima since it seems we are planning to go down the #97 route, is this PR still relevant?

[oleonardolima]

@oleonardolima since it seems we are planning to go down the #97 route, is this PR still relevant?

I guess this one can still land if we'd like to cut a release with these improvements, and mainly with #98. Then, cut a new release specifically with the refactor of #97. 🤔