Merge branch 'master' of github.com:OAI/OpenAPI-Specification

Author: philsturgeon

.github/workflows/convert-examples-to-json.yaml

@@ -0,0 +1,50 @@
+name: convert-examples-to-json
+
+# author: @MikeRalphson / @cebe
+# issue: https://github.com/OAI/OpenAPI-Specification/issues/1385
+
+#
+# This workflow updates the *.json files in the examples/v3.x directories,
+# when the corresponding *.yaml files change.
+# JSON example files are automatically generated from the YAML example files.
+# Only the YAML files should be adjusted manually.
+#
+
+# run this on push to master
+on:
+  push:
+    branches:
+      - master
+
+jobs:
+  yaml2json:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1 # checkout repo content
+
+    - name: Install dependencies
+      run: npm i
+
+    - name: convert YAML examples to JSON
+      run: find examples/v3* -type f -name "*.yaml" | xargs node scripts/yaml2json/yaml2json.js
+
+    - name: git diff
+      run: |
+        git add examples/**/*.json
+        git --no-pager -c color.diff=always diff --staged
+
+    - name: Create Pull Request
+      uses: peter-evans/create-pull-request@v1
+      with:
+        token: ${{ secrets.GITHUB_TOKEN }}
+        branch-suffix: none
+        branch: update-json-examples
+        title: Update JSON example files
+        commit-message: Update JSON example files
+        body: |
+          This pull request is automatically triggered by GitHub action `convert-examples-to-json`.
+
+          The examples/v3.* YAML files have changed, so the JSON files are automatically being recreated.
+

.gitignore

@@ -5,4 +5,5 @@
 target
 atlassian-ide-plugin.xml
 node_modules/
+package-lock.json
 Gemfile.lock

CODE_OF_CONDUCT.md

@@ -0,0 +1,118 @@
+Code of Conduct
+===============
+
+OpenAPI Initiative Code of Conduct
+
+*The Linux Foundation*
+
+*Effective November 24, 2020*
+
+The OpenAPI Initiative (OAI) is an open source Linux Foundation project
+and home of the OpenAPI Specification (OAS) released under the Apache
+2.0 license. As contributors, maintainers, and participants in this
+project, we want to foster an open and welcoming environment. We pledge
+to make participation in our project and our community a harassment-free
+experience for everyone, regardless of age, body size, disability,
+ethnicity, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance,
+race, religion, or sexual identity and orientation.
+
+Our Standards
+-------------
+
+Examples of behaviors that contribute to creating a positive environment
+include:
+
+-   Using welcoming and inclusive language
+
+-   Being respectful of differing viewpoints and experiences
+
+-   Gracefully accepting constructive criticism
+
+-   Focusing on what is best for the community
+
+-   Showing empathy towards other community members
+
+-   Assuming the best intent from others
+
+Examples of unacceptable behavior by participants include:
+
+-   The use of sexualized language or imagery and unwelcome sexual attention or advances
+
+-   Making unsolicited, insulting or derogatory comments, including personal (i.e., ad hominem) or political attacks to create conflict (e.g., trolling)
+
+-   Public or private harassment
+
+-   Publishing others' private information, such as a physical or electronic address, without explicit permission (e.g., doxxing)
+
+-   Threatening, offensive, harmful comments, or behavior
+
+-   Other conduct which could reasonably be considered inappropriate in a professional setting
+
+Our Responsibilities
+--------------------
+
+The Code of Conduct Committee is responsible for clarifying the
+standards of acceptable behavior and is expected to take appropriate and
+fair corrective action in response to any instances of unacceptable
+behavior.
+
+Scope
+-----
+
+This Code of Conduct applies to OAI project spaces, as well as
+interactions in public spaces. Project spaces include, but are not
+limited to, official OAI code repositories, Slack, mailing lists,
+meetings, and events. Public spaces may include venues where an
+individual is representing the project or its community. Examples of
+this include a community member's email communication, forum posts,
+social media activity, or acting as a representative at an online or
+offline event. In addition, violations of this code of conduct outside
+of these spaces may affect a person's ability to participate in them.
+
+Enforcement
+-----------
+
+To report instances of abuse, harassment, or otherwise unacceptable
+behavior, contact
+[conduct\@openapis.org](mailto:[email protected]). **We
+are committed to maintaining the confidentiality of anyone reporting an
+incident**. The Code of Conduct Committee will review and investigate
+all complaints, responding as deemed necessary and appropriate to the
+circumstances. For incidents relating to offline events, we aim to
+respond to reports within 24 hours, and for incidents relating to online
+activities, we aim to respond to reports within 7 days.
+
+The Code of Conduct Committee has the right and responsibility to
+remove, edit, or reject comments, commits, code, wiki edits, issues, and
+other contributions that are not aligned to this Code of Conduct, or
+take other appropriate action as deemed necessary for behaviors contrary
+to the standards listed above. In the case of offline or in-person
+events, if a participant engages in behavior that is not aligned to this
+Code of Conduct, the committee may take action, such as warning the
+offender, banning the offender from various online spaces (temporary or
+permanent), removing the offender from an event with no refund, or other
+options deemed appropriate.
+
+Further details of specific enforcement policies are currently being
+drafted. When these details are completed we will post updates to our
+website for transparency.
+
+Project maintainers who do not report possible incidents or follow
+responses in good faith may face temporary or permanent repercussions as
+determined by the Code of Conduct Committee.
+
+### Events
+
+Some OpenAPI events are governed by the [Linux Foundation Code of
+Conduct](https://events.linuxfoundation.org/about/code-of-conduct/)
+(E.g. API Specifications Conference) and will be listed on the event
+page. The OAI Code of Conduct is designed to be compatible with the
+above policy and also includes more details on responding to incidents.
+
+### Attribution
+
+This code of conduct is adapted from the [Contributor Covenant, version
+1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct)
+and the [PyCon 2019 Code of
+Conduct](https://us.pycon.org/2019/about/code-of-conduct/).

README.md

@@ -1,41 +1,38 @@
 # The OpenAPI Specification
 
-[![Build Status](https://travis-ci.org/OAI/OpenAPI-Specification.svg?branch=master)](https://travis-ci.org/OAI/OpenAPI-Specification)
+![Build Status](https://github.com/OAI/OpenAPI-Specification/workflows/validate-markdown/badge.svg)
 
 ![](https://avatars3.githubusercontent.com/u/16343502?v=3&s=200)
 
+
 The OpenAPI Specification is a community-driven open specification within the [OpenAPI Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
 
-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.
+The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP 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.
 
-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.
+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 APIs 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.
 
-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.
+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 HTTP APIs, but does include support for [REST APIs](https://en.wikipedia.org/wiki/Representational_state_transfer). 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 HTTP API.
 
 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.
 
-## Current Version - 3.0.3
-
-The current version of the OpenAPI specification is [OpenAPI Specification 3.0.3](versions/3.0.3.md).
-
-### Future Versions
+## Current Version - 3.1.0
 
-[3.1.0](https://github.com/OAI/OpenAPI-Specification/tree/v3.1.0-dev) - The next MINOR version. Non-breaking changes should be submitted against this branch.
+The current version of the OpenAPI specification is [OpenAPI Specification 3.1.0](versions/3.1.0.md).
 
 ### Previous Versions
 
-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.
+This repository also contains all [previous versions](versions).
 
 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.
 
 ## See It in Action
 
-If you just want to see it work, check out the [list of current examples](examples/v3.0).
+If you just want to see it work, check out the [list of current examples](examples).
 
 ## Tools and Libraries
 
 Looking to see how you can create your own OpenAPI definition, present it, or otherwise use it? Check out the growing
-[list of 3.0 implementations](IMPLEMENTATIONS.md).
+[list of implementations](IMPLEMENTATIONS.md).
 
 ## Participation
 
@@ -47,7 +44,7 @@ The TSC holds weekly web conferences to review open pull requests and discuss op
 
 The OpenAPI 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:
 
-* Review the [current specification](versions/3.0.3.md). The human-readable markdown file _is the source of truth_ for the specification.
+* Review the [current specification](versions/3.1.0.md). The human-readable markdown file _is the source of truth_ for the specification.
 * Review the [development](DEVELOPMENT.md) process so you understand how the spec is evolving.
 * 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 subscribing to the existing issue or PR.
 * Create an issue to describe a new concern. If possible, propose a solution.

TOB.md

@@ -12,7 +12,7 @@ Marsh Gardiner @earth2marsh
 
 Ron Ratovsky @webron
 
-## BGB Elected - terms through May 2020
+## BGB Elected - terms through May 2022
 
 Darrel Miller @darrelmiller