Closed morenol closed 3 years ago
Once this PR gets merged we can start to implement separately the other APIs on top of this one. I am already implementing the CollectionsAPI. Maybe you could check the operations or aliases API? @emmanuelantony2000
Other than this, I think it could be merged.
One thing I wanted to point out here, the advantage of using hyper::Body, is that it allows us to stream the responses where required, and not store it directly to a vector and pass around. In wasm we have to extract the response anyways to a vec. But if that streaming feature is not required, we could do the same with the hyper implementation of send()
by using this function. And on an other note, we could use the Bytes
instead of Vec
@emmanuelantony2000 I changed from Vectype Response = http::Response<hyper::Body>
. Not sure why you pointed that, we could still use that feature, right?
Yeah, we could still use that feature. What I wanted to say was, what if instead of Response<Body>
we use Response<Bytes>
if we don't need that streaming feature for the client api? If that is fine, I think we could merge this.
I tried that quickly with: pub(crate) type HyperClient<C> = hyper::Client<C, Bytes>;
but got into this error: the trait 'HttpBody' is not implemented for 'bytes::Bytes'
. I will merge this and then we can decide if we need that or not
Change Summary
Added root client for the library. We should use this client to access the other API.
With something like this:
fn collection(&self) -> CollectionClient
fn operations(&self) -> OperationsClient
fn aliases(&self) -> AliasClient
Should solve #5
PR Checklist