flow-go
flow-go copied to clipboard
onflow
Add REST Support for Flow API
Problem Definition
Related to issue #2485. This epic pertains to the Flow API Service, a part of the wider Flow Access Node Refactoring. The current Flow API is a gRPC implementation, based on the legacy Access API. It now needs support for REST APIs so that the Flow API Service can serve web services.
Proposed Solution
The Flow API adds REST API support and can serve web clients (JSON, XML, etc.).
Definition of Done
• Expose external Flow APIs (REST) based on the legacy Access API's REST implementation • Flow API responds to web/HTTP requests • Flow API serves web clients • Handles blocks, transactions, collections, execution, accounts, scripts, and events in a similar way to Access API
Regarding Flow API Service for REST: It seems that is is quite extensive what we do to translate REST calls to gRPC backend (queryselectable, queryexpandable). Do we want to blindly forward requests from the Flow API Service over REST to BDS/DPS, or do we want to translate them in place before passing it through? Should we do an HTTP 3xx redirect only?
I need to revisit this issue. The current design of flow API service will use gRPC as the primary protocol.
There are two ways to support REST on top of this.
- We can translate calls in the API service cloning the current logic of the access node or
- We can do a 301 Moved Permanently redirection to a node supporting the respective REST API of an Upstream Access node.
The first option seems to be the straightforward choice, but it was planned for the Access API and not for the Protocol API.
The next question:
- Do we define a REST API for the Protocol API?
- Do we use the current Access REST protocol and forward it to the gRPC Access API of the API service in place?
We still need to provide an Access API as well in case of the second option, and it also implies the choice of option one in the first question (translation in place, no 301 forwarding)
