First RESTful HTTP API (#399)
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* WIP: Restructured REST API to use hyper_router and separate services.
* WIP: Fixing rust for REST API
* WIP: Fixed up many bugs in trying to get router to compile.
* WIP: Got the beacon_node to compile with the REST changes
* Basic API works!
- Changed CLI flags from rest-api* to api*
- Fixed port cli flag
- Tested, works over HTTP
* WIP: Moved things around so that we can get state inside the handlers.
* WIP: Significant API updates.
- Started writing a macro for getting the handler functions.
- Added the BeaconChain into the type map, gives stateful access to the beacon state.
- Created new generic error types (haven't figured out yet), to reduce code duplication.
- Moved common stuff into lib.rs
* WIP: Factored macros, defined API result and error.
- did more logging when creating HTTP responses
- Tried moving stuff into macros, but can't get macros in macros to compile.
- Pulled out a lot of placeholder code.
* Fixed macros so that things compile.
* Cleaned up code.
- Removed unused imports
- Removed comments
- Addressed all compiler warnings.
- Ran cargo fmt.
* Removed auto-generated OpenAPI code.
* Addressed Paul's suggestions.
- Fixed spelling mistake
- Moved the simple macros into functions, since it doesn't make sense for them to be macros.
- Removed redundant code & inclusions.
* Removed redundant validate_request function.
* Included graceful shutdown in Hyper server.
* Fixing the dropped exit_signal, which prevented the API from starting.
* Wrapped the exit signal, to get an API shutdown log line.
2019-07-31 08:29:41 +00:00
|
|
|
[package]
|
2020-09-29 03:46:54 +00:00
|
|
|
name = "http_api"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
authors = ["Paul Hauner <paul@paulhauner.com>"]
|
First RESTful HTTP API (#399)
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* WIP: Restructured REST API to use hyper_router and separate services.
* WIP: Fixing rust for REST API
* WIP: Fixed up many bugs in trying to get router to compile.
* WIP: Got the beacon_node to compile with the REST changes
* Basic API works!
- Changed CLI flags from rest-api* to api*
- Fixed port cli flag
- Tested, works over HTTP
* WIP: Moved things around so that we can get state inside the handlers.
* WIP: Significant API updates.
- Started writing a macro for getting the handler functions.
- Added the BeaconChain into the type map, gives stateful access to the beacon state.
- Created new generic error types (haven't figured out yet), to reduce code duplication.
- Moved common stuff into lib.rs
* WIP: Factored macros, defined API result and error.
- did more logging when creating HTTP responses
- Tried moving stuff into macros, but can't get macros in macros to compile.
- Pulled out a lot of placeholder code.
* Fixed macros so that things compile.
* Cleaned up code.
- Removed unused imports
- Removed comments
- Addressed all compiler warnings.
- Ran cargo fmt.
* Removed auto-generated OpenAPI code.
* Addressed Paul's suggestions.
- Fixed spelling mistake
- Moved the simple macros into functions, since it doesn't make sense for them to be macros.
- Removed redundant code & inclusions.
* Removed redundant validate_request function.
* Included graceful shutdown in Hyper server.
* Fixing the dropped exit_signal, which prevented the API from starting.
* Wrapped the exit signal, to get an API shutdown log line.
2019-07-31 08:29:41 +00:00
|
|
|
edition = "2018"
|
2021-08-06 00:47:31 +00:00
|
|
|
autotests = false # using a single test binary compiles faster
|
First RESTful HTTP API (#399)
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* WIP: Restructured REST API to use hyper_router and separate services.
* WIP: Fixing rust for REST API
* WIP: Fixed up many bugs in trying to get router to compile.
* WIP: Got the beacon_node to compile with the REST changes
* Basic API works!
- Changed CLI flags from rest-api* to api*
- Fixed port cli flag
- Tested, works over HTTP
* WIP: Moved things around so that we can get state inside the handlers.
* WIP: Significant API updates.
- Started writing a macro for getting the handler functions.
- Added the BeaconChain into the type map, gives stateful access to the beacon state.
- Created new generic error types (haven't figured out yet), to reduce code duplication.
- Moved common stuff into lib.rs
* WIP: Factored macros, defined API result and error.
- did more logging when creating HTTP responses
- Tried moving stuff into macros, but can't get macros in macros to compile.
- Pulled out a lot of placeholder code.
* Fixed macros so that things compile.
* Cleaned up code.
- Removed unused imports
- Removed comments
- Addressed all compiler warnings.
- Ran cargo fmt.
* Removed auto-generated OpenAPI code.
* Addressed Paul's suggestions.
- Fixed spelling mistake
- Moved the simple macros into functions, since it doesn't make sense for them to be macros.
- Removed redundant code & inclusions.
* Removed redundant validate_request function.
* Included graceful shutdown in Hyper server.
* Fixing the dropped exit_signal, which prevented the API from starting.
* Wrapped the exit signal, to get an API shutdown log line.
2019-07-31 08:29:41 +00:00
|
|
|
|
|
|
|
|
[dependencies]
|
2021-10-12 03:35:49 +00:00
|
|
|
warp = { git = "https://github.com/macladson/warp", rev ="dfa259e", features = ["tls"] }
|
2020-10-05 08:22:19 +00:00
|
|
|
serde = { version = "1.0.116", features = ["derive"] }
|
2021-08-17 01:00:24 +00:00
|
|
|
tokio = { version = "1.10.0", features = ["macros","sync"] }
|
2021-03-01 01:58:05 +00:00
|
|
|
tokio-stream = { version = "0.1.3", features = ["sync"] }
|
2020-09-29 03:46:54 +00:00
|
|
|
types = { path = "../../consensus/types" }
|
|
|
|
|
hex = "0.4.2"
|
First RESTful HTTP API (#399)
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* Added generated code for REST API.
- Created a new crate rest_api, which will adapt the openapi generated code to Lighthouse
- Committed automatically generated code from openapi-generator-cli (via docker). Should hopfully not have to modify this at all, and do all changes in the rest_api crate.
* Removed openapi generated code, because it was the rust client, not the rust server.
* Added the correct rust-server code, automatically generated from openapi.
* Included REST API in configuratuion.
- Started adding the rest_api into the beacon node's dependencies.
- Set up configuration file for rest_api and integrated into main client config
- Added CLI flags for REST API.
* Futher work on REST API.
- Adding the dependencies to rest_api crate
- Created a skeleton BeaconNodeService, which will handle /node requests.
- Started the rest_api server definition, with the high level request handling logic.
* WIP: Restructured REST API to use hyper_router and separate services.
* WIP: Fixing rust for REST API
* WIP: Fixed up many bugs in trying to get router to compile.
* WIP: Got the beacon_node to compile with the REST changes
* Basic API works!
- Changed CLI flags from rest-api* to api*
- Fixed port cli flag
- Tested, works over HTTP
* WIP: Moved things around so that we can get state inside the handlers.
* WIP: Significant API updates.
- Started writing a macro for getting the handler functions.
- Added the BeaconChain into the type map, gives stateful access to the beacon state.
- Created new generic error types (haven't figured out yet), to reduce code duplication.
- Moved common stuff into lib.rs
* WIP: Factored macros, defined API result and error.
- did more logging when creating HTTP responses
- Tried moving stuff into macros, but can't get macros in macros to compile.
- Pulled out a lot of placeholder code.
* Fixed macros so that things compile.
* Cleaned up code.
- Removed unused imports
- Removed comments
- Addressed all compiler warnings.
- Ran cargo fmt.
* Removed auto-generated OpenAPI code.
* Addressed Paul's suggestions.
- Fixed spelling mistake
- Moved the simple macros into functions, since it doesn't make sense for them to be macros.
- Removed redundant code & inclusions.
* Removed redundant validate_request function.
* Included graceful shutdown in Hyper server.
* Fixing the dropped exit_signal, which prevented the API from starting.
* Wrapped the exit signal, to get an API shutdown log line.
2019-07-31 08:29:41 +00:00
|
|
|
beacon_chain = { path = "../beacon_chain" }
|
2020-09-29 03:46:54 +00:00
|
|
|
eth2 = { path = "../../common/eth2", features = ["lighthouse"] }
|
|
|
|
|
slog = "2.5.2"
|
2019-08-14 08:23:26 +00:00
|
|
|
network = { path = "../network" }
|
2020-06-19 04:13:23 +00:00
|
|
|
eth2_libp2p = { path = "../eth2_libp2p" }
|
2020-09-29 03:46:54 +00:00
|
|
|
eth1 = { path = "../eth1" }
|
2020-05-18 11:24:23 +00:00
|
|
|
state_processing = { path = "../../consensus/state_processing" }
|
2020-09-29 03:46:54 +00:00
|
|
|
lighthouse_version = { path = "../../common/lighthouse_version" }
|
2020-05-18 11:24:23 +00:00
|
|
|
lighthouse_metrics = { path = "../../common/lighthouse_metrics" }
|
2020-09-29 03:46:54 +00:00
|
|
|
lazy_static = "1.4.0"
|
|
|
|
|
warp_utils = { path = "../../common/warp_utils" }
|
2020-05-18 11:24:23 +00:00
|
|
|
slot_clock = { path = "../../common/slot_clock" }
|
Implement SSZ union type (#2579)
## Issue Addressed
NA
## Proposed Changes
Implements the "union" type from the SSZ spec for `ssz`, `ssz_derive`, `tree_hash` and `tree_hash_derive` so it may be derived for `enums`:
https://github.com/ethereum/consensus-specs/blob/v1.1.0-beta.3/ssz/simple-serialize.md#union
The union type is required for the merge, since the `Transaction` type is defined as a single-variant union `Union[OpaqueTransaction]`.
### Crate Updates
This PR will (hopefully) cause CI to publish new versions for the following crates:
- `eth2_ssz_derive`: `0.2.1` -> `0.3.0`
- `eth2_ssz`: `0.3.0` -> `0.4.0`
- `eth2_ssz_types`: `0.2.0` -> `0.2.1`
- `tree_hash`: `0.3.0` -> `0.4.0`
- `tree_hash_derive`: `0.3.0` -> `0.4.0`
These these crates depend on each other, I've had to add a workspace-level `[patch]` for these crates. A follow-up PR will need to remove this patch, ones the new versions are published.
### Union Behaviors
We already had SSZ `Encode` and `TreeHash` derive for enums, however it just did a "transparent" pass-through of the inner value. Since the "union" decoding from the spec is in conflict with the transparent method, I've required that all `enum` have exactly one of the following enum-level attributes:
#### SSZ
- `#[ssz(enum_behaviour = "union")]`
- matches the spec used for the merge
- `#[ssz(enum_behaviour = "transparent")]`
- maintains existing functionality
- not supported for `Decode` (never was)
#### TreeHash
- `#[tree_hash(enum_behaviour = "union")]`
- matches the spec used for the merge
- `#[tree_hash(enum_behaviour = "transparent")]`
- maintains existing functionality
This means that we can maintain the existing transparent behaviour, but all existing users will get a compile-time error until they explicitly opt-in to being transparent.
### Legacy Option Encoding
Before this PR, we already had a union-esque encoding for `Option<T>`. However, this was with the *old* SSZ spec where the union selector was 4 bytes. During merge specification, the spec was changed to use 1 byte for the selector.
Whilst the 4-byte `Option` encoding was never used in the spec, we used it in our database. Writing a migrate script for all occurrences of `Option` in the database would be painful, especially since it's used in the `CommitteeCache`. To avoid the migrate script, I added a serde-esque `#[ssz(with = "module")]` field-level attribute to `ssz_derive` so that we can opt into the 4-byte encoding on a field-by-field basis.
The `ssz::legacy::four_byte_impl!` macro allows a one-liner to define the module required for the `#[ssz(with = "module")]` for some `Option<T> where T: Encode + Decode`.
Notably, **I have removed `Encode` and `Decode` impls for `Option`**. I've done this to force a break on downstream users. Like I mentioned, `Option` isn't used in the spec so I don't think it'll be *that* annoying. I think it's nicer than quietly having two different union implementations or quietly breaking the existing `Option` impl.
### Crate Publish Ordering
I've modified the order in which CI publishes crates to ensure that we don't publish a crate without ensuring we already published a crate that it depends upon.
## TODO
- [ ] Queue a follow-up `[patch]`-removing PR.
2021-09-25 05:58:36 +00:00
|
|
|
eth2_ssz = "0.4.0"
|
2020-12-07 08:20:33 +00:00
|
|
|
bs58 = "0.4.0"
|
2020-12-04 00:18:58 +00:00
|
|
|
futures = "0.3.8"
|
2019-09-10 00:54:37 +00:00
|
|
|
|
2019-11-25 04:48:24 +00:00
|
|
|
[dev-dependencies]
|
2020-09-29 03:46:54 +00:00
|
|
|
store = { path = "../store" }
|
|
|
|
|
environment = { path = "../../lighthouse/environment" }
|
Implement SSZ union type (#2579)
## Issue Addressed
NA
## Proposed Changes
Implements the "union" type from the SSZ spec for `ssz`, `ssz_derive`, `tree_hash` and `tree_hash_derive` so it may be derived for `enums`:
https://github.com/ethereum/consensus-specs/blob/v1.1.0-beta.3/ssz/simple-serialize.md#union
The union type is required for the merge, since the `Transaction` type is defined as a single-variant union `Union[OpaqueTransaction]`.
### Crate Updates
This PR will (hopefully) cause CI to publish new versions for the following crates:
- `eth2_ssz_derive`: `0.2.1` -> `0.3.0`
- `eth2_ssz`: `0.3.0` -> `0.4.0`
- `eth2_ssz_types`: `0.2.0` -> `0.2.1`
- `tree_hash`: `0.3.0` -> `0.4.0`
- `tree_hash_derive`: `0.3.0` -> `0.4.0`
These these crates depend on each other, I've had to add a workspace-level `[patch]` for these crates. A follow-up PR will need to remove this patch, ones the new versions are published.
### Union Behaviors
We already had SSZ `Encode` and `TreeHash` derive for enums, however it just did a "transparent" pass-through of the inner value. Since the "union" decoding from the spec is in conflict with the transparent method, I've required that all `enum` have exactly one of the following enum-level attributes:
#### SSZ
- `#[ssz(enum_behaviour = "union")]`
- matches the spec used for the merge
- `#[ssz(enum_behaviour = "transparent")]`
- maintains existing functionality
- not supported for `Decode` (never was)
#### TreeHash
- `#[tree_hash(enum_behaviour = "union")]`
- matches the spec used for the merge
- `#[tree_hash(enum_behaviour = "transparent")]`
- maintains existing functionality
This means that we can maintain the existing transparent behaviour, but all existing users will get a compile-time error until they explicitly opt-in to being transparent.
### Legacy Option Encoding
Before this PR, we already had a union-esque encoding for `Option<T>`. However, this was with the *old* SSZ spec where the union selector was 4 bytes. During merge specification, the spec was changed to use 1 byte for the selector.
Whilst the 4-byte `Option` encoding was never used in the spec, we used it in our database. Writing a migrate script for all occurrences of `Option` in the database would be painful, especially since it's used in the `CommitteeCache`. To avoid the migrate script, I added a serde-esque `#[ssz(with = "module")]` field-level attribute to `ssz_derive` so that we can opt into the 4-byte encoding on a field-by-field basis.
The `ssz::legacy::four_byte_impl!` macro allows a one-liner to define the module required for the `#[ssz(with = "module")]` for some `Option<T> where T: Encode + Decode`.
Notably, **I have removed `Encode` and `Decode` impls for `Option`**. I've done this to force a break on downstream users. Like I mentioned, `Option` isn't used in the spec so I don't think it'll be *that* annoying. I think it's nicer than quietly having two different union implementations or quietly breaking the existing `Option` impl.
### Crate Publish Ordering
I've modified the order in which CI publishes crates to ensure that we don't publish a crate without ensuring we already published a crate that it depends upon.
## TODO
- [ ] Queue a follow-up `[patch]`-removing PR.
2021-09-25 05:58:36 +00:00
|
|
|
tree_hash = "0.4.0"
|
2021-05-04 01:59:51 +00:00
|
|
|
sensitive_url = { path = "../../common/sensitive_url" }
|
2021-08-06 00:47:31 +00:00
|
|
|
|
|
|
|
|
[[test]]
|
|
|
|
|
name = "bn_http_api_tests"
|
|
|
|
|
path = "tests/main.rs"
|
