Treat new PUT request properties as compatible again #538
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mas-chen
reviewed
Jul 20, 2023
| } | ||
|
|
||
| @Test | ||
| public void testDiffDifferent() { |
There was a problem hiding this comment.
I don't think we should remove this test. In fact it should be kept to check that the two docs are indeed compatible.
So we should have a testFieldAdditionalInPutApiIsCompatible or something similar
There was a problem hiding this comment.
I think it's better to keep changes isolated. Since this PR is introducing a new fix, that particular test should be included here, to validate your change
There was a problem hiding this comment.
Fair enough. I've made your suggested changes. Look ok?
There was a problem hiding this comment.
Looks good to me but I'm not a contributor, would be good to get the help of one to merge this fix
Effectively reverts change for OpenAPITools#136 which appears invalid in intent, implementation, and test. - Invalid in intent: OpenAPITools#136 claims that adding a readOnly property to the request body of a PUT request is a breaking change because clients will begin to omit it and the server will interpret the omission as a directive to delete the property. This is incorrect because the server should expect, [per the OAS spec](https://spec.openapis.org/oas/v3.0.3#fixed-fields-19), that readOnly properties "SHOULD NOT be sent as part of the request". So it would be a bug for the server to delete any data associated with the readOnly property. Regardless, the API is left unbroken if the server simply ignores readOnly properties. - Invalid in implementation: the code treats as incompatible any PUT request property, not just readOnly properties. - Invalid in test: no readOnly properties are tested. In theory one could argue that some servers might enforce the "SHOULD NOT" language of the spec by returning validation errors where they didn't before, and this would constitute an API breakage. But that should be discussed in a different issue.
westse
force-pushed
the
read-only-prop-put
branch
from
57bf492
to
be914cb
Compare
mas-chen
approved these changes
Jul 21, 2023
joschi
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Effectively reverts change for #136 (and PR #137) which appear invalid in intent, implementation, and test.
In theory one could argue that some servers might enforce the "SHOULD NOT" language of the spec by returning validation errors where they didn't before, and this would constitute an API breakage. But that should be discussed in a different issue.
Fixes #537
Refs #136
Refs #137