Skip to content

Commit fd6718e

Browse files
authored
Merge pull request #1 from OAI/master
Update fork from origin OAI/OpenAPI-Specification repo
2 parents e5bfee3 + 9a1e621 commit fd6718e

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

46 files changed

+4713
-1510
lines changed

.travis.yml

+15-5
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,18 @@
11
sudo: false
2-
language: scala
3-
scala:
4-
- 2.10.4
52
script:
63
- npm install
7-
- npm test
8-
- sbt ++$TRAVIS_SCALA_VERSION test
4+
env:
5+
- VALIDATORS=tv4
6+
- VALIDATORS=zschema
7+
matrix:
8+
allow_failures:
9+
- env: VALIDATORS=tv4
10+
install:
11+
- rm -rf ~/.nvm
12+
- curl -L https://raw.githubusercontent.com/creationix/nvm/master/install.sh | sh
13+
- source ~/.nvm/nvm.sh
14+
- nvm install 6.1
15+
- nvm use 6.1
16+
script:
17+
- npm install
18+
- node node_modules/mdv/mdv versions/3.*.md

CONTRIBUTORS.md

+9
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
2+
* Jason Harmon [@jharmn](https://github.com/jharmn)
3+
* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
4+
* Kris Hahn [@KrisHahn](https://github.com/krishahn)
5+
* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
6+
* Mike Ralphson [@MikeRalphson](https://github.com/mikeralphson)
7+
* Rob Dolin [@RobDolinMS](https://github.com/robdolinms)
8+
* Ron Ratovsky [@webron](https://github.com/webron)
9+
* Tony Tam [@fehguy](https://github.com/fehguy)

DEVELOPMENT.md

+56
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
## Development Guidelines
2+
3+
This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The Open API Technical Developer Community will initially follow these processes when merging changes from external contributors or from the TDC itself. This guideline document will be adjusted as practicality dictates.
4+
5+
## OAI Specification Driving factors
6+
7+
The OpenAPI Specification should be use-case driven. We can specify support for hypothetical use cases as we see fit, but specifications should be backed by realistic scenarios.
8+
9+
## Specification Change Criteria
10+
11+
The specification _will change_ from the original 2.0 version. We should typically make changes when any of the following criteria are met:
12+
13+
- Clarity. The current "way" something is done doesn't make sense, is complicated, or not clear.
14+
- Consistency. A portion of the specification is not consistent with the rest, or with the industry standard terminology.
15+
- Necessary functionality. We are missing functionality because of a certain design of the specification.
16+
- Forward-looking designs. As usage of APIs evolves to new protocols, formats, and patterns, we should always consider what the next important functionality should be.
17+
- Impact. A change will provide impact on a large number of use cases. We should not be forced to accommodate every use case. We should strive to make the _common_ and _important_ use cases both well supported and common in the definition of the OAI Spec. We cannot be edge-case driven.
18+
19+
20+
## Tracking Process
21+
22+
- Use GitHub for all spec designs, use cases, and so on.
23+
- As with 2.0, the **human readable** document is the source of truth. If using a JSON Schema again to document the spec, it is secondary to the human documentation. The documentation should live in a *.md file, in parallel to the 2.0 document (versions/3.0.0.md for example).
24+
- At any given time, there would be _at most_ 4 work branches. The branches would exist if work has started on them. Assuming a current version of 3.0.0:
25+
- `master` - Current stable version. No PRs would be accepted directly to modify the specification. PRs against supporting files can be accepted.
26+
- `v3.0.1` - The next PATCH version of the specification. This would include non-breaking changes such as typo fixes, document fixes, wording clarifications.
27+
- `v3.1.0` - The next MINOR version.
28+
- `v4.0.0` - The next MAJOR version.
29+
- The `master` branch shall remain the current, released OpenAPI Specification. We will describe and link the work branch(es) on the **default** README.md on master.
30+
- Examples of how something is described _currently_ vs. the proposed solution should accompany any change proposal.
31+
- New features should be done in feature branches/forks which, upon approval, are merged into the proper work branch.
32+
- Use labels for the workflow of specification changes. Examples of labels are `proposed`, `needs migration review`, `needs tooling review`, `needs documentation`, `rejected`, and `needs approval`. These labels must be assigned by project committers.
33+
- An issue will be opened for each feature change. Embedded in the issue, or ideally linked in a file via pull-request (PR), a document about use cases should be supplied with the change.
34+
- A PR will be used to describe the _proposed_ solution, and linked to the original issue.
35+
- Not all committers will contribute to every single proposed change. There may be many open proposals at once, and multiple efforts may happen in parallel.
36+
- When the a work branch is ready and approved, the branch will be merged to master.
37+
38+
## Approving Changes
39+
40+
For each change in the specification we should _always_ consider the following:
41+
42+
- Migration. Is this a construct that has a path from the existing 2.0 specification? If so, how complicated is it to migrate to the proposed change?
43+
- Tooling. Strive to support code generation, software interfaces, and spec generation techniques. Some features may be impossible to support in different frameworks/languages. These should be documented and considered during the change approval process.
44+
- Visualization. Can the specification change be graphically visualized somehow in a UI or other interface?
45+
46+
Spec changes should be approved by a majority of the committers. Approval can be given by commenting on the issue itself, for example, "Approved by @fehguy". After voting criteria is met, any committer can merge the PR. (**TODO**: we will want to formalize what voting criteria actually is).
47+
48+
No change should be approved until there is documentation for it, supplied in an accompanying PR.
49+
50+
## Transparency
51+
52+
We should always be as transparent as possible. Sometimes there will be discussions that use customer names, sensitive use cases, and so on. These must be anonymized, discussed in a private repository, or conducted offline.
53+
54+
- Asynchronous discussions should live in the GitHub issues for this project.
55+
- Realtime discussions should be in a public chat such as IRC or Slack.
56+

IMPLEMENTATIONS.md

+47
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
### Implementations
2+
3+
Below is a list of known tooling that implements the 3.0.0 specification. While support for the 3.0.0 specification matures, refer to the details of projects listed below for any notes about stability and roadmap. The process to improve the 3.x specification includes feedback from end-users and tooling creators. We strongly encourage draft tooling be made available for early users of OAS drafts.
4+
5+
These tools are not necessarily endorsed by the OAI.
6+
7+
#### Low-Level tooling
8+
9+
| Title | Project Link | Language |Description |
10+
|----------------|--------------|----------|---------------------|
11+
| swagger-parser | [GitHub/swagger-api](https://github.com/swagger-api/swagger-parser/tree/feature/3.0.0-rc0) | Java | Swagger 1.0, 1.1, 1.2, 2.0 to Open API Specification converter |
12+
| swagger-models | [GitHub/swagger-api](https://github.com/swagger-api/swagger-core/tree/feature/3.0.0-rc0/modules/swagger-models) | Java | Open API 3.0 Java Pojos |
13+
| KaiZen OpenAPI Parser | [GitHub/RepreZen/KaiZen-OpenAPI-Parser](https://github.com/RepreZen/KaiZen-OpenAPI-Parser) | Java | High-performance Parser, Validator, and Java Object Model for OpenAPI 3.x |
14+
| openapi3-ts | [GitHub/metadevpro/openapi3-ts](https://github.com/metadevpro/openapi3-ts) | TypeScript | TS Model & utils for OpenAPI 3.0.x contracts |
15+
| swagger2openapi | [GitHub/mermade/swagger2openapi](https://github.com/mermade/swagger2openapi) | Node.js | An OpenAPI / Swagger 2.0 to OpenAPI 3.0.x converter and validator |
16+
| Tavis.OpenApi | [GitHub/tavis-sofware/Tavis.OpenApi](https://github.com/tavis-software/Tavis.OpenApi/) | dotnet | C# based parser with definition validation and migration support from V2 |
17+
| odata-openapi | [GitHub/oasis-tcs/odata-openapi](https://github.com/oasis-tcs/odata-openapi) | XSLT | OData 4.0 to OpenAPI 3.0.0 converter |
18+
19+
20+
#### Editors
21+
22+
| Title | Project Link | Language |Description |
23+
|----------------|--------------|----------|---------------------|
24+
| KaiZen OpenAPI Editor | [GitHub/RepreZen/KaiZen-OpenAPI-Editor](https://github.com/RepreZen/KaiZen-OpenAPI-Editor) | Java | Eclipse Editor for OpenAPI 2.0 and 3.0 |
25+
| RepreZen API Studio | [RepreZen.com/OpenAPI](https://www.reprezen.com/OpenAPI) | Java | Commercial desktop IDE for API design, documentation & development |
26+
| OpenApi-gui | [GitHub/Mermade/openapi-gui](https://github.com/Mermade/openapi-gui) | Node.js | GUI / visual editor for creating and editing OpenApi / Swagger definitions |
27+
| swagger-editor | [GitHub/swagger-api](https://github.com/swagger-api/swagger-editor) | JavaScript | Web-Based editor for creating, editing, validating and testing OpenAPI\Swagger definitions |
28+
29+
#### User Interfaces
30+
31+
| Title | Project Link | Language |Description |
32+
|----------------|--------------|----------|---------------------|
33+
| openapi-viewer | [GitHub/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification. |
34+
| swagger-ui | [GitHub/swagger-api](https://github.com/swagger-api/swagger-UI) | JavaScript | Web-Based interface for visualizing and testing OpenAPI\Swagger definitions |
35+
| lincoln | [GitHub/temando/open-api-renderer](https://github.com/temando/open-api-renderer)| React.js| A React renderer for Open API v3 |
36+
37+
38+
#### Server Implementations
39+
40+
41+
#### Code Generators
42+
43+
| Title | Project Link | Language |Description |
44+
|----------------|--------------|----------|---------------------|
45+
| baucis-openapi3 | [Github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts. |
46+
| Google Gnostic | [GitHub/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations. |
47+
| serverless-openapi-documentation | [GitHub/temando/serverless-openapi-documentation](https://github.com/temando/serverless-openapi-documentation) | Typescript | Serverless 1.0 plugin to generate OpenAPI V3 documentation from serverless configuration |

LICENSE

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
Copyright 2016 The Linux Foundation
1+
Copyright 2017 The Linux Foundation
22

33
Licensed under the Apache License, Version 2.0 (the "License");
44
you may not use this file except in compliance with the License.

README.md

+33-37
Original file line numberDiff line numberDiff line change
@@ -1,68 +1,64 @@
1-
# The OpenAPI Specification (fka The Swagger Specification)
1+
# The OpenAPI Specification
22

33
[![Build Status](https://travis-ci.org/OAI/OpenAPI-Specification.svg?branch=master)](https://travis-ci.org/OAI/OpenAPI-Specification)
44

55
![](https://avatars3.githubusercontent.com/u/16343502?v=3&s=200)
66

7-
**The OAS 3.0.0-RC0 Spec can be [found here](https://github.com/OAI/OpenAPI-Specification/blob/3.0.0-rc0/versions/3.0.md)**
7+
The OpenAPI Specification is a community driven, open specification within the [Open API Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
88

9-
The goal of The OpenAPI Specification is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, 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 interfaces have done for lower-level programming, OpenAPI removes the guesswork in calling the service.
9+
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.
1010

11-
Use cases for machine-readable API interfaces include interactive documentation, code generation for documentation, client, and server, as well as automated test cases. OpenAPI-enabled APIs expose JSON files that correctly adhere to the OpenAPI Specification, documented in this repository. These files can either be produced and served statically, or be generated dynamically from your application.
11+
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.
1212

13-
Without going into a long history of interfaces to Web Services, this is not the first attempt to do so. We can learn from CORBA, WSDL and WADL. These specifications had good intentions but were limited by proprietary vendor-specific implementations, being bound to a specific programming language, and goals which were too open-ended. In the end, they failed to gain traction.
14-
15-
OpenAPI 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-ful API. OpenAPI 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.
13+
The OpenAPI Specification does not require rewriting existing APIs. It does not require binding any software to a service—the 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 OpenAPI—this 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.
1614

1715
This GitHub project is the starting point for OpenAPI.
18-
Here you will find the information you need about the OpenAPI Specification, a simple static sample of what it looks like,
19-
and some general information regarding the project.
16+
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.
2017

18+
## Current Version - 3.0
2119

22-
## Current Version - 2.0
20+
The current version of the OpenAPI specification is [OpenAPI Specification 3.0](versions/3.0.0.md).
2321

24-
The current version of the OpenAPI specification is 2.0 - and you can find it [here](versions/2.0.md).
22+
### Future Versions
2523

26-
### [OpenAPI 2.0 Specification](versions/2.0.md)
24+
[3.0.1](https://github.com/OAI/OpenAPI-Specification/tree/v3.0.1) - The next PATCH version. Patch-level fixes (typos, clarifications, etc.) should be submitted against this branch.
2725

28-
This repository contains the existing Swagger 1.2, 2.0 specifications as well as proposals for the next version of the specification, which will be called the OpenAPI Specification 3.0. The proposals live in the [OpenAPI.next](https://github.com/OAI/OpenAPI-Specification/tree/OpenAPI.next) branch.
26+
### Previous Versions
2927

30-
## Structure
28+
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”,
29+
as well as the Swagger 1.2 and Swagger 2.0 specifications.
3130

32-
Each section should contain v1.2 and v2.0 folders to avoid confusion between the versions.
31+
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.
3332

34-
Please keep in mind that the other projects under OpenAPI use an independent version system.
35-
As such, don't confuse the version of the OpenAPI Specification they support and the version of that given library.
33+
## See It in Action
3634

37-
## The Wiki
35+
If you just want to see it work, check out the [list of current examples](examples/v3.0).
3836

39-
Check out the [wiki](https://github.com/OAI/OpenAPI-Specification/wiki) for additional and relevant information about the project.
37+
## Tools and Libraries
4038

41-
This includes:
42-
- Static sample tutorial.
43-
- List of known deployments.
44-
- Revision history.
39+
Looking to see how you can create your own OpenAPI definition, present it, or otherwise use it? Check out the growing
40+
[list of 3.0 Implementations](IMPLEMENTATIONS.md).
4541

46-
## See it in Action
42+
## Participation
4743

48-
If you just want to see it work, check out the [pet store sample](http://petstore.swagger.io/).
44+
The current process for development of the OpenAPI Specification is described in
45+
[Development Guidelines](DEVELOPMENT.md).
46+
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.
4947

50-
## Tools and Libraries
48+
The Open API Initiative encourages participation from individuals and companies alike.
49+
If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions:
5150

52-
Looking to see how you can create your own OpenAPI definition, present it or otherwise use it? Check out our [list of tools](http://swagger.io/open-source-integrations/) over at [http://swagger.io](http://swagger.io/open-source-integrations/).
51+
* Review the [current specification](versions/3.0.0.md). The human-readable markdown file _is the source of truth_ for the specification.
52+
* Review the [development](DEVELOPMENT.md) process so you understand how the spec is evolving.
53+
* Check the [issues](https://github.com/OAI/OpenAPI-Specification/issues) and [pull requests](https://github.com/OAI/OpenAPI-Specification/pulls) to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by adding a comment to the existing issue or PR.
54+
* Create an issue to describe a new concern. If possible, propose a solution.
5355

54-
(Yes, there used to be a really long list here, we just moved it to the main website)
56+
Not all feedback can be accommodated and there may be solid arguments for or against a change being appropriate for the specification.
5557

5658
## License
5759

58-
Copyright 2016 The Linux Foundation
5960

60-
Licensed under the Apache License, Version 2.0 (the "License");
61-
you may not use this file except in compliance with the License.
62-
You may obtain a copy of the License at [apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0)
61+
See: [License (Apache-2.0)](https://github.com/OAI/OpenAPI-Specification/blob/master/LICENSE)
62+
6363

64-
Unless required by applicable law or agreed to in writing, software
65-
distributed under the License is distributed on an "AS IS" BASIS,
66-
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
67-
See the License for the specific language governing permissions and
68-
limitations under the License.
64+
![Analytics](https://ga-beacon.appspot.com/UA-831873-42/readme.md?pixel)

0 commit comments

Comments
 (0)