Skip to content

Commit

Permalink
Add support for webhooks as a top-level element (OAI#2103)
Browse files Browse the repository at this point in the history
* Add webhooks as a top-level element to the spec

* Add the changes from OAI#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
  • Loading branch information
lornajane authored and darrelmiller committed Jan 16, 2020
1 parent e3c236a commit 61f9d7e
Show file tree
Hide file tree
Showing 2 changed files with 87 additions and 6 deletions.
61 changes: 61 additions & 0 deletions examples/v3.1/webhook-example.yaml
Original file line number Diff line number Diff line change
@@ -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"


32 changes: 26 additions & 6 deletions versions/3.1.0.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
---|:---:|---
Expand Down Expand Up @@ -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

Expand Down

0 comments on commit 61f9d7e

Please sign in to comment.