Skip to content

Commit 2d2fcc4

Browse files
author
Ron
authored
Merge pull request OAI#1354 from a-akimov/patch-1
Update README
2 parents 875ec9a + 103054f commit 2d2fcc4

File tree

1 file changed

+8
-13
lines changed

1 file changed

+8
-13
lines changed

README.md

Lines changed: 8 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -6,25 +6,23 @@
66

77
**This is the WIP branch for the next patch version of the spec - 3.0.1. Patch level corrections should be submitted against this branch, specifically against [3.0.1.md](https://github.com/OAI/OpenAPI-Specification/blob/v3.0.1/versions/3.0.1.md).**
88

9-
The OpenAPI Specification is a community driven, open specification within the [Open API Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
9+
The OpenAPI Specification is a community-driven open specification within the [Open API Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
1010

11-
The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. 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 guesswork in calling a service.
11+
The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for [REST APIs](https://en.wikipedia.org/wiki/Representational_state_transfer), which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. 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 guesswork in calling a service.
1212

13-
Use cases for machine-readable API definition documents include, but are not limited to, interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. OpenAPI documents describe an API's services and are represented in either YAML or JSON formats. These documents may either be produced and served statically or be generated dynamically from an application.
13+
Use cases for machine-readable API definition documents include, but are not limited to: interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. OpenAPI documents describe an API's services and are represented in either YAML or JSON formats. These documents may either be produced and served statically or be generated dynamically from an application.
1414

15-
The OpenAPI Specification does not require rewriting existing APIs. It does not require binding any software to a servicethe service being described may not even be owned by the creator of its description. 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 OpenAPIthis specification is not intended to cover every possible style of REST APIs. The OpenAPI Specification does not mandate a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with a REST API.
15+
The OpenAPI Specification does not require rewriting existing APIs. It does not require binding any software to a servicethe service being described may not even be owned by the creator of its description. 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 OpenAPIthis specification is not intended to cover every possible style of REST APIs. The OpenAPI Specification does not mandate a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with a REST API.
1616

17-
This GitHub project is the starting point for OpenAPI.
18-
Here you will find the information you need about the OpenAPI Specification, simple examples of what it looks like, and some general information regarding the project.
17+
This GitHub project is the starting point for OpenAPI. Here you will find the information you need about the OpenAPI Specification, simple examples of what it looks like, and some general information regarding the project.
1918

2019
## Current Version - 3.0
2120

2221
The current version of the OpenAPI specification is [OpenAPI Specification 3.0](versions/3.0.0.md).
2322

2423
### Previous Versions
2524

26-
This repository also contains the [OpenAPI Specification 2.0](versions/2.0.md), which is identical to the Swagger 2.0 specification before it was renamed to “OpenAPI Specification”,
27-
as well as the Swagger 1.2 and Swagger 2.0 specifications.
25+
This repository also contains the [OpenAPI Specification 2.0](versions/2.0.md), which is identical to the Swagger 2.0 specification before it was renamed to "OpenAPI Specification", as well as the Swagger 1.2 and Swagger 2.0 specifications.
2826

2927
Each folder in this repository, such as [examples](examples) and [schemas](schemas), should contain folders pertaining to the current and previous versions of the specification.
3028

@@ -35,16 +33,15 @@ If you just want to see it work, check out the [list of current examples](exampl
3533
## Tools and Libraries
3634

3735
Looking to see how you can create your own OpenAPI definition, present it, or otherwise use it? Check out the growing
38-
[list of 3.0 Implementations](IMPLEMENTATIONS.md).
36+
[list of 3.0 implementations](IMPLEMENTATIONS.md).
3937

4038
## Participation
4139

4240
The current process for development of the OpenAPI Specification is described in
4341
[Development Guidelines](DEVELOPMENT.md).
4442
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). 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.
4543

46-
The Open API Initiative encourages participation from individuals and companies alike.
47-
If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions:
44+
The Open API Initiative encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions:
4845

4946
* Review the [current specification](versions/3.0.0.md). The human-readable markdown file _is the source of truth_ for the specification.
5047
* Review the [development](DEVELOPMENT.md) process so you understand how the spec is evolving.
@@ -55,8 +52,6 @@ Not all feedback can be accommodated and there may be solid arguments for or aga
5552

5653
## License
5754

58-
5955
See: [License (Apache-2.0)](https://github.com/OAI/OpenAPI-Specification/blob/master/LICENSE)
6056

61-
6257
![Analytics](https://ga-beacon.appspot.com/UA-831873-42/readme.md?pixel)

0 commit comments

Comments
 (0)