Influxdata
/
influxdb
mirror of https://github.com/influxdata/influxdb.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
influxdb/influxdb_iox_client/Cargo.toml

19 lines
532 B
TOML
Raw Normal View History

feat: create IOx API client Initialises a new library crate and implements a basic IOx API client. The API client supports: - ping - create database Care has been taken to abstract away the underlying HTTP client used (reqwest) and avoid leaking it into the public API (error types is a common leak!) This makes updating the HTTP client and/or swapping it for something else a backwards compatible change for end users of the crate. Outstanding items: - move shared API types into a sensible location - discriminate between various IOx error responses The former doesn't need doing until we publish the crate and will likely be rather invasive / conlict prone so aiming to merge this PR and then move things around in a follow-up. The latter would allow us to expose error conditions to the user such that they can take actions to remidy the situation / know if the request can or should be retried / etc. Currently we expose a string error message when requests fail, requiring string matching and/or passing the string higher in the stack (and thus punting the problem to the caller). It would be very nice to have typed errors, but a detail I have left for later.
2021-01-08 16:21:26 +00:00
[package]
name = "influxdb_iox_client"
version = "0.1.0"
authors = ["Dom Dwyer <dom@itsallbroken.com>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
data_types = { path = "../data_types" }
reqwest = { version = "0.10.10", features = ["gzip", "json"] } # Latest release using tokio 0.2
serde = "1.0.118"
refactor: error handling & typed errors Refactors the API method errors. The user of the API client needs to be able to distinguish between various error states when an API request fails. The most ergonomic way of exposing this information is by returning an error enum that is specific to each API method (or at least the important ones with well defined failure modes) - currently only the `create_database()` method has significant error states, so this is the only one with a specific error type in this impl. This change defines a bunch of API error codes in the API client, adds them to the IOx API error response body, and maps them in the API client. Due to error wrapping the error code mapping in the IOx server is less exhaustive than I had hoped however.
2021-01-13 17:30:46 +00:00
serde_json = "1.0.61"
thiserror = "1.0.23"
feat: create IOx API client Initialises a new library crate and implements a basic IOx API client. The API client supports: - ping - create database Care has been taken to abstract away the underlying HTTP client used (reqwest) and avoid leaking it into the public API (error types is a common leak!) This makes updating the HTTP client and/or swapping it for something else a backwards compatible change for end users of the crate. Outstanding items: - move shared API types into a sensible location - discriminate between various IOx error responses The former doesn't need doing until we publish the crate and will likely be rather invasive / conlict prone so aiming to merge this PR and then move things around in a follow-up. The latter would allow us to expose error conditions to the user such that they can take actions to remidy the situation / know if the request can or should be retried / etc. Currently we expose a string error message when requests fail, requiring string matching and/or passing the string higher in the stack (and thus punting the problem to the caller). It would be very nice to have typed errors, but a detail I have left for later.
2021-01-08 16:21:26 +00:00
tokio = { version = "0.2", features = ["net", "tcp", "macros"] }
[dev-dependencies]
rand = "0.8.1"