Word convention for JSON

[cv21]

Sometimes it matters which word convention do you use.

For example, in some projects it is a rule to use only snake_case in json properties.

Now we do not have any options for the problem. I suggest to add some flag for word convention.

[smyrman]

What are you planning on controlling with such a flag? You can already control which fields to use by using struct tags or naming your input variables to service functions.

As for the fields in the JSON RPC response itself, the names has to follow the JSON RPC spec.

[cv21]

@smyrman , the JSONRPC spec does not specify json word convention.

lowerCamelCase variant:

--> {"jsonrpc": "2.0", "method": "someMethod", "params": {"someParam": 23, "someOtherParam": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}

snake_case variant:

--> {"jsonrpc": "2.0", "method": "some_method", "params": {"some_param": 23, "some_other_param": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}

The both are possible by the spec. The both are usable. But only one works now.

[smyrman]

Sorry for being unclear, I was referring to the reserved words (jsonrpc, method, params, result, error). But I guess all of these (except jsonrpc) are single words.

But to achive what you want, you should be able to do the following?

func (srv *Service) Some_method(some_param, some_other_param int) (*int, *zenrpc.Error) {
}

Not saying this is nice in Go, but you could solve that by letting the service method become a thin wrapper for your actual (private) method with propper naming.

And for nested data-structures, rely on json-tags.

[cv21]

Thank you so much for such tricks, @smyrman.

As you mention, it is technically possible to solve the problem using current state of zenrpc, but I believe we can improve zenrpc and make it more convenient and less tricky.

[vetcher]

This feature is available in my old pr and can be easily copied to some fork.