github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-09-05 03:03:40 +00:00
Code Issues Projects Releases Wiki Activity

Move docs/services-firewalls.md into docs/user-guide/ and make small

Browse Source 
wording changes to api.md
This commit is contained in:
David Oppenheimer
2015-07-16 02:03:32 -07:00
parent 596a8a40d1
commit fd2c3695e3
4 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/api.md
View File

@@ -44,9 +44,9 @@ What constitutes a compatible change and how to change the API are detailed by t
## API versioning
Fine-grain resource evolution alone makes it difficult to eliminate fields or restructure resource representations. Therefore, Kubernetes supports multiple API versions, each at a different API path prefix, such as `/api/v1beta3`. These are simply different interfaces to read and/or modify the same underlying resources. In general, all API resources are accessible via all API versions, though there may be some cases in the future where that is not true.
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path prefix, such as `/api/v1beta3`. These are simply different interfaces to read and/or modify the same underlying resources. In general, all API resources are accessible via all API versions, though there may be some cases in the future where that is not true.
Distinct API versions present more clear, consistent views of system resources and behavior than intermingled, independently evolved resources. They also provide a more straightforward mechanism for controlling access to end-of-lifed and/or experimental APIs.
We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-lifed and/or experimental APIs.
The [API and release versioning proposal](design/versioning.md) describes the current thinking on the API version evolution process.