Add JSON Schemas for Bitcoin Kernel Bindings Test Handler Protocol

[janb84]

Added 2 schemas that represent the request and responses json following the test handler spec 0.0.3.

These json schema's can be used to validation and test the downstream solutions.

[stringintech]

Concept ACK. Thank you for working on this!

I took a brief look to compare pure JSON Schema versus OpenRPC for our use case (per #7 (comment)). It looks like using pure JSON Schema provides mature tooling for type generation across different languages for our handler implementations, as well as good documentation generation capabilities.

OpenRPC seems to facilitate more than just type generation - like server-side code generation (in our case, servers being handlers) that generates more boilerplate for request handling. However, existing tooling and generation support appears to be less mature and to be limited to a few languages.

Perhaps @stickies-v can correct me if I'm overlooking any clear benefit OpenRPC would provide over a pure JSON Schema approach in this context.

[stickies-v]

Perhaps @stickies-v can correct me if I'm overlooking any clear benefit OpenRPC would provide over a pure JSON Schema approach in this context.

No strong opinion. I'm not really familiar with the json schema or openrpc ecosystems, it just looked like we're pretty close to json schema compatibility already so i thought it'd be worthwhile keeping an eye out for that so users can more easily use existing tooling.

Also I think if any support for json schema or openrpc (or anything else) is added, internal adherence should be enforced through tests. If that's too much work / not feasible right now, we shouldn't commit to the schema either - at most just a mention that we're aiming for it.

(edit: royal "we", i'm just sharing thoughts, not really doing the work)

[janb84]

Concept ACK. Thank you for working on this!

I took a brief look to compare pure JSON Schema versus OpenRPC for our use case (per #7 (comment)). It looks like using pure JSON Schema provides mature tooling for type generation across different languages for our handler implementations, as well as good documentation generation capabilities.

OpenRPC seems to facilitate more than just type generation - like server-side code generation (in our case, servers being handlers) that generates more boilerplate for request handling. However, existing tooling and generation support appears to be less mature and to be limited to a few languages.

Perhaps @stickies-v can correct me if I'm overlooking any clear benefit OpenRPC would provide over a pure JSON Schema approach in this context.

I'm also willing to look into openRPC, haven't done that before but it can be more suitable for this new situation (the dynamic json-rpc ). Will look into it.

Also I think if any support for json schema or openrpc (or anything else) is added, internal adherence should be enforced through tests. If that's too much work / not feasible right now, we shouldn't commit to the schema either - at most just a mention that we're aiming for it.

Agree on the enforcement by tests. Let me tinker a bit more to see if what is possible.

[stringintech]

As a prerequisite to adding tests to validate the json files against schema definitions and following the discussion here, I think it makes sense I refactor the existing json files such that each test case has the following format:

{
  "request": {
    "id": "",
    "method": "",
    "params": {}
  },
  "expected_response": {
    "result": ""
  }
}

Instead of the current format (where request and response are composed by the go runner):

{
  "id": "",
  "method": "",
  "params": {},
  "expected": {
    "result": ""
  }
}

[stringintech]

refactor the existing json files such that ...

Addressed in #12.