RPC Discover endpoint with basic informations

[Leinnan]

Objective

It does not resolves issue for full support for OpenRPC for bevy_remote, but it is a first step in that direction. Connected to the #16744 issue.

Solution

• Adds rpc.discover endpoint to the bevy_remote which follows https://spec.open-rpc.org/#openrpc-document For now in methods array only the name, which is the endpoint address is populated.
• Moves json_schema structs into new module inside bevy_remote.

Testing

Tested the commands by running the BRP sample( cargo run --example server --features="bevy_remote") and with these curl command:

curl -X POST -d '{ "jsonrpc": "2.0", "id": 1, "method": "rpc.discover"}' 127.0.0.1:15702 | jq .

The output is:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "info": {
      "title": "Bevy Remote Protocol",
      "version": "0.16.0-dev"
    },
    "methods": [
      {
        "name": "bevy/mutate_component",
        "params": []
      },
      {
        "name": "bevy/insert",
        "params": []
      },
      {
        "name": "bevy/get",
        "params": []
      },
      {
        "name": "bevy/spawn",
        "params": []
      },
      {
        "name": "bevy/get+watch",
        "params": []
      },
      {
        "name": "bevy/destroy",
        "params": []
      },
      {
        "name": "bevy/list",
        "params": []
      },
      {
        "name": "bevy/mutate_resource",
        "params": []
      },
      {
        "name": "bevy/reparent",
        "params": []
      },
      {
        "name": "bevy/registry/schema",
        "params": []
      },
      {
        "name": "bevy/get_resource",
        "params": []
      },
      {
        "name": "bevy/query",
        "params": []
      },
      {
        "name": "bevy/remove_resource",
        "params": []
      },
      {
        "name": "rpc.discover",
        "params": []
      },
      {
        "name": "bevy/insert_resource",
        "params": []
      },
      {
        "name": "bevy/list_resources",
        "params": []
      },
      {
        "name": "bevy/remove",
        "params": []
      },
      {
        "name": "bevy/list+watch",
        "params": []
      }
    ],
    "openrpc": "1.3.2",
    "servers": [
      {
        "name": "Server",
        "url": "127.0.0.1:15702"
      }
    ]
  }
}

[Leinnan]

Could be interested in this: @mweatherley and @purplg

[mweatherley]

This is a very minor nit, but I guess it bothers me slightly that this isn't transparent to the transport used for BRP; I think ideally in the future (e.g. when we eventually include more detailed method information in the OpenRPC document) we'd have the server info be separately registered by the transport plugin in some kind of resource in the internals.

Just a thought!

[Leinnan]

Agreed, I just wasn’t confident enough in any solution to include it.

[Leinnan]

@alice-i-cecile Something missing or is it ready for merge?

[alice-i-cecile]

This needs a second review: I would, but I've never worked with this flavor of thing before.

[villor]

Overall happy with this kind of functionality! 🥳 Helps both with discoverability and things like generating API clients.

Curious about the use of 1.0.0-rc1 spec instead of the latest spec.

The information included for the methods is pretty sparse currently. It would be nice (maybe in a follow up) to extend it with more stuff, possibly by extending RemoteMethods to hold more metadata like:

• Summary
• Description
• etc

[villor]

Any particular reason these were left out?
params is required in OpenRPC 1.3.2.
resultis required in OpenRPC 1.0.0-rc1.

Maybe these could be included as $refs using some of the json_schema code? 🤔

[Leinnan]

Unfortunately it wasn't that easy: #16744 (comment)

[villor]

Right, yeah it's a bit tricky that the methods are serde-based rather than bevy_reflect, but it also makes sense for usecases with non-reflectable data 🤔

There is https://github.com/GREsau/schemars which can generate JSON schemas for serde types. Not sure if we'd want to bring in another dep though.

I say include a (possibly empty) params either way though, just to be spec-compliant. There might be clients that rely on it being present.

[villor]

Another route could be to add manual schemas for the BRP types, which we already kind of do in module docs: https://dev-docs.bevyengine.org/src/bevy_remote/lib.rs.html#99

Ideally those would not be duplicated though, so if there was a way to write them in one place and have them available both through OpenRPC and in bevy docs that would be nice.

[Leinnan]

Argument about including params makes sense, done :)

[Leinnan]

To have a full RPC Discover support the stuff you've described would be great. For the basic one I am aiming on atm what this PR provides is enough IMHO. But I would love to see it with proper params support.

[villor]

That's fair, this is a great start! Approving now 😄

[alice-i-cecile]

@Leinnan ping me when this is passing CI and I'll get this merged for you.

[Leinnan]

@alice-i-cecile ping ;)