As discussed in the community, we have three main possibilities for the Query API:

• Using the protobuf as the spec, and using something like grpc-gateway for the REST interface. This would however be inefficient for future endpoints, such as bulk retrieval of traces.
• Using OpenAPI to document the API, potentially having it auto-generate the handlers
• Using GraphQL, similar to OpenAPI in that it can handle most of the work for us, but is focused on queries

A decision has to be made having two things in mind:

• we might have consumers like Kiali, who'd benefit from a HTTP/2 or gRPC-like approach, for performance reasons
• browsers should also be able to talk to the API, such as the Jaeger UI or the OpenShift Developer Console

A comment from Yuri: the JSON data model for the REST API, if that's the path we'd take, could use OTLP instead of Jaeger's representation, given that there's a JSON spec for trace data.