lta-rs
🚍 Singapore LTA Datamall Rust Client written in pure rust with support for asynchronous requests. lta-rs is used to interact with the lta-datamall
lta-rs in action
Cargo.toml setup
[]
= "0.3.0-async-preview-5"
API key setup
You can get your API key from here
extern crate lta;
use *;
Examples
Getting bus timings
use *;
use LTAClient;
use get_arrival;
use Result;
Getting anything else
// All the APIs in this library are designed to be used like this
// `module::get_something`
// All of them return lta::utils::Result<Vec<T>>
// The example below is bus::get_bus_services()
// and traffic::get_erp_rates()
// Do note that the API calling convention is similar across all the APIs except for
// bus::get_arrival
// prefer lta::prelude::* over glob imports
use *;
use LTAClient;
use get_erp_rates;
use get_bus_services;
use Result;
Async Example
use r#;
use var;
use run;
Custom Client
There are some instance where you might need to customise the client more due to certain limitations.
use Duration;
use ClientBuilder;
use LTAClient;
use Client;
Concurrent requests without Futures
use Arc;
use spawn;
use LTAClient;
use Client;
General advice
- Reuse
LTAClient
as it holds a connection pool internally - Reduce the number of times you call the API, take a look at the
Update Freq
in the documentation andprevent yourself from getting blacklisted. Use a caching mechanism. - Prefer
async
APIs over writing your own implementation for concurrent requests.
Getting help
- You can get help via github issues. I will try my best to respond to your queries :smile:
Design decisions
- Made sure that Rust structs are as close to the original response as possible to make sure that people can reference the original docs if there are any issues
- Simple and no additional baggage. Only the client is included. E.g If anyone wants to add concurrency, they have to do it on their own
- Predictable API usage
Changelog
Changelog can be found here
Requirements
On Linux:
- OpenSSL 1.0.1, 1.0.2, or 1.1.0 with headers (see https://github.com/sfackler/rust-openssl)
On Windows and macOS:
- Nothing.
lta-rs uses rust-native-tls internally, which will use the operating system TLS framework if available, meaning Windows and macOS. On Linux, it will use OpenSSL 1.1.
Todo (excluding bugs from issues)
- Proper date types using chrono library
- Utils cleanup
- Host on crates.io
- Static website to showcase project
- Documentation
- More idiomatic Rust code
- Asynchronous requests
- Travis CI
- Documentation for async
-
std::future
- Customisable
Client
- Better testing, reduce API spam and cache data for testing
- Deserialization benchmark
License
lta-rs is licensed under MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
Frequently Asked Questions
Is this library being actively developed?
Yes. However, development will slow down from mid August 2019 onwards due to my NS commitments.
What are the APIs available?
Take a look at the offical LTA docs.
Where do I get the official docs from lta?
You can get them here
Why are some of the data types different from the lta documentation?
Some of the data types returned are not ideal such as returning lat
and lang
as string
rather than number
. Some of the types are also converted to enums to reduce the number of stringly typed stuff
My application panicked.
Check if your API key is valid, if it is and your application still panics because of this library, create a github issue
Why is the most fully featured LTA client library implemented in a language not many people use?
Friendship ended with Kotlin. Now Rust is my best friend ❤️.
Is this project affiliated to LTA or any government body?
No.
What is the plan to move to
std::future
?
Currently waiting for dependencies to move to std::future
. However, this might take some time and different libraries might
update at different times, so I am currently experimenting on making the APIs exposed to users use std::future
while the internal implementation
depends on the compat
layer provided by futures-preview
.
All the async stuff is currently on preview and will be released for 0.3.0
. I do not want to rush the implementation of async APIs to
ensure that the ergonomics of them are user friendly. Considering that a lot of libraries are currently moving to std::future
,
this can be very confusing to beginners that want to take a look into futures.
Development of this happens on master
branch.