RejectedSoftware Forums

Sign up

Case conventions for parameters and response

Currently there is MethodStyle to set the case conventions for the REST interface. This is working fine for the methods. But I expected it to work for the parameters and the response as well. With the response I mean the field in a struct that is returned.

Example:

interface Api
{
    int fooBar(int fooBar);
}

When the method style is set to lowerUnderscored the above route is accessible as foo_bar. But the parameter needs to be fooBar. I would have expected the parameter to follow the same case conventions, i.e. foo_bar.

Same issue with the response:

struct Response
{
    int fooBar;
}

interface Api
{
    Response fooBar(int fooBar);
}

The JSON response for the above would look something like { "fooBar": 0 }. But I would expect it to follow the case conventions as in: { "foo_bar": 0 }.

I have not tried the behavior of the deserialization in a request, but I'm suspecting it has the same behavior.

Should the parameters and request/response follow the style set by MethodStyle or should those be separate settings?

/Jacob Carlborg

Re: Case conventions for parameters and response

Am 24.02.2016 um 11:14 schrieb Jacob Carlborg:

Currently there is MethodStyle to set the case conventions for the REST interface. This is working fine for the methods. But I expected it to work for the parameters and the response as well. With the response I mean the field in a struct that is returned.

Example:

interface Api
{
     int fooBar(int fooBar);
}

When the method style is set to lowerUnderscored the above route is accessible as foo_bar. But the parameter needs to be fooBar. I would have expected the parameter to follow the same case conventions, i.e. foo_bar.

Same issue with the response:

struct Response
{
     int fooBar;
}

interface Api
{
     Response fooBar(int fooBar);
}

The JSON response for the above would look something like { "fooBar": 0 }. But I would expect it to follow the case conventions as in: { "foo_bar": 0 }.

I have not tried the behavior of the deserialization in a request, but I'm suspecting it has the same behavior.

Should the parameters and request/response follow the style set by MethodStyle or should those be separate settings?

/Jacob Carlborg

I think it should be a separate setting because the calling convention
between functions, parameters and fields can be different on either of
the two sides.

A second setting for parameters would be easy to add, except that the
adjustMethodStyle function would have to be extended to recognize the
lower_underscore notation as the source style (at least that's the style
endorsed by the vibe.d style guide).

Just the field names would be more difficult, because the serialization
framework would need to get some support for name rewrites. But for
fields there is also the possibility to use @name("CustomName").