Allow more granularity in paramater naming convention configuration

[araki-nobuteru]

Hi folks!

I'd like to have the possibility to configure the paramater naming convention in a more granular way.
The tool currently validates all types of parameters (path, query string, body, form) using the same name convention. The ideia is to allow an individual configuration for each type of parameter.
Something like the snippet below in options.json file:

"parameterNamingConvention": {
    "path": "HypenCase",
    "query": "CamelCase",
    "body":  "AnyCase"
}

If the user doesn't specify the naming convention for some parameter type, the would consider a default convention.

Does this idea make sense?

Thank you!

[JFCote]

Hi @araki-nobuteru!

This is currently how it works, but maybe the naming of the parameter is a little bit different than what you were expecting. If you check the readme, you will see this in the documentation:

As you can see, you can specify the type of naming convention for the path, parameter, header, and properties.

I'm not sure why we chose parameters instead of query to be honest, must be because of some naming in the swagger-parser. As for the body, we don't validate it directly, we check each property (field).

Therefore, I think you have everything you need. Give it a try and let us know if everything is working as expected.
Thanks!

[araki-nobuteru]

Hi @JFCote!

I think I didn't make myself clear when describing the problem. Here are more details with an example.

In the project I working we have to follow a naming convention that specifies the following:

• Paths: hyphen-case
• Path parameters: hyphen-case
• Headers: hyphen-case
• Query parameters: camelCase
• Body properties: camelCase

I created an API spec to illustrate the idea for the feature I suggested and this API has the following paths:

Please note the path parameter api-parameter-one defined at lines 108 and 114. And then, the query parameter apiParameterTwo at line 119.

The options.json file is defined as shown below:

When I run the validator using the spec and the options above, I get the following errors:

The second and the last error are expected, so we can ignore them.

The point is that the validator is validating path parameters and query parameters using the same naming convention. So, what I would like to have is an option to specify different naming conventions for each type of parameter.

I hope I could make myself clear now 😃

Thanks!

[JFCote]

Hi @araki-nobuteru

You are absolutely right and I was mistaken! The pathNamingConvention is strictly validating for the URL itself without the parameters. All parameters are validated with the same naming convention except the header (for some reason).

So I guess it would make sense to have something like this:

• pathNamingConvention -> for the rest of the url
• queryParamNamingConvention -> for query param
• pathParamNamingConvention -> for path param
• headerParamNamingConvention -> for header param
• cookieParamNamingConvention -> for cookie param

The following parameters would become deprecated but still accepted for a couple of versions:

• parameterNamingConvention
• headerNamingConvention

Would that follow your requirements?

[araki-nobuteru]

Hi @JFCote!

Yes, I think this configuration will address the requirement.

Just a question: what you called cookie parameters would be the formData parameters?

[JFCote]

Hi @araki-nobuteru ,

OpenAPI V3 only support 4 types which is:

But since we want to support OpenAPI V2, I will need to think about it a little more since in V2 we have more type:

I'm kind of in a rush right now, if you have any idea how to tackle this, let me know!

[araki-nobuteru]

Hi @JFCote ,

I'm fiddling with the code as I have some free time. My initial suggestion is to add another parameter in the options.json file to deal with formData params in the API specs. Something like this:

• formDataParamNamingConvention

I'll let you know if some different idea comes to my mind.