API seems rather unergonomic. about backblaze-b2-rs HOT 4 OPEN

The api I'm currently considering for the next version would look something like this:

// Create a private bucket.
let mut bucket = client.send(
    CreateBucket::new(&auth, &bucket_name, BucketType::Private)
)?;

// Make the bucket public
let updated_bucket = client.send(
    UpdateBucket::new(&auth, &bucket.bucket_id)
        .bucket_type(BucketType::Public)
)?;

What are your thoughts on this kind of api?

from backblaze-b2-rs.

I assume you're referring to the

where C: NetworkConnector<Stream=S>, S: Into<Box<NetworkStream + Send>>

on the upload file function on the master branch. It's a leaky abstraction that comes from not introducing my own Client type and using hyper's types directly — the connector is necessary because the connection requires https, but it would probably have been better to just put the connector in a Client object.

As for the lifetimes, are you referring to for<'de> InfoType: Deserialize<'de> or to the request types the library uses internally? The first should be replaced with InfoType: DeserializeOwned, as that is a simpler way of specifying the same thing. Generally I've never been quite happy with the InfoType abstraction, and it still exists on the ver0.2 branch. If you have better ideas for that one, I'm all ears.

Generally a thing I intend to change is to move the api calls away from being methods on the B2Credentials object, as it makes them hard to find in the documentation.

from backblaze-b2-rs.

but it would probably have been better to just put the connector in a Client object

👍

Oh so, InfoType is for free-form fileInfo. I'd just hardcode it to be JsonValue and if anyone wants a concret type, they can do the conversion manually later: https://stackoverflow.com/a/41721162/12271202

Generally a thing I intend to change is to move the api calls away from being methods on the B2Credentials object, as it makes them hard to find in the documentation.

Probably a good idea. Seems to me that I have to pass Client everywhere and that should be the only base class. Putting methods on different authorizations does not seem very beneficial.

Please make sure all applicable classes are Debug and Clone.

Seems to me that structs like B2Authorization should be split into B2AuthorizationResponse and core B2Authorization or something? This way when Cloned no everything will have to get copied. And there are things like allowed that are just random info, unnecessary later for authorization purposes, so no point in copying it around.

Some of my pain was the B2 API itself. It's rather weird. Like - I can't find a way to turn bucket id into bucket name or the other way around without having listBuckets permission, which means I'll have to ask the user for all of:

• app_key_id
• app_key
• bucket_id
• bucket_name

Writing libraries like this one is a lot of PITA. These APIs itself are often not very elegant, and it's hard to pick the right level of abstraction. When I did it in the past I've generally split the library into smaller crates. One crate would be only for data-types: Call1Request, Call1Response, Call2Request... and so on. This way anyone can take an http client etc. that they need and re-use just the type definitions. And then on top of it, I'd build a more opinionated API with some usability improvements, types conversions etc. But usually it's best to keep it rather mechanical and mapping 1:1 anyway because users typically come being familiar with the API (or at least looking at it's documentation) and 1:1 mapping allows them to quickly figure out what is what. Example: https://github.com/rust-bitcoin/rust-bitcoincore-rpc

from backblaze-b2-rs.

I like it. It probably gives much more room for customization / default arguments, etc.

from backblaze-b2-rs.