The Wayback Machine - https://web.archive.org/web/20211230104558/https://github.com/OpenAPITools/openapi-generator/issues/1260
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Python] boolean query parameter capitalization #1260

Open
ryanfox opened this issue Oct 17, 2018 · 5 comments
Open

[Python] boolean query parameter capitalization #1260

ryanfox opened this issue Oct 17, 2018 · 5 comments
Labels
Client: Python Good First Issue Issue: Bug

Comments

@ryanfox
Copy link

@ryanfox ryanfox commented Oct 17, 2018

(Copy of swagger-api/swagger-codegen#8433)

Description

The generated python client translates boolean query parameters in Python case - i.e. "True"/"False" rather than "true"/"false".

I am dealing with a case-sensitive API endpoint, which expects a boolean query parameter, and treats anything except "0" and "false" as true - including "False" evaluating to true.

Per RFC 3986, the query part of a URI should be treated as case-sensitive. I suspect many (most?) servers in the wild expect "false", in line with the variable names in most languages.

Is this expected behavior?

Swagger-codegen version

2.4.0-SNAPSHOT

Swagger declaration file content or url

        "parameters": [
          {
            "name": "reverse",
            "in": "query",
            "description": "If true, will sort results newest first.",
            "required": false,
            "default": false,
            "type": "boolean"
          }
        ],

Command line used for generation

java -jar ./swagger-codegen/modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i ./swagger.json -l python -o generated/python

Steps to reproduce

# given an API endpoint which accepts a boolean query parameter
>>> foo_list = client.Foo.Foo_get(reverse=True)
>>> foo_list.future.request.prepare()
>>> print(foo_list.url)
http://example.com/api/foo?reverse=True

Suggest a fix/enhancement

Suggestion: instead of "True" or "False", convert to the string "true" or "false".
@wing328
Copy link
Member

@wing328 wing328 commented Oct 19, 2018

@ryanfox one workaround is to document the query parameter as a string instead of boolean and users will need to input either "true" or "false"

Another way is to use customized templates with the -t option and add logic to normalize the values inside the following mustache tag:

{{#isBoolean}}
...
{{/isBoolean}}
@ryanfox
Copy link
Author

@ryanfox ryanfox commented Oct 22, 2018

Thanks for the info. That's not going to work for the use case I am working with - what do you think the chances are of implementing a fix?

In any case, good to know there is a workaround.
@spacether
Copy link
Contributor

@spacether spacether commented Dec 9, 2019

@ryanfox why would the string solution not work in your use case?
Why not make it a string enum?

      - name: "reverse"
        in: "query"
        description: 'If true, will sort results newest first.'
        required: false
        default: "false"
        type: "string"
        enum:
        - "true"
        - "false"
@mcejp
Copy link

@mcejp mcejp commented Mar 15, 2021

@spacether Perhaps because it adds a lot of noise to the spec, lies to every tool involved including the API generator, and generally just smells of a massive, dirty hack? :))
@spacether
Copy link
Contributor

@spacether spacether commented Mar 15, 2021 •
edited

Not saying that it shouldn't be fixed. My goal was to provide solution that unblocks Ryan.
We welcome any PRs that fix issues. Do you want to work on fixing this @ryanfox or @mcejp ?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client: Python Good First Issue Issue: Bug
4 participants
@ryanfox @wing328 @spacether @mcejp