bobertoyin / mbta-rs

A Rust client to interact with the MBTA V3 API.

MBTA-RS

---

A simple Rust client for interacting with the Massachusetts Bay Transport Authority's V3 API*

*This project is not affiliated with any official development work from the MBTA

About

The MBTA V3 API is described as:

A fast, flexible, standards-based API for schedules, arrival predictions, vehicle locations, and service alerts.

This project provides a simple synchronous client and data models to easily consume data from the API within your Rust code.

Built With

• ureq as the underlying HTTP client
• Serde and Serde JSON for data deserialization/serialization
• Chrono for handling datetime data

Why provide a synchronous client rather than an asynchronous one?

1. I didn't want this crate to be tied down to a specific async runtime
2. I wanted to use the ureq crate for its simple API and small size, and it only provides a synchronous client

Why not auto-generate a client, given that the OpenAPI/Swagger client code-generators exists?

1. I'm not very familiar with any of the code generation tools available
2. I'd personally prefer to have a handcrafted client with some sharper data definitions than one that is auto-generated
3. There aren't too many API endpoints as of now, so manual maintenance shouldn't be too much of an issue once kicked off
4. I like subjecting myself to unnecessary and Sisyphean tasks

Usage

It is highly recommended to have the API Swagger docs handy, as it generally contains more detailed and thorough documentation for model field than what is provided here.

In your Cargo.toml file:

[dependencies]
mbta-rs = "*"

# if you need to manipulate/further inspect certain fields
chrono = "*"
serde_json = "*"

Simple example usage:

use std::env;
use mbta_rs::Client;

let client = match env::var("MBTA_TOKEN") {
    Ok(token) => Client::with_key(token),
    Err(_) => Client::without_key()
};

let query_params = [
    ("page[limit]", "3")
];

let alerts_response = client.alerts(&query_params);
if let Ok(response) = alerts_response {
    for alert in response.data {
        println!("MBTA alert: {}", alert.attributes.header);
    }
}

Map Feature

This library comes with an optional module for plotting location-related data models (stops, vehicles, shapes, etc.) onto a simple tile map.

In your Cargo.toml file:

[dependencies]
mbta-rs = { version = "*", features = ["map"] }

# necessary to create the map itself
staticmap = "*"

Simple example usage:

use std::{collections::HashMap, env};
use staticmap::StaticMapBuilder;
use mbta_rs::{Client, map::{Plottable, PlotStyle}};

let client = match env::var("MBTA_TOKEN") {
    Ok(token) => Client::with_key(token),
    Err(_) => Client::without_key()
};

let routes = client.routes(&[("filter[type]", "0,1")]).expect("failed to get routes");
let mut map = StaticMapBuilder::new()
    .width(1000)
    .height(1000)
    .zoom(12)
    .lat_center(42.326768)
    .lon_center(-71.100099)
    .build()
    .expect("failed to build map");

for route in routes.data {
    let query_params = [("filter[route]", &route.id)];
    let shapes = client
        .shapes(&query_params)
        .expect("failed to get shapes");
    for shape in shapes.data {
        shape
            .plot(&mut map, true, PlotStyle::new((route.attributes.color.clone(), 3.0), Some(("#FFFFFF".into(), 1.0))))
            .expect("failed to plot shape");
    }
    let stops = client
        .stops(&query_params)
        .expect("failed to get stops");
    for stop in stops.data {
        stop.plot(
            &mut map,
            true,
            PlotStyle::new((route.attributes.color.clone(), 3.0), Some(("#FFFFFF".into(), 1.0))),
        )
        .expect("failed to plot stop");
    }
}

// save to file...

Contribute

See CONTRIBUTE.md to get started!

Other Acknowledgements

• Matt Vertescher's MBTA V3 API for already existing!
• Matt Boulanger's Mattermost API client for some of the client design inspiration
• Othneil Drew's Best README Template for templating the README and CONTRIBUTE layouts

mbta-rs's Issues

Optional feature: tile-map rendering of location data

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.

Better Request Error Results

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

Change `Plottable` trait's `plot` method to use `&self` instead of `self`

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

Loosen type for query parameters

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

Consider making `Client` `Send + Sync`

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