Crates.io | fts-server |
lib.rs | fts-server |
version | |
source | src |
created_at | 2025-03-21 17:56:30.90802+00 |
updated_at | 2025-04-21 15:35:59.31829+00 |
description | A RESTful flow trading API server |
homepage | |
repository | |
max_upload_size | |
id | 1600922 |
Cargo.toml error: | TOML parse error at line 23, column 1 | 23 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
This crate is part of a collection of crates that together implement flow trading as proposed by Budish, Cramton, et al, in which trade occurs continuously over time via regularly-scheduled batch auctions.
The different crates in this workspace are as follows:
This crate provides a REST API for the core flow trading operations. Building
the sibling crate fts-demo
will generate an OpenAPI schema. A running server will host this schema at http://localhost:8080/rapidoc.
It is true that JSON is a significantly flawed choice for (de)serialization of bid data. It is also true that a RESTful API over HTTP is questionable, at best, with respect to building a trading platform. On the other hand, these choices allow for virtually any programming environment to easily interface with the server, as well as open the door to rich, web-based clients.
Given that this project is primarily intended to motivate the use of flow trading, especially in the context of forward markets, these trade-offs are more than reasonable. With that said, the design of flow trading specifically discourages high-frequency execution, so the performance overhead of these trade-offs are also largely irrelevant.
In the interest of simplicity, endpoints that process bid data (or execute administrative actions) expect HTTP requests to contain the Authorization
header with a JWT bearer token. The sub:
claim of this token must be the bidder's UUID. To authorize an administrative action, this token must contain the custom claim admin: true
. It is left to the operator to securely authenticate and generate these tokens.
Please refer to the automatically generated OpenAPI schema for up-to-date documentation of the endpoints. Note that any endpoint expecting a datetime type expects an RFC3339-compliant string.