[Python][Validation] Knob to control whether to ignore additional attribute in the HTTP response
Created by: sebastien-rosset
Bug Report Checklist
-
Have you provided a full/minimal spec to reproduce the issue? -
Have you validated the input using an OpenAPI validator (example)? -
What's the version of OpenAPI Generator used? -
Have you search for related issues/PRs? -
What's the actual output vs expected output? -
[Optional] Bounty to sponsor the fix (example)
Description
I've noticed SDKs are inconsistent in how they handle additional, undeclared attributes in HTTP response. What do you think about having a language-independent parameter that controls the leniency?
Some clients (such as python-experimental) do strict validation of the response. If the response includes undeclared properties that the client does not know about, the client raises an exception. Other clients (such as go and Java) are lenient and ignore additional attributes from the server JSON response.
Use case: The client has been generated and keeps running for weeks without problem. Then the server is upgraded to a newer version, adding one more declared property in the schema, in a way which is backward compatible. I.e. the OAS spec has a new property to an existing API. The new server sends the new property when the existing API is requested. The problem is as soon as the server is upgraded, the clients will start failing. If there are thousands of clients, this is bad because as soon as the server is upgraded, all clients fail and must be upgraded.
A user of the client SDK may have the intent to run the same version of the SDK for a while, even if the server is upgraded. They may be perfectly fine doing this because the server provides backward compatibility guarantees and new attributes can be safely ignored. Other users may want to make sure the client fails when a new attribute in sent by the server, because they really want the client and server to be always at the same version.
As a workaround, it's possible to set "additionalproperties" in the spec everywhere, to prepare for additions to the spec. I don't find this solution very appealing because it can't address the above use cases.
openapi-generator version
master February 17th 2020