Skip to content

Callback review and preliminary message expression syntax #891

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Feb 22, 2017
61 changes: 58 additions & 3 deletions versions/3.0.md
Original file line number Diff line number Diff line change
Expand Up @@ -1555,15 +1555,70 @@ description: object created

#### <a name="callbackObject"></a>Callback Object

A container for possible out-of band callbacks from an operation. A callback may be returned from an operation, calling back to the path specified in the operation object.
A map of possible out-of band callbacks related to the parent operation. Each value in the map is an [operation object](#operationObject) that describes a request that may be initiated by the API provider and the responses expected. The key value used to identify callback object is an expression, that when evaluated at runtime, identifies a URL to used for the callback operation.
Copy link
Contributor

@DavidBiesack DavidBiesack Feb 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add article "the" : "used to identify the callback object"

Copy link
Contributor

@DavidBiesack DavidBiesack Feb 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggested: "is an expression, evaluated at runtime, that identifies... "

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.


##### Patterned Fields
Field Pattern | Type | Description
---|:---:|---
Copy link
Contributor

@DavidBiesack DavidBiesack Feb 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe CommonMark does not support tables with this notation; one must use HTML <table> elements.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:-) I realize this might sound a little hypocritical but we are suggesting CommonMark in OpenAPI definitions, but we are still using GFM in the spec.

<a name="responseName"></a>Callback name | [Callback Operation Object](#operationObject) <span>&#124;</span> [Operation Object](#operationObject) | An operation object used to define a callback payload structure
<a name="responseName"></a>Callback name | [Callback Operation Object](#operationObject) <span>&#124;</span> [Operation Object](#operationObject) | An operation object used to define a callback request and expected responses
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name="callbackName" perhaps?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed


This object can be extended with [Specification Extensions](#specificationExtensions).

##### Key Expression

The key used to identify the callback object is also an expression that can be evaluated on the runtime HTTP request/response to identify the URL to be used for the callback request. A simple example might be "$request.body.url". However, the expression syntax enables accessing the complete HTTP message and reaching into any payload that can map to an object/array/property data model.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"evaluated in the context of a runtime HTTP request/response" (It's not clear what "evaluated on the runtime HTTP request/response object means" since those are not executable, but they do provide a context for expression evaluation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks!


The expression is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you consider using JSON Pointer or JSONPath for the body-reference expressions? In particular, when extracting elements from arrays, it is often necessary to pass in predicates/filters to match a specific array elements. (I'm extrapolating based on from experience with UnRAVL which also allows extracting data from response bodies.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had not considered using those for just the body-reference. I had ruled out using them for the complete expression, but using it for just the body-reference is quite an cool idea. I'd like to use JSON Pointer because we already need that in tooling to support $refs.

I have a fairly significant update to this PR because I found it contradicted some of the docs in Links which I am also reviewing. I'll post an update soon and I'll see if it is easy to incorporate JSONPointer. Nice thing about that is approach is in the future we could open the door to using other fragment syntaxes for other media types where JSONPointer is not appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about the predicates/filters, I do see the value but it adds quite a bit of work for tooling. I'm not going to include anything for the moment, but I'll bring it up with the TDC tomorrow.


```
expression = target source *( "." bind-token [ index ]] )
target = ("$request." | "$response.")
source = ( header-reference | query-reference | path-reference | body-reference )
header-reference = "header." token
query-reference = "query." name
path-reference = "path." name
body-reference = "body" *( index | "." name )
index = "[" *(digit) "]"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

document is indexing is zero-based (I assume, recommend) or 1-based.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move to JSONPointer, I can punt on this :-)

name = *( char )
char = as per RFC [7159](https://tools.ietf.org/html/rfc7159#section-7)
token = as per RFC [7230](https://tools.ietf.org/html/rfc7230#section-3.2.6)
```

The `name` identifier is case-sensitive, whereas `token` is not.

Given the following HTTP request:

```http
POST /subscribe/myevent?queryUrl=http://clientdomain.com/stillrunning HTTP/1.1
Host: example.org
Content-Type: application/json
Content-Length: 123

{
"failedurl" : "http://clientdomain.com/failed"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest failedUrl and successUrls (camel)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the $response.body#/id variant.

"successurls : [
"http://clientdomain.com/fast",
"http://clientdomain.com/medium",
"http://clientdomain.com/slow"
]
}

201 Created
Location: http://example.org/subscription/1

```

Here are the examples of how the various expressions evaluate, assuming a the callback operation has a path parameter named `eventType` and a query parameter named `queryUrl`.

Expression | Value
---|:---
$request.path.eventType | myevent
$request.query.queryUrl | http://clientdomain.com/stillrunning
$request.header.content-Type | application/json
$request.body.failed | http://clientdomain.com/stillrunning
$request.body.successurls[2] | http://clientdomain.com/medium
$response.header.Location | http://example.org/subscription/1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This expression notation may need some mechanism to provide a default value if the item is not found, i.e. $request.body.successurls[2] | $response.header.Location
would return the second successurl if it exists, or the location header.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Links section, the suggestion is that if the item is not found, then the value is null. I'm not exactly sure what we do if the reference points to something that is not a primitive.



##### Callback Object Example

Expand All @@ -1572,7 +1627,7 @@ A callback to the URL specified by the `url` parameter in the request

```yaml
myWebhook:
'$request.url':
'$request.body.url':
post:
body:
name: postResponse
Expand Down