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

Grammar and Markdown fixes for api-conventions #3755

Merged
merged 1 commit into from Jun 2, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
31 changes: 13 additions & 18 deletions contributors/devel/sig-architecture/api-conventions.md
Expand Up @@ -25,7 +25,6 @@ An introduction to using resources with kubectl can be found in [the object mana
- [Differing Representations](#differing-representations)
- [Verbs on Resources](#verbs-on-resources)
- [PATCH operations](#patch-operations)
- [Strategic Merge Patch](#strategic-merge-patch)
- [Idempotency](#idempotency)
- [Optional vs. Required](#optional-vs-required)
- [Defaulting](#defaulting)
Expand Down Expand Up @@ -163,7 +162,7 @@ are not singular JSON objects, such as streams of JSON objects or unstructured
text log data.

A common set of "meta" API objects are used across all API groups and are
thus considered part of the server group named `meta.k8s.io`. These types may
thus considered part of the API group named `meta.k8s.io`. These types may
evolve independent of the API group that uses them and API servers may allow
them to be addressed in their generic form. Examples are `ListOptions`,
`DeleteOptions`, `List`, `Status`, `WatchEvent`, and `Scale`. For historical
Expand Down Expand Up @@ -252,7 +251,7 @@ or otherwise changed after creation by other ecosystem components (e.g.,
schedulers, auto-scalers), and is persisted in stable storage with the API
object. If the specification is deleted, the object will be purged from the
system. The status summarizes the current state of the object in the system, and
is usually persisted with the object by an automated processes but may be
is usually persisted with the object by automated processes but may be
generated on the fly. At some cost and perhaps some temporary degradation in
behavior, the status could be reconstructed by observation if it were lost.

Expand Down Expand Up @@ -499,8 +498,8 @@ as `nfs` and `iscsi`. All fields in the set should be
Sometimes, when a new type is created, the api designer may anticipate that a
union will be needed in the future, even if only one field is allowed initially.
In this case, be sure to make the field [Optional](#optional-vs-required)
optional. In the validation, you may still return an error if the sole field is
unset. Do not set a default value for that field.
In the validation, you may still return an error if the sole field is unset. Do
not set a default value for that field.

### Lists and Simple kinds

Expand Down Expand Up @@ -572,23 +571,19 @@ The API supports three different PATCH operations, determined by their
corresponding Content-Type header:

* JSON Patch, `Content-Type: application/json-patch+json`
* As defined in [RFC6902](https://tools.ietf.org/html/rfc6902), a JSON Patch is
* As defined in [RFC6902](https://tools.ietf.org/html/rfc6902), a JSON Patch is
a sequence of operations that are executed on the resource, e.g. `{"op": "add",
"path": "/a/b/c", "value": [ "foo", "bar" ]}`. For more details on how to use
JSON Patch, see the RFC.
* Merge Patch, `Content-Type: application/merge-patch+json`
* As defined in [RFC7386](https://tools.ietf.org/html/rfc7386), a Merge Patch
* As defined in [RFC7386](https://tools.ietf.org/html/rfc7386), a Merge Patch
is essentially a partial representation of the resource. The submitted JSON is
"merged" with the current resource to create a new one, then the new one is
saved. For more details on how to use Merge Patch, see the RFC.
* Strategic Merge Patch, `Content-Type: application/strategic-merge-patch+json`
* Strategic Merge Patch is a custom implementation of Merge Patch. For a
* Strategic Merge Patch is a custom implementation of Merge Patch. For a
detailed explanation of how it works and why it needed to be introduced, see
below.

#### Strategic Merge Patch

Details of Strategic Merge Patch are covered [here](/contributors/devel/sig-api-machinery/strategic-merge-patch.md).
[here](/contributors/devel/sig-api-machinery/strategic-merge-patch.md).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewers: I got rid of this section in the markdown document because the whole section was just a link to another doc describing the strategic merge patch and the bullet list entry directly above here contained virtually the exact phrase as what was contained in this section. So, I just condensed the whole section to be a link to the strategic merge patch document from the bulleted list entry above.


## Idempotency

Expand Down Expand Up @@ -630,8 +625,8 @@ different logic for an optional field which is not provided vs. provided with
empty values, do not use `omitempty` (e.g. https://github.com/kubernetes/kubernetes/issues/34641).

Note that for backward compatibility, any field that has the `omitempty` struct
tag will considered to be optional but this may change in future and having
the `+optional` comment tag is highly recommended.
tag will be considered to be optional, but this may change in the future and
having the `+optional` comment tag is highly recommended.

Required fields have the opposite properties, namely:

Expand Down Expand Up @@ -879,11 +874,11 @@ was not supported by the code.
* Indicates that either the resource the client attempted to create already
exists or the requested update operation cannot be completed due to a conflict.
* Suggested client recovery behavior:
* * If creating a new resource:
* * Either change the identifier and try again, or GET and compare the
* If creating a new resource:
* Either change the identifier and try again, or GET and compare the
fields in the pre-existing object and issue a PUT/update to modify the existing
object.
* * If updating an existing resource:
* If updating an existing resource:
* See `Conflict` from the `status` response section below on how to
retrieve more information about the nature of the conflict.
* GET and compare the fields in the pre-existing object, merge changes (if
Expand Down