-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First RESTful HTTP API #399
Conversation
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Changed CLI flags from rest-api* to api* - Fixed port cli flag - Tested, works over HTTP
- 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
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey man, looks good! Just a few minor comments.
Keen to get this merged!
- Fixed spelling mistake - Moved the simple macros into functions, since it doesn't make sense for them to be macros. - Removed redundant code & inclusions.
Actually, there is something happening that prevents |
My preference is to ditch the graceful shutdown for now and create an issue so we can pick it up later. I need to do some updates to our metrics and I'd like to start doing them using this HTTP server. |
So I have tried to resolve this shutdown issue, but without much avail. I have created issue #478 to cover this. |
Background Info
As discussed in ethereum/consensus-specs#1011 and ethereum/consensus-specs#1012, and formalised in PR ethereum/consensus-specs#1069, we are changing the gRPC interface between the validator client and beacon node to be a simple HTTP REST interface.
This PR brings the first iteration of the RESTful API to Lighthouse
Proposed Changes
This PR includes a new crate called
rest_api
, which implements all of the API functionality.It also introduces three new flags, which can be used to enable the API:
--api --api-address 127.0.0.1 --api-port 12345
This is the first iteration of the API, but only includes some simple endpoints to demonstrate the fundamental REST server and integration with stateful information in Lighthouse. the full API implementation is pending.