Add visibility the to rest-spec-api
#56104
Merged
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
|
Pinging @elastic/es-core-infra (:Core/Infra/REST API) |
dakrone
reviewed
May 4, 2020
rest-api-spec/src/main/resources/rest-api-spec/api/indices.put_index_template.json
Outdated
Show resolved
Hide resolved
|
It is still unclear to me why |
Mpdreamz
force-pushed
the
feature/rest-spec-visibility
branch
from
49cb189 to
8d09e42
Compare
Mpdreamz
force-pushed
the
feature/rest-spec-visibility
branch
3 times, most recently
from
dd3e52e to
b441fec
Compare
...n/src/test/resources/rest-api-spec/api/data_frame_transform_deprecated.update_transform.json
Show resolved
Hide resolved
picandocodigo
approved these changes
Dec 10, 2020
sethmlarson
approved these changes
Dec 10, 2020
|
After some further thought, I think the advantages of having all our APIs included in the spec, even for internal uses, is valuable so that we can validate we have not missing any specs. LGTM. |
This documents API intended exposure to the outside world. * `private`, API is not exposed on clients * `feature_flag` API is exposed on clients but clients can emit documentation on the fact its not available OOTB. * `public`, the API is publicly available in distributions. `visibility` does not replace `stability` as that only documents the state of development for the API. An `experimental` API can be `public` and `stable` API's can be behind a `feature_flag`. There are currently no restrictions on this.
…he parser validated this
Mpdreamz
force-pushed
the
feature/rest-spec-visibility
branch
from
996e842 to
8c8ab07
Compare
Mpdreamz
added a commit
to Mpdreamz/elasticsearch
that referenced
this pull request
Dec 15, 2020
(cherry picked from commit e31e3de)
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.
This documents API's intended exposure to the outside world under a new key
visibility:private, API is not exposed on clientsfeature_flagAPI is exposed on clients but clients can emit documentation on the fact its not available OOTB.public, the API is publicly available in distributions.If an API has
visibility: feature_flagit also needs to document the feature flag its behind underfeature_flag: "es.___".ClientYamlSuiteRestApiParser.javais updated to reflect this requirement.visibilitydoes not replacestabilityas that only documents the state of development for the API. AnexperimentalAPI can bepublicandstableAPI's can be behind afeature_flag. There are currently no restrictions on this.Relates to #54664 (comment) where new API's have come in that are fully intended to be
private. As well as several API's coming in that are behind feature_flags.When
stabilitywas introduced in #38413 (comment) we decided to hold of onprivate. I feel the API has changed significantly since to reconsider this decision.