-
Notifications
You must be signed in to change notification settings - Fork 9.2k
Update readme for v3 #1281
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
Update readme for v3 #1281
Conversation
Incorporated first batch of suggestions from TDC, before any changes from the gdoc.
README.md
Outdated
| The OpenAPI Specification defines a standard, language-agnostic interface description for REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, additional documentation, or through network traffic inspection. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes the guesswork in calling the service. | ||
|
|
||
| Development of the next version of the OpenAPI Specification is guided by the [OAI Technical Contributors Board](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/CONTRIBUTORS.md). This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate. All development activity on the future specification will be performed as features and merged into this branch. Upon release of the OpenAPI Specification, this branch will be merged to master. | ||
| Use cases for machine-readable API interfaces include interactive documentation; code generation for documentation, client, and server; and automated test cases. OpenAPI descriptions describe APIs via YAML or JSON documents that adhere to the OpenAPI Specification. These documents can either be produced and served statically, or be generated dynamically from your application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still up for debate, but I think we're opting the term "OpenAPI definitions" for the instance docments: "OpenAPI definitions define APIs ...". but that's a bit awkward. "An API is defined by an OpenAPI definition: a YAML or JSON document that adheres to the OpenAPI specification."
README.md
Outdated
| Use cases for machine-readable API interfaces include interactive documentation; code generation for documentation, client, and server; and automated test cases. OpenAPI descriptions describe APIs via YAML or JSON documents that adhere to the OpenAPI Specification. These documents can either be produced and served statically, or be generated dynamically from your application. | ||
|
|
||
| The current process for development of the OpenAPI Specification is described in [Development Guidelines](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md). | ||
| The OpenAPI Specification does not require you to rewrite your existing API. It does not require binding any software to a service--the service being described may not even be yours. It does, however, require the capabilities of the service be described in the structure of the OpenAPI Specification. Not all services can be described by OpenAPI--this specification is not intended to cover every possible use-case of a REST API. The OpenAPI Specification does not define a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with a REST API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the -- to — (—) in a couple locations. When I view this, the line gets split between the first and second -.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also changed "described" to "defined".
| ### Previous Versions | ||
|
|
||
| This repository also contains the [OpenAPI Specification 2.0](versions/2.0), which is identical to the Swagger 2.0 specification, | ||
| as well as the Swagger 1.2 and Swagger 2.0 specifications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of redundancy here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically it only currently contains one copy of the OpenAPI 2.0 specification, not the Swagger 2.0 specification as well.
README.md
Outdated
|
|
||
| ## Tools and Libraries | ||
|
|
||
| Looking to see how you can create your own OpenAPI definition, present it or otherwise use it? Check out the growing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add a comma after "present it"
README.md
Outdated
| The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. The OAI encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions: | ||
| The current process for development of the OpenAPI Specification is described in | ||
| [Development Guidelines](DEVELOPMENT.md). | ||
| Development of the next version of the OpenAPI Specification is guided by the [Technical Developer Community](https://www.openapis.org/participate/how-to-contribute/governance#TDC) and governed by the [TDC Contributors](CONTRIBUTORS.md). This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate. All development activity on the future specification will be performed as features and merged into this branch. Upon release of the future specification, this branch will be merged to master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove "the next version of"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"bring", "incorporate", "expand" should be "brings", "incorporates", "expands" (as in "this group ... brings")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can probably drop the process info about "this branch" and merging" as when this becomes the README, this will have been completed and will be in master. I think it is too early to say what the post 3.0.0 process and branch strategy will be. Need more TDC input on this. (I think removing this from the main README is OK - it should be in DEVELOPING.md which is mentioned immediately below)
Work by people in the TDC and marketing committee
README.md
Outdated
| The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. The OAI encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions: | ||
| The current process for development of the OpenAPI Specification is described in | ||
| [Development Guidelines](DEVELOPMENT.md). | ||
| Development of the next version of the OpenAPI Specification is guided by the [Technical Developer Community](https://www.openapis.org/participate/how-to-contribute/governance#TDC) and governed by the [TDC Contributors](CONTRIBUTORS.md). This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate. All development activity on the future specification will be performed as features and merged into this branch. Upon release of the future specification, this branch will be merged to master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"governed by the [TDC Contributors]" governed seems the wrong word.
README.md
Outdated
| The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. The OAI encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions: | ||
| The current process for development of the OpenAPI Specification is described in | ||
| [Development Guidelines](DEVELOPMENT.md). | ||
| Development of the next version of the OpenAPI Specification is guided by the [Technical Developer Community](https://www.openapis.org/participate/how-to-contribute/governance#TDC) and governed by the [TDC Contributors](CONTRIBUTORS.md). This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate. All development activity on the future specification will be performed as features and merged into this branch. Upon release of the future specification, this branch will be merged to master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per TDC I'll remove the link and discussion of contributors for now.
Incorporated first batch of suggestions from TDC, before any changes
from the gdoc.