bobertoyin / mbta-rs Goto Github PK

Is your feature request related to a problem? Please describe.
There's not much of a reason to consume the plottable data when only references to the data fields are necessary.

Describe the solution you'd like
Change function signature from fn plot(self... to fn plot(&self...

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
The Client struct doesn't mutate itself, so it should be handy enough to add these traits to the client in order to make it work better with multi-threaded use-cases.

Describe the solution you'd like
Derive/implement the above traits for the struct.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
Query parameters for endpoints are currently expected to be of HashMap<String, String>: this type is generally too inconvenient and restrictive and could be loosened to be easier to use.

Describe the solution you'd like
Internally, each endpoint function iterates over each key-value pair and only uses the &str values: this means that we could have some generic parameter that implements IntoIterator<Item = (AsRef<Str>, AsRef<Str>)> (this is obviously not what it'll look like in Rust, but it captures the essence of what the generic should look like).

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
The MBTA V3 API contains a lot of latitudinal and longitudinal data: it'd be cool to provide some simple, optional functionality to plot this data!

Describe the solution you'd like
Leveraging the staticmap crate seems to be the simplest solution: it's a no-frills library that can render the simplest elements necessary (lines, circles, icons) without being too hefty of an addition.

Describe alternatives you've considered
There are plenty of crates related to OpenStreetMap and Google Maps, but none of them are quite as "batteries-included" a.k.a "no-implementation-required" as staticmap.

Is your feature request related to a problem? Please describe.
Currently, invalid request errors are boxed into a high-level client error; this isn't particularly helpful in diagnosing what specific issues the MBTA API had with the request (typically invalid query parameters or non-existent resources).

Describe the solution you'd like
ureq errors have a Status error that contains a status code and a response object with a known schema. This means that a helpful "error" response could be returned that indicates to the user what issues the API had with the request. Refactoring would convert the existing Response struct into an enum with some kind of Success variant and Error variant, with the Success variant containing the current Response schema and the Error variant containing the error response schema.

Describe alternatives you've considered
N/A

Additional context
N/A