You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 1, 2021. It is now read-only.
Copy file name to clipboardExpand all lines: versions/3.0.md
+37-37Lines changed: 37 additions & 37 deletions
Original file line number
Diff line number
Diff line change
@@ -1868,11 +1868,11 @@ The `Link Object` is responsible for defining a possible operation based on a si
1868
1868
Field Name | Type | Description
1869
1869
---|:---:|---
1870
1870
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
1871
-
operationId | `string` | the name of an _existing_, resolvable OAS operation, as defined with a unique `operationId`. This field is mutually exclusive with the `href` field. Relative `href` values MAY be used to locate an existing [Operation Object](#operationObject) in the OAS.
1872
-
parameters | [Link Parameters Object](#linkParametersObject) | an object representing parameters to pass to an operation as specified with `operationId` or identified via `href`.
1873
-
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.
1874
-
description | `string` | a description of the link, supports [CommonMark syntax](http://spec.commonmark.org/).
1875
-
server | [Server Object](#serverObject) | a server object to be used by the target operation
1871
+
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.
1872
+
parameters | [Link Parameters Object](#linkParametersObject) | an object representing parameters to pass to an operation as specified with `operationId` or identified via `operationRef`.
1873
+
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.
1874
+
description | `string` | a description of the link, supports [CommonMark syntax](http://spec.commonmark.org/).
1875
+
server | [Server Object](#serverObject) | a server object to be used by the target operation
1876
1876
1877
1877
This object can be extended with [Specification Extensions](#specificationExtensions).
1878
1878
@@ -1883,9 +1883,11 @@ method for specifications with external references.
Payload values are only available in parsable response payloads which match the advertised media type and for media types that can be referenced using a JSON Pointer fragment Id.
1887
-
In all cases, if a value does _not_ exist, the parameter will be considered a `null` value (as opposed to an empty value) and _not_ passed as a parameter to the linked resource.
1888
-
In cases where a value is required, and a parameter is not supplied, the client MAY choose to not follow the link definition.
1886
+
Payload values are only available in parsable response payloads which match the advertised media
1887
+
type and for media types that can be referenced using a JSON Pointer fragment Id. In all cases,
1888
+
if a value does _not_ exist, the parameter will be considered a `null` value (as opposed to an
1889
+
empty value) and _not_ passed as a parameter to the linked resource. In cases where a value is
1890
+
required, and a parameter is not supplied, the client MAY choose to not follow the link definition.
1889
1891
1890
1892
##### Example
1891
1893
@@ -1992,51 +1994,46 @@ Can be used in a link like this:
1992
1994
1993
1995
```yaml
1994
1996
Addresses:
1995
-
href: '/users/{$request.path.id}/department'
1997
+
# the target link operationId
1998
+
operationId: getUserAddress
1999
+
parameters:
2000
+
# get the `id` field from the request path parameter named `id`
2001
+
userId: '{$request.path.id}'
1996
2002
```
1997
2003
1998
2004
Where the `$request.path.id` is the value passed in the request to `/users/{id}`.
1999
-
For a `id` value of `10101110`, the generated link would be:
2000
-
2001
-
```yaml
2002
-
href: '/users/10101110/department'
2003
-
```
2004
2005
2005
2006
##### Response Payload Example
2006
2007
2007
2008
```yaml
2008
2009
Addresses:
2009
-
href: '/users/{$response.body#/uuid}/address'
2010
-
```
2011
-
2012
-
Where the `$response.uuid` from the example above would yield the target:
Would produce three links with the `colorName` of `red`, `green`, and `blue`:
2033
2026
2034
-
As with all links, it is at the clients' discretion to follow them, neither permissions nor the ability to make a successful call to that link is guaranteed solely by the existence of a relationship.
2027
+
As with all links, it is at the clients' discretion to follow them, neither
2028
+
permissions nor the ability to make a successful call to that link is guaranteed
2029
+
solely by the existence of a relationship.
2035
2030
2036
2031
2037
2032
##### Example
2038
2033
2039
-
The example below shows how relationships in the BitBucket API can be represented with the link schema. This example uses `operationId` values to link responses to possible operations.
2034
+
The example below shows how relationships in the BitBucket API can be represented
2035
+
with the link schema. This example uses `operationId` values to link responses to
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.
0 commit comments