Skip to content
This repository has been archived by the owner on Apr 14, 2022. It is now read-only.

First steps towards a high-level HTTP client API #195

Open
1 of 5 tasks
sethmlarson opened this issue Jan 23, 2020 · 0 comments
Open
1 of 5 tasks

First steps towards a high-level HTTP client API #195

sethmlarson opened this issue Jan 23, 2020 · 0 comments

Comments

@sethmlarson
Copy link
Contributor

sethmlarson commented Jan 23, 2020

@njsmith and I discussed what the next steps would look like for Hip to become less like urllib3 and more like what users expect from a high-level HTTP client.

  • Make a v0.1 release with the current code-base before changing everything.
    This will allow people including ourselves to play around with the code-base and
    hammer on the implementation, especially the async implementation.
  • Make modifications to our unasync configuration to have two top-level names ahip and hip instead of hip._async and hip._sync. This will probably require a change in unasync to make it more generic?
  • Create a top-level async def request(method: str, url: str) -> Response function within the ahip namespace and add a simple unit test for the function. Figure out how in the future we'll be writing tests for both async and sync.
  • Hide all of the "urllib3" API. We could accomplish this by basically adding underscores in front of everything. Keep all the existing unit tests the same for now and replace all names with the new _-prefixed ones.
  • Start adding existing features to the top-level request() function. When functionality is added to the top-level function migrate those unit tests away from testing the internal APIs and to only use ahip.request() and hip.request().

From there we're well on our way towards a v1.0. Let me know if we forgot any steps that you think are important, there's obviously a lot of work to do in addition to what's listed above but hopefully we can focus on the above list to get us closer to a stable user-facing API.

Each of the above tasks can potentially be turned into their own issue when we start working on them?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant