Skip to content

Commit 06ca1cf

Browse files
committed
Refactoring variable substitution into runtime expression
1 parent a5bf8a0 commit 06ca1cf

1 file changed

Lines changed: 63 additions & 99 deletions

File tree

versions/3.0.md

Lines changed: 63 additions & 99 deletions
Original file line numberDiff line numberDiff line change
@@ -1808,7 +1808,7 @@ This object can be extended with [Specification Extensions](#specificationExtens
18081808

18091809
The key used to identify the [Path Item Object](#pathItemObject) is a variable expression that can be evaluated in the context of a runtime HTTP request/response to identify the URL to be used for the callback request.
18101810
A simple example might be `$request.body#/url`.
1811-
However, using [variable substitution](#variableSubstitution) syntax the complete HTTP message can be accessed.
1811+
However, using a [variable substitution](#runtimeExpression) syntax the complete HTTP message can be accessed.
18121812
This includes accessing any part of a body that can be accessed using a JSON Pointer [RFC6901](https://tools.ietf.org/html/rfc6901).
18131813

18141814
For example, given the following HTTP request:
@@ -1830,7 +1830,6 @@ Content-Length: 123
18301830
18311831
201 Created
18321832
Location: http://example.org/subscription/1
1833-
18341833
```
18351834

18361835
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`.
@@ -1849,12 +1848,13 @@ $response.header.Location | http://example.org/subscription/1
18491848

18501849
##### Callback Object Example
18511850

1852-
A callback to the URL specified by the `url` parameter in the request
1851+
A callback to the URL specified by the `url` property in the request body.
18531852

18541853

18551854
```yaml
18561855
myWebhook:
18571856
'$request.body#/url':
1857+
'http://notificationServer.com?transactionId={$request#/body}&email={$request.body#/email}}'
18581858
post:
18591859
requestBody:
18601860
description: Callback payload
@@ -2000,9 +2000,9 @@ schemas:
20002000
The links object represents a set of possible design-time links for a response.
20012001
The presence of a link does not guarantee the caller's ability to successfully invoke it, rather it provides a known relationship and traversal mechanism between responses and other operations.
20022002

2003-
As opposed to _dynamic_ links (links provided **in** the response payload), the OAS linking mechanism does not require that link information be provided in a specific response format at runtime.
2003+
As opposed to _dynamic_ links (i.e. links provided **in** the response payload), the OAS linking mechanism does not require that link information be provided in a specific response format at runtime.
20042004

2005-
For computing links, and providing instructions to execute them, [variable substitution](#variableSubstitution) is used for accessing values in a response and using them as values while invoking the linked operation.
2005+
For computing links, and providing instructions to execute them, a [runtime expression](#runtimeExpression) is used for accessing values in a response and using them as parameters while invoking the linked operation.
20062006

20072007
##### Patterned Fields
20082008
Field Pattern | Type | Description
@@ -2019,7 +2019,6 @@ Field Name | Type | Description
20192019
<a name="linkOperationRef"></a>operationRef | `string` | a relative or absolute reference to an OAS operation. This field is mutually exclusive with the `operationId` field, and must point to the fragment of a valid OAS definition.
20202020
<a name="linkOperationId"></a>operationId | `string` | the name of an _existing_, resolvable OAS operation, as defined with a unique `operationId`. This field is mutually exclusive with the `operationRef` field. Relative `operationRef` values MAY be used to locate an existing [Operation Object](#operationObject) in the OAS.
20212021
<a name="linkParameters"></a>parameters | [Link Parameters Object](#linkParametersObject) | an object representing parameters to pass to an operation as specified with `operationId` or identified via `operationRef`.
2022-
<a name="linkHeaders"></a>headers | [Headers Object](#headersObject) | an object representing headers to pass to the linked resource. Where conflicts occur between these headers, and those defined in the related operation, these headers override.
20232022
<a name="linkDescription"></a>description | `string` | a description of the link, supports [CommonMark syntax](http://spec.commonmark.org/).
20242023
<a name="linkServer"></a>server | [Server Object](#serverObject) | a server object to be used by the target operation.
20252024

@@ -2030,88 +2029,6 @@ In the case of an `operationId`, it MUST be unique and resolved in the scope of
20302029
Because of the potential for name clashes, consider the `operationRef` syntax as the preferred
20312030
method for specifications with external references.
20322031

2033-
##### <a name="responsePayload"></a>Response Payload Values
2034-
2035-
Payload values are only available in parsable response payloads which match the advertised media
2036-
type and for media types that can be referenced using a JSON Pointer fragment Id. In all cases,
2037-
if a value does _not_ exist, the parameter will be considered a `null` value (as opposed to an
2038-
empty value) and _not_ passed as a parameter to the linked resource. In cases where a value is
2039-
required, and a parameter is not supplied, the client MAY choose to not follow the link definition.
2040-
2041-
##### Example
2042-
2043-
Response payload:
2044-
```json
2045-
{
2046-
"id": "df71a505-07bc-458a-a5c0-73c0340d1ec7",
2047-
"firstname": "Ash",
2048-
"lastname": "Williams"
2049-
}
2050-
```
2051-
2052-
Payload Variables:
2053-
```yaml
2054-
id: df71a505-07bc-458a-a5c0-73c0340d1ec7
2055-
firstname: Ash
2056-
lastname: Williams
2057-
missingValue: null
2058-
```
2059-
2060-
In situations where variables appear in an array, an array of variables will be extracted.
2061-
For example:
2062-
2063-
```json
2064-
[
2065-
{ "color": "red" },
2066-
{ "color": "green" },
2067-
{ "color": "blue" }
2068-
]
2069-
```
2070-
2071-
will be extracted as such:
2072-
2073-
```json
2074-
color: ["red", "green", "blue"]
2075-
```
2076-
2077-
The variables generated can be used in locations prescribed by the definition.
2078-
2079-
2080-
##### <a name="variableSubstitution"></a>Variable Substitution
2081-
In all cases, _variables_ from request and responses may be substituted for link generation.
2082-
The table below provides examples of variable expressions and examples of their use in a value:
2083-
2084-
Source Location | variable expression | example reference | notes
2085-
---|:---|:---|:---
2086-
HTTP Method | `$method` | `/users/{$method}` | The allowable values for the `$method` will be those for the HTTP operation
2087-
Requested content type | `$request.header.accept` | `/users/3?format={$request.header.accept}` |
2088-
Request parameter | `$request.path.id` | `/users/{$request.path.id}` | Request parameters MUST be declared in the `parameters` section for the operation or they cannot be used in substitution. This includes request headers
2089-
Request body | `$request.body` | `/users/{$request.body#/user/uuid}` | For operations which accept payloads, references may be made to portions of the `requestBody` or the entire body itself
2090-
Request URL | `$url` | `/track?url={$url}` |
2091-
Response value | `$response.body` | `{$response.body#/uuid}` | Only the payload in the response can be accessed with the `$response` syntax.
2092-
Response header | `$response.header` | `{$response.header.Server}` | Single header values only are available
2093-
2094-
From the request, the `parameter`s used in calling the operation are made available through the `$request` syntax.
2095-
For responses, the response payload may be used with the `$response` syntax.
2096-
For both requests and responses, values will be substituted in the link in sections designated with a variable expression, surrounded by curly brackets `{}`.
2097-
2098-
The variable expression is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax
2099-
2100-
```
2101-
expression = ( "$url" | "$method" | "$request." [ source ] | "$response." [ source ])
2102-
source = ( header-reference | query-reference | path-reference | body-reference )
2103-
header-reference = "header." token
2104-
query-reference = "query." name
2105-
path-reference = "path." name
2106-
body-reference = "body#" fragment
2107-
fragment = a JSON Pointer [RFC 6901](https://tools.ietf.org/html/rfc6901)
2108-
name = *( char )
2109-
char = as per RFC [7159](https://tools.ietf.org/html/rfc7159#section-7)
2110-
token = as per RFC [7230](https://tools.ietf.org/html/rfc7230#section-3.2.6)
2111-
```
2112-
2113-
The `name` identifier is case-sensitive, whereas `token` is not.
2114-
21152032

21162033
##### Request Parameter Example
21172034
Computing a link from a request operation like this:
@@ -2147,32 +2064,30 @@ Addresses:
21472064
operationId: getUserAddress
21482065
parameters:
21492066
# get the `id` field from the request path parameter named `id`
2150-
userId: '{$request.path.id}'
2067+
userId: $request.path.id
21512068
```
21522069
21532070
Where the `$request.path.id` is the value passed in the request to `/users/{id}`.
21542071

21552072
##### Response Payload Example
21562073

21572074
```yaml
2158-
Addresses:
2075+
AddressesLink:
21592076
operationId: getUserAddressByUUID
21602077
parameters:
21612078
# get the `id` field from the request path parameter named `id`
2162-
userUuid: '{$response.body#/uuid}'
2079+
userUuid: $response.body#/uuid
21632080
```
21642081
21652082
And the array example:
21662083
21672084
```yaml
2168-
ColorSelection:
2085+
ColorSelectionLink:
21692086
operationId: getColorSample
21702087
parameters:
2171-
colorName: '{$response.body#/color}'
2088+
colorName: $response.body#/color
21722089
```
21732090
2174-
Would produce three links with the `colorName` of `red`, `green`, and `blue`:
2175-
21762091
As with all links, it is at the clients' discretion to follow them, neither
21772092
permissions nor the ability to make a successful call to that link is guaranteed
21782093
solely by the existence of a relationship.
@@ -2394,7 +2309,9 @@ components:
23942309
links:
23952310
UserRepositories:
23962311
# returns array of '#/components/schemas/repository'
2397-
operationRef: '#paths~12.0~1repositories~1{$response.body#/username}'
2312+
operationRef: '#paths~12.0~1repositories~1/{username}'
2313+
parameters:
2314+
username: $response.body#/username
23982315
```
23992316

24002317
or an absolute `operationRef`:
@@ -2404,14 +2321,15 @@ components:
24042321
links:
24052322
UserRepositories:
24062323
# returns array of '#/components/schemas/repository'
2407-
href: 'https://na2.gigantic-server.com/#/paths/~12.0~1repositories~1{$response.body#/username}'
2324+
operationRef: 'https://na2.gigantic-server.com/#/paths/~12.0~1repositories~1{username}'
2325+
parameters:
2326+
username: $response.body#/username
24082327
```
24092328

24102329
Note that in the use of `operationRef`, the _escaped forward-slash_ is necessary when
24112330
using JSON references.
24122331

24132332
#### <a name="linkParametersObject"></a>Link Parameters Object
2414-
Using the `operationId` to reference an operation in the definition has many benefits, including the ability to define media type options, security requirements, response and error payloads.
24152333
Many operations require parameters to be passed, and these MAY be dynamic depending on the response itself.
24162334

24172335
To specify parameters required by the operation, we can use a **Link Parameters Object**.
@@ -2420,7 +2338,10 @@ This object contains parameter names along with static or dynamic values:
24202338
##### Patterned Fields
24212339
Field Pattern | Type | Description
24222340
---|:---:|---
2423-
<a name="linkParameterName"></a> {name} | Any \| [{expression}](#variableSubstitution) | A constant value or expression to be evaluated and passed to the linked operation.
2341+
<a name="linkParameterName"></a> {name} | Any \| [{runtime expression}](#runtimeExpression) | A constant value or expression to be evaluated and passed to the linked operation.
2342+
2343+
When a runtime expression evaluates to null, no parameter value is passed to the target operation.
2344+
24242345

24252346
```yaml
24262347
paths:
@@ -2449,6 +2370,49 @@ components:
24492370

24502371
In the above, the link for `UserCommitHistory` points to the operation `getUserCommitHistory`, and passes the `username` value from the response payload as well as the static scalar value `0`.
24512372

2373+
##### <a name="runtimeExpression"></a>Runtime Expressions
2374+
2375+
Runtime expressions allow defining values based on information that will only available within the HTTP message in an actual API call. This mechanism is used by [Link Parameters Objects](#linkParmeterObject) and [Callback Objects](#callbackObject).
2376+
2377+
The runtime expression is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax
2378+
2379+
```
2380+
expression = ( "$url" | "$method" | "$request." [ source ] | "$response." [ source ])
2381+
source = ( header-reference | query-reference | path-reference | body-reference )
2382+
header-reference = "header." token
2383+
query-reference = "query." name
2384+
path-reference = "path." name
2385+
body-reference = "body#" fragment
2386+
fragment = a JSON Pointer [RFC 6901](https://tools.ietf.org/html/rfc6901)
2387+
name = *( char )
2388+
char = as per RFC [7159](https://tools.ietf.org/html/rfc7159#section-7)
2389+
token = as per RFC [7230](https://tools.ietf.org/html/rfc7230#section-3.2.6)
2390+
```
2391+
2392+
The `name` identifier is case-sensitive, whereas `token` is not.
2393+
2394+
The table below provides examples of runtime expressions and examples of their use in a value:
2395+
2396+
##### <a name="runtimeExpressionExamples"></a>Examples
2397+
2398+
Source Location | example expression | notes
2399+
---|:---|:---|:---
2400+
HTTP Method | `$method` | The allowable values for the `$method` will be those for the HTTP operation
2401+
Requested media type | `$request.header.accept` |
2402+
Request parameter | `$request.path.id` | Request parameters MUST be declared in the `parameters` section for the parent operation or they cannot be evaluated. This includes request headers.
2403+
Request body property | `$request.body#/user/uuid` | For operations which accept payloads, references may be made to portions of the `requestBody` or the entire body itself
2404+
Request URL | `$url` |
2405+
Response value | `$response.body#/status` | Only the payload in the response can be accessed with the `$response` syntax.
2406+
Response header | `$response.header.Server` | Single header values only are available
2407+
2408+
Runtime expressions preserve the type of the referenced value.
2409+
Expression values can be embeded into string values by surrounding the expression with `{}` curly braces.
2410+
2411+
`$request.body`and `$response.body`expressions are only available in payloads which that can be accessed using a JSON Pointer.
2412+
If a value does _not_ exist, the result of the expression will be considered a `null` value (as opposed to an empty value).
2413+
2414+
2415+
24522416
#### <a name="headerObject"></a>Header Object
24532417
24542418
The Header Object follows the structure of the [Parameter Object](#parameterObject), with the following changes:

0 commit comments

Comments
 (0)