result field could be a JSON schema instead of custom contentDescriptorObject

[rmedaer]

As far as I read JSON RPC 2.0, 5. Response Object there is no rule or restriction for the result object. Indeed we can either put an integer, an object or any valid JSON (including null).

See in examples:

<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

Currently in OpenRPC spec, we are waiting for a Content Descriptor Object. It doesn't define which kind of content it returns as Response result.

My proposal is quiet the same then issue #226: use a JSON Schema instead of Content Descriptor Object. Despite params field which only accept an object, an array or null, we can here put any valid JSON Schema.

Example:

{
  (...)
  "methods": [
    {
      "name": "addition",
      (...)
      "result": {
        "type": "integer"
      }
    }
  ]
}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BelfordZ]

@rmedaer Haven't forgot about this. Been thinking about ditching content descriptor for just plain json schema for both param and result.

Scope of change would be quite large, but the more I think about it the more it makes sense.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[shanejonas]

the separation we have with ContentDescriptors is better for code generation, and lines up with OpenAPI that we forked, having name, summary, description, schema, deprecated.

if we had just JSON Schemas for params, we'd have to have separate specs for by-name vs by-position for each parameter type with a oneOf.

params cant just be forced as only objects: type: "object", properties: { bar: { type: "string" }. As an array param the connonical json schema would be type: "array", items, and the ordering of JSON keys cant be preserved with JSON.parse.

[zcstarr]

Since this was mentioned, I'll talk about this in the context of result. With result it's much simpler, but I think there's still a lot of value add in having an explicit usage of a content descriptor ( name decoupled from type and no guesswork there). It will help with downstream consumers of the spec ( annotations code generation) , as well as make it easier for lib builders to handle one specific case contentDescriptors imho.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.