Skip to content

Commit f9e313d

Browse files
webronwebron
committed
Merge branch 'master' into v3.1.0-dev
2 parents 8b97717 + f1adc84 commit f9e313d

File tree

5 files changed

+122
-68
lines changed

5 files changed

+122
-68
lines changed

‎CODE_OF_CONDUCT.md

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
Code of Conduct
2+
===============
3+
4+
OpenAPI Initiative Code of Conduct
5+
6+
*The Linux Foundation*
7+
8+
*Effective November 24, 2020*
9+
10+
The OpenAPI Initiative (OAI) is an open source Linux Foundation project
11+
and home of the OpenAPI Specification (OAS) released under the Apache
12+
2.0 license. As contributors, maintainers, and participants in this
13+
project, we want to foster an open and welcoming environment. We pledge
14+
to make participation in our project and our community a harassment-free
15+
experience for everyone, regardless of age, body size, disability,
16+
ethnicity, gender identity and expression, level of experience,
17+
education, socio-economic status, nationality, personal appearance,
18+
race, religion, or sexual identity and orientation.
19+
20+
Our Standards
21+
-------------
22+
23+
Examples of behaviors that contribute to creating a positive environment
24+
include:
25+
26+
- Using welcoming and inclusive language
27+
28+
- Being respectful of differing viewpoints and experiences
29+
30+
- Gracefully accepting constructive criticism
31+
32+
- Focusing on what is best for the community
33+
34+
- Showing empathy towards other community members
35+
36+
- Assuming the best intent from others
37+
38+
Examples of unacceptable behavior by participants include:
39+
40+
- The use of sexualized language or imagery and unwelcome sexual attention or advances
41+
42+
- Making unsolicited, insulting or derogatory comments, including personal (i.e., ad hominem) or political attacks to create conflict (e.g., trolling)
43+
44+
- Public or private harassment
45+
46+
- Publishing others' private information, such as a physical or electronic address, without explicit permission (e.g., doxxing)
47+
48+
- Threatening, offensive, harmful comments, or behavior
49+
50+
- Other conduct which could reasonably be considered inappropriate in a professional setting
51+
52+
Our Responsibilities
53+
--------------------
54+
55+
The Code of Conduct Committee is responsible for clarifying the
56+
standards of acceptable behavior and is expected to take appropriate and
57+
fair corrective action in response to any instances of unacceptable
58+
behavior.
59+
60+
Scope
61+
-----
62+
63+
This Code of Conduct applies to OAI project spaces, as well as
64+
interactions in public spaces. Project spaces include, but are not
65+
limited to, official OAI code repositories, Slack, mailing lists,
66+
meetings, and events. Public spaces may include venues where an
67+
individual is representing the project or its community. Examples of
68+
this include a community member's email communication, forum posts,
69+
social media activity, or acting as a representative at an online or
70+
offline event. In addition, violations of this code of conduct outside
71+
of these spaces may affect a person's ability to participate in them.
72+
73+
Enforcement
74+
-----------
75+
76+
To report instances of abuse, harassment, or otherwise unacceptable
77+
behavior, contact
78+
[conduct\@openapis.org](mailto:[email protected]). **We
79+
are committed to maintaining the confidentiality of anyone reporting an
80+
incident**. The Code of Conduct Committee will review and investigate
81+
all complaints, responding as deemed necessary and appropriate to the
82+
circumstances. For incidents relating to offline events, we aim to
83+
respond to reports within 24 hours, and for incidents relating to online
84+
activities, we aim to respond to reports within 7 days.
85+
86+
The Code of Conduct Committee has the right and responsibility to
87+
remove, edit, or reject comments, commits, code, wiki edits, issues, and
88+
other contributions that are not aligned to this Code of Conduct, or
89+
take other appropriate action as deemed necessary for behaviors contrary
90+
to the standards listed above. In the case of offline or in-person
91+
events, if a participant engages in behavior that is not aligned to this
92+
Code of Conduct, the committee may take action, such as warning the
93+
offender, banning the offender from various online spaces (temporary or
94+
permanent), removing the offender from an event with no refund, or other
95+
options deemed appropriate.
96+
97+
Further details of specific enforcement policies are currently being
98+
drafted. When these details are completed we will post updates to our
99+
website for transparency.
100+
101+
Project maintainers who do not report possible incidents or follow
102+
responses in good faith may face temporary or permanent repercussions as
103+
determined by the Code of Conduct Committee.
104+
105+
### Events
106+
107+
Some OpenAPI events are governed by the [Linux Foundation Code of
108+
Conduct](https://events.linuxfoundation.org/about/code-of-conduct/)
109+
(E.g. API Specifications Conference) and will be listed on the event
110+
page. The OAI Code of Conduct is designed to be compatible with the
111+
above policy and also includes more details on responding to incidents.
112+
113+
### Attribution
114+
115+
This code of conduct is adapted from the [Contributor Covenant, version
116+
1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct)
117+
and the [PyCon 2019 Code of
118+
Conduct](https://us.pycon.org/2019/about/code-of-conduct/).

‎README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ The OpenAPI Specification (OAS) defines a standard, programming language-agnosti
1111

1212
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.
1313

14-
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.
14+
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.
1515

1616
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.
1717

‎examples/v3.1/webhook-example.json

Lines changed: 0 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -4,38 +4,6 @@
44
"title": "Webhook Example",
55
"version": "1.0.0"
66
},
7-
"paths": {
8-
"/pets": {
9-
"get": {
10-
"summary": "List all pets",
11-
"operationId": "listPets",
12-
"parameters": [
13-
{
14-
"name": "limit",
15-
"in": "query",
16-
"description": "How many items to return at one time (max 100)",
17-
"required": false,
18-
"schema": {
19-
"type": "integer",
20-
"format": "int32"
21-
}
22-
}
23-
],
24-
"responses": {
25-
"200": {
26-
"description": "A paged array of pets",
27-
"content": {
28-
"application/json": {
29-
"schema": {
30-
"$ref": "#/components/schemas/Pets"
31-
}
32-
}
33-
}
34-
}
35-
}
36-
}
37-
}
38-
},
397
"webhooks": {
408
"newPet": {
419
"post": {
@@ -76,12 +44,6 @@
7644
"type": "string"
7745
}
7846
}
79-
},
80-
"Pets": {
81-
"type": "array",
82-
"items": {
83-
"$ref": "#/components/schemas/Pet"
84-
}
8547
}
8648
}
8749
}

‎examples/v3.1/webhook-example.yaml

Lines changed: 1 addition & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -2,28 +2,7 @@ openapi: 3.1.0
22
info:
33
title: Webhook Example
44
version: 1.0.0
5-
paths:
6-
# OpenAPI documents all need a paths element
7-
/pets:
8-
get:
9-
summary: List all pets
10-
operationId: listPets
11-
parameters:
12-
- name: limit
13-
in: query
14-
description: How many items to return at one time (max 100)
15-
required: false
16-
schema:
17-
type: integer
18-
format: int32
19-
responses:
20-
'200':
21-
description: A paged array of pets
22-
content:
23-
application/json:
24-
schema:
25-
$ref: "#/components/schemas/Pets"
26-
5+
# Since OAS 3.1.0 the paths element isn't necessary. Now a valid OpenAPI Document can describe only paths, webhooks, or even only reusable components
276
webhooks:
287
# Each webhook needs a name
298
newPet:
@@ -53,9 +32,4 @@ components:
5332
type: string
5433
tag:
5534
type: string
56-
Pets:
57-
type: array
58-
items:
59-
$ref: "#/components/schemas/Pet"
60-
6135

‎versions/3.1.0.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1549,7 +1549,7 @@ It is common to use `multipart/form-data` as a `Content-Type` when transferring
15491549

15501550
In a `multipart/form-data` request body, each schema property, or each element of a schema array property, takes a section in the payload with an internal header as defined by [RFC7578](https://tools.ietf.org/html/rfc7578). The serialization strategy for each property of a `multipart/form-data` request body can be specified in an associated [`Encoding Object`](#encodingObject).
15511551

1552-
When passing in `multipart` types, boundaries MAY be used to separate sections of the content being transferred — thus, the following default `Content-Type`s are defined for `multipart`:
1552+
When passing in `multipart` types, boundaries MAY be used to separate sections of the content being transferred — thus, the following default `Content-Type`s are defined for `multipart`:
15531553

15541554
* If the property is a primitive, or an array of primitive values, the default Content-Type is `text/plain`
15551555
* If the property is complex, or an array of complex values, the default Content-Type is `application/json`
@@ -1600,7 +1600,7 @@ A single encoding definition applied to a single schema property.
16001600
##### Fixed Fields
16011601
Field Name | Type | Description
16021602
---|:---:|---
1603-
<a name="encodingContentType"></a>contentType | `string` | The Content-Type for encoding a specific property. Default value depends on the property type: for `object` - `application/json`; for `array` – the default is defined based on the inner type; for all other cases the default is `application/octet-stream`. The value can be a specific media type (e.g. `application/json`), a wildcard media type (e.g. `image/*`), or a comma-separated list of the two types.
1603+
<a name="encodingContentType"></a>contentType | `string` | The Content-Type for encoding a specific property. Default value depends on the property type: for `object` - `application/json`; for `array` – the default is defined based on the inner type; for all other cases the default is `application/octet-stream`. The value can be a specific media type (e.g. `application/json`), a wildcard media type (e.g. `image/*`), or a comma-separated list of the two types.
16041604
<a name="encodingHeaders"></a>headers | Map[`string`, [Header Object](#headerObject) \| [Reference Object](#referenceObject)] | A map allowing additional information to be provided as headers, for example `Content-Disposition`. `Content-Type` is described separately and SHALL be ignored in this section. This property SHALL be ignored if the request body media type is not a `multipart`.
16051605
<a name="encodingStyle"></a>style | `string` | Describes how a specific property value will be serialized depending on its type. See [Parameter Object](#parameterObject) for details on the [`style`](#parameterStyle) property. The behavior follows the same values as `query` parameters, including default values. This property SHALL be ignored if the request body media type is not `application/x-www-form-urlencoded` or `multipart/form-data`. If a value is explicitly defined, then the value of [`contentType`](#encodingContentType) (implicit or explicit) SHALL be ignored.
16061606
<a name="encodingExplode"></a>explode | `boolean` | When this is true, property values of type `array` or `object` generate separate parameters for each value of the array, or key-value-pair of the map. For other types of properties this property has no effect. When [`style`](#encodingStyle) is `form`, the default value is `true`. For all other styles, the default value is `false`. This property SHALL be ignored if the request body media type is not `application/x-www-form-urlencoded` or `multipart/form-data`. If a value is explicitly defined, then the value of [`contentType`](#encodingContentType) (implicit or explicit) SHALL be ignored.

0 commit comments

Comments
 (0)