Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

API Call #143

Closed
djrtwo opened this issue Apr 14, 2020 · 5 comments
Closed

API Call #143

djrtwo opened this issue Apr 14, 2020 · 5 comments

Comments

@djrtwo
Copy link
Collaborator

djrtwo commented Apr 14, 2020

As discussed on the previous eth2 call, we intended to do an API call this Wednesday to chat about API formats, beacon-node APIs, and cross-format tooling and CI.

@protolambda and I are also putting together a comprehensive look at existing APIs as well as some notes on both general and more specific requirements.

I propose we push this call to Monday to provide more time for input and discussion as well as digesting the additional resources we plan to publish tomorrow.

I also solicit more active engagement from at least one member of each client team.

Agenda

  • format eth2.0-apis/issues/24
    • OpenAPI / JSON -- general agreement (?)
      • int vs str-int
      • bytes (0x vs base64)
    • optional SSZ where easy/sensible
    • optional protobuf refs (?)
    • versioning
  • api conversions/CI eth2.0-apis/issues/26
    • any updates
  • bn apis eth2.0-apis/issues/25
    • HOW to make this RESTful while avoiding excessive verbosity
      • Identifiers in the context of our types (vs. query params)
        • /beacon/{id}/resource <- very nice construct, but would require some amount duck-typing
        • /validator, /state_roots, /block_roots, /balances all fit in nicely here
      • Define additional types (that don't map to basic SSZ types, e.g. /forkchoice/ffg, /network/host (or sub-components))
    • standardize useful computations and return types that clearly diverge from REST but are useful while not being burdensome on the eth2-client (e.g. /beacon/forkchoice/individual_votes)

Call Monday @ 2pm UTC

@djrtwo
Copy link
Collaborator Author

djrtwo commented Apr 14, 2020

Tentative meeting time, Monday April 20th at 1:30pm UTC. Will confirm in ~2 days as these conversations progress

(edit: oh shit, it's 420 🎄)

@alonmuroch
Copy link

Any specific topics you thought of? to maybe send some questions before hand?

@tzapu
Copy link

tzapu commented Apr 20, 2020

while not strictly API related, it would be useful to standardise the version string sent through the API. It would be most useful for 3rd party tools in the future
something like Client/v0.0.0/githash/os/other/stuff might be good... of course, the hash could be a part of semver as well...

@mratsim
Copy link

mratsim commented Apr 20, 2020

@protolambda
Copy link

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants