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

Fix Issue #136 new read-only property breaks PUT #137

Merged
merged 1 commit into from
Aug 27, 2020

Conversation

trohrberg
Copy link

@trohrberg trohrberg commented Mar 24, 2020

Adding a new read-only property into an API model should be considered a breaking change for PUT operations. A client not knowing of the new read-only property would get a resource from the API which includes the new read-only property and would send a full update back via PUT omitting that new property. The result is that the property would be cleared on the server side as the client did not sent the retrieved value back.

Fixes #136

Adding a new read-only property into an API model should be considered a breaking change for PUT operations. A client not knowing of the new read-only property would get a resource from the API which includes the new read-only property and would send a full update back via PUT omitting that new property. The result is that the property would be cleared on the server side as the client did not sent the retrieved value back.
@quen2404 quen2404 merged commit 72eaac9 into OpenAPITools:master Aug 27, 2020
joschi pushed a commit that referenced this pull request Jul 25, 2023
Effectively reverts change for #136 (and PR #137) which appear invalid in intent, implementation, and test.

- Invalid in intent: #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 new 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.

Fixes #537
Refs #136
Refs #137
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Invalid backward compatibility result for new read-only property in PUT operations
2 participants