ion232 / lichess-api

A Rust API client for lichess.org
https://lichess.org/api
Apache License 2.0
9 stars 7 forks source link

Make Client methods parameters more intuitive #65

Closed EpokTarren closed 1 month ago

EpokTarren commented 1 month ago

Improves the types used in Client methods and makes the API of these methods easier by:

  1. Removing parameters which don't have any options.
  2. Introduce Default implementations for Request<_ , _> where it makes sense.
  3. Implements From for some Request<_ , _> and accepts impl Into<Request<_ , _>> in Client methods.

There is a question which came up while writing this PR, model::board::seek::PostRequest has options which couldn't be set before, I left PostRequest::new as is but did implement From<PostQuery>. I think PostRequest::new should accept a PostQuery, though I may be missing something.

Closes #64

EpokTarren commented 1 month ago

I think being able to construct the requests from just mandatory data, or mandatory and optional data would be the next step. Not necessary for this PR though. If you have any thoughts, let me know.

Considering types with one non optional parameter I think I got all of the From implementations, as for optional data I think that might be impossible without macros in Rust since there are no variadic functions. Implementing From<(Mandatory, Optional)> would be possible though it feels clunky to me.

FooRequest {
    foo: Foo,
    bar: Option<Bar>
}

impl From<(Foo, Bar)> for FooRequest {
    /* ... */
}

// user
let client = reqwest::ClientBuilder::new().build()?;
let api = LichessApi::new(client, None);
api.foo((foo, bar));

At this point a named type would be easier to read, and if the user has to name that type they might as well name the request type. I think the only real alternative would be just be accepting the number of arguments into the functions or keeping it as is.