query string parameter names should not be transformed with respect to case

[lorenjerickson]

According to the W3 spec for URIs, query string parameter names should be considered case-sensitive unless the scheme being used specifically calls them out as being case-insensitive. See this. Note that the HTTP spec here does not specify that query parameters are case-insensitive, therefore they must be treated as case-sensitive per the URI spec.

When presented with a query string parameter whose name is all uppercase, TOK for example, the generator assumes the name of the parameter provided in the params input to the operation will be in camel case (lower case first letter, so tOK in this example). The discrepancy between the name of the field in the params input will become a source of confusion and is not consistent with the specification of the path.

In any case, it is my responsibility as the API provider to document the API correctly and I would prefer that the API present the _exact_ interface that I specify in the JSON. The generator should not perform any transformation of the parameter names anywhere, in my opinion, regardless of whatever conventions may be common in the language. In other words, no assumptions should be made by the generator about conventions that may be in use by the API.

So this:

{
    . . . 
    "schemes": ["https"],
    "paths": {
        "/thing/{id}": {
            "get": {
                "summary": "Get a thing",
                "description": "A route to get a thing.",
                "operationId": "getThingById",
                "parameters": [{
                    "name": "TOK",
                    "in": "query",
                    "description": "application token whose name will get transformed to tOK, which is NOT OK",
                    "required": true,
                    "type": "string"
                }],
    . . . 
}

Gets transformed into something like this:

if (parameters['tOK'] !== undefined) {
    queryParameters['TOK'] = parameters['tOK'];
}

Sample thing.json file available if needed.

[wcandillon]

@lorenjerickson I fixed the bug in version 1.0.0, can you confirm?

[lorenjerickson]

Confirmed. Thank you!

On Sat, Mar 14, 2015 at 11:20 AM William Candillon notifications@github.com
wrote:

@lorenjerickson https://github.com/lorenjerickson I fixed the bug in
version 1.0.0, can you confirm?

—
Reply to this email directly or view it on GitHub
#62 (comment)
.