Add support for webhooks as a top-level element (#2103)

* Add webhooks as a top-level element to the spec

* Add the changes from #2048 and signpost webhooks

* Add an example of webhooks

* Relocate and expand on webhooks section following feedback

* Better wording to describe expectations on API consumers

* Clearer wording for why the paths element is here

* Update language to make callbacks clearer

examples/v3.1/webhook-example.yaml

@@ -0,0 +1,61 @@
+openapi: 3.1.0
+info:
+  title: Webhook Example
+  version: 1.0.0
+paths:
+  # OpenAPI documents all need a paths element
+  /pets:
+    get:
+      summary: List all pets
+      operationId: listPets
+      parameters:
+        - name: limit
+          in: query
+          description: How many items to return at one time (max 100)
+          required: false
+          schema:
+            type: integer
+            format: int32
+      responses:
+        '200':
+          description: A paged array of pets
+          content:
+            application/json:    
+              schema:
+                $ref: "#/components/schemas/Pets"
+
+webhooks:
+  # Each webhook needs a name
+  newPet:
+    # This is a Path Item Object, the only difference is that the request is initiated by the API provider
+    post:
+      requestBody:
+        description: Information about a new pet in the system
+        content:
+          application/json:
+            schema:
+              $ref: "#/components/schemas/Pet"
+      responses:
+        "200":
+          description: Return a 200 status to indicate that the data was received successfully
+
+components:
+  schemas:
+    Pet:
+      required:
+        - id
+        - name
+      properties:
+        id:
+          type: integer
+          format: int64
+        name:
+          type: string
+        tag:
+          type: string
+    Pets:
+      type: array
+      items:
+        $ref: "#/components/schemas/Pet"
+
+

versions/3.1.0.md

@@ -193,11 +193,13 @@ Field Name | Type | Description
 <a name="oasInfo"></a>info | [Info Object](#infoObject) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required.
 <a name="oasServers"></a>servers | [[Server Object](#serverObject)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` property is not provided, or is an empty array, the default value would be a [Server Object](#serverObject) with a [url](#serverUrl) value of `/`.
 <a name="oasPaths"></a>paths | [Paths Object](#pathsObject) | **REQUIRED**. The available paths and operations for the API.
+<a name="oasWebhooks"></a>webhooks | Map[`string`, [Path Item Object](#pathItemObject)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](../examples/v3.1/webhook-example.yaml) is available.
 <a name="oasComponents"></a>components | [Components Object](#componentsObject) | An element to hold various schemas for the specification.
 <a name="oasSecurity"></a>security | [[Security Requirement Object](#securityRequirementObject)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. Individual operations can override this definition.
 <a name="oasTags"></a>tags | [[Tag Object](#tagObject)] | A list of tags used by the specification with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operationObject) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique.
 <a name="oasExternalDocs"></a>externalDocs | [External Documentation Object](#externalDocumentationObject) | Additional external documentation.
 
+
 This object MAY be extended with [Specification Extensions](#specificationExtensions).
 
 #### <a name="infoObject"></a>Info Object
@@ -1844,6 +1846,8 @@ A map of possible out-of band callbacks related to the parent operation.
 Each value in the map is a [Path Item Object](#pathItemObject) that describes a set of requests that may be initiated by the API provider and the expected responses.
 The key value used to identify the callback object is an expression, evaluated at runtime, that identifies a URL to use for the callback operation.
 
+To describe incoming requests from the API provider independent from another API call, use the [`webhooks`](#oasWebhooks) field.
+
 ##### Patterned Fields
 Field Pattern | Type | Description
 ---|:---:|---
@@ -1893,25 +1897,41 @@ $request.body#/successUrls/2 | https://clientdomain.com/medium
 $response.header.Location | https://example.org/subscription/1
 
 
-##### Callback Object Example
+##### Callback Object Examples
 
-The following example shows a callback to the URL specified by the `id` and `email` property in the request body.
+The following example uses the user provided `queryUrl` query string parameter to define the callback URL. This is an example of how to use a callback object to describe a callback that goes with the subscription operation to enable registering for the callback.
 
 ```yaml
-myWebhook:
-  'https://notificationServer.com?transactionId={$request.body#/id}&email={$request.body#/email}':
+myCallback:
+  '{$request.query.queryUrl}':
     post:
       requestBody:
         description: Callback payload
-        content: 
+        content:
           'application/json':
             schema:
               $ref: '#/components/schemas/SomePayload'
       responses:
         '200':
-          description: webhook successfully processed and no retries will be performed
+          description: callback successfully processed
 ```
 
+The following example shows a callback where the server is hard-coded, but the query string parameters are populated from the `id` and `email` property in the request body.
+
+```yaml
+transactionCallback:
+  'http://notificationServer.com?transactionId={$request.body#/id}&email={$request.body#/email}':
+    post:
+      requestBody:
+        description: Callback payload
+        content:
+          'application/json':
+            schema:
+              $ref: '#/components/schemas/SomePayload'
+      responses:
+        '200':
+          description: callback successfully processed
+```
 
 #### <a name="exampleObject"></a>Example Object