#2659 Add a JSON API
Opened 3 years ago by walters. Modified 3 years ago

See https://github.com/fedora-infra/bodhi/issues/4175 - which is part of a headlining feature in rpm-ostree v2021.1: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MQWBKRFCYH2GB3CW5CG722RGQAEPHHAN/

Basically I don't want to drag XML-RPC and really too much koji specifics in rpm-ostree; a more modern HTTP API where a URL returns JSON is much more preferable.


Direct link to the proxy service code that rpm-ostree is using today: https://github.com/cgwalters/koji-sane-json-api

It was a Koji 2.0 item to add a JSON-RPC API. Alas, apparently it wasn't wanted, so the plan for Koji 2.0 was scrapped.

+1

This would be nice. XML-RPC is ok, but it is showing its age.

But more than a modern Koji communication API, I'd like a stable API. Data types have changed from time to time and it's caused surprises. This happens in minor point releases. Improvements are fine, but a little more API stability would be appreciated. An API version would be useful too so if you need to make large breaking changes, you can just do that as a new API version.

Note, if you're going to screen-scrape the Koji CLI, please check out "koji call " with the "--json" flag, because that will be much more stable. We don't really guarantee that the human-readable CLI output won't break.

I have been looking at adding gRPC to Koji Hub, because we really need something that supports the benefits of RPC like rich error reporting we already have, and it would be great to get things like bi-directional streaming, etc. My goal is to preserve as much existing Koji API and surrounding ecosystem code as possible, so gRPC would require a minimal amount of Koji client porting.

Here are some of the things I've found so far:

  • Several Koji RPCs accept no arguments. While gRPC does have google.protobuf.Empty, it's not quite the same for a client implementation.

  • Some RPCs accept more than one type for a parameter, for example "getBuild" accepts a name (str) or an ID (int), and this is complicated to easily expose with gRPC while also preserving the existing Python library API. We'd probably need to wrap these cases with a higher-level API for each language.

  • Anonymous access is straightforward, and gRPC supports client x509 auth ("mTLS"), but GSSAPI authentication is not available in gRPC upstream (https://github.com/grpc/proposal/pull/101). We'd probably need to build our own (again! see the original krb Koji implementation) or else do GSSAPI outside gRPC (HTTP request?) and use a token for authenticating gRPC.

Please don't use gRPC. Protobufs are a pain to work with and I'd really rather not inflict that terribleness on everyone.

Login to comment on this ticket.

Metadata