Update api-conventions.md
Moved compatibility gotchas to api_changes.md
This commit is contained in:
parent
64c17b12ff
commit
de51cfaba5
|
@ -1463,22 +1463,6 @@ be less than 256", "must be greater than or equal to 0". Do not use words
|
|||
like "larger than", "bigger than", "more than", "higher than", etc.
|
||||
* When specifying numeric ranges, use inclusive ranges when possible.
|
||||
|
||||
## Backward compatibility gotchas
|
||||
|
||||
* A single feature/property cannot be represented using multiple spec fields in the same API version
|
||||
simultaneously. Only one field can be populated in any resource at a time, and the client
|
||||
needs to be able to specify which field they expect to use (typically via API version),
|
||||
on both mutation and read. Old clients must continue to function properly while only manipulating
|
||||
the old field. New clients must be able to function properly while only manipulating the new
|
||||
field.
|
||||
* Changing any validation rules always has the potential of breaking some client, since it changes the
|
||||
assumptions about part of the API, similar to adding new enum values. Validation rules on spec fields can
|
||||
neither be relaxed nor strengthened. Strengthening cannot be permitted because any requests that previously
|
||||
worked must continue to work. Weakening validation has the potential to break other consumers and generators
|
||||
of the API resource. Status fields whose writers are under our control (e.g., written by non-pluggable
|
||||
controllers), may potentially tighten validation, since that would cause a subset of previously valid
|
||||
values to be observable by clients.
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
|
Loading…
Reference in New Issue