2xx codes treated as error response

[acwl-aiq]

Describe the bug In the HTTP world, 2xx response codes tend to be treated as success. For instance, 201 is an extension of 200 which indicates the creation of a resource.

Problem This function here dictates what code is acceptable as a response code. It will default to 200 or the first 2xx code in the list of defined responses and there is no way to specify which responses are acceptable.

https://github.com/MarcoMuellner/openapi-python-generator/blob/390ce1a90e51669ad7645c69d970e92f25ab6723/src/openapi_python_generator/language_converters/python/service_generator.py#L196

In other words, there's no way for the service provider to dictate multiple response codes as "good"

An alternative to this problem is to allow the client to decide which response codes to treat as error but the current implementation forbids that and instead throws an exception on the behalf of the client if that singular response code is not observed. The workaround for the service is to always return 200 OK

Expected behavior Either:

1. Treat 2xx as good
2. Allow 2xx responses to be treated as good if defined in "responses" param of the API
3. Option to let client to handle response codes

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context Add any other context about the problem here.

[drsybren]

Describe the bug In the HTTP world, 2xx response codes tend to be treated as success.

It's stronger than that. The 2xx range is literally defined as "Successful" in RFC 9110, which defines the semantics of the HTTP protocol.

I use 204 No Content a lot in my API, which is a standard way of signalling "I did the thing, and have nothing to say in response".