Skip to content

v3.2: Add support for application/linkset[+json] #4740

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 2 commits into from
Jul 16, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions src/oas.md
Original file line number Diff line number Diff line change
Expand Up @@ -2451,6 +2451,67 @@ Using `content` with a `text/plain` media type is RECOMMENDED for headers where
| ---- | :----: | ---- |
| <a name="header-content"></a>content | Map[`string`, [Media Type Object](#media-type-object)] | A map containing the representations for the header. The key is the media type and the value describes it. The map MUST only contain one entry. |

##### Modeling Link Headers

[[!RFC9264]] defines the `application/linkset` and `application/linkset+json` media types.
The former is exactly the format of HTTP link header values except allowing additional whitespace for readability, while the latter is an equivalent JSON representation of such headers.

To use either of these media types, the `schema` in the [Media Type Object](#media-type-object) MUST describe the links as they would be structured in the `application/linkset+json` format.
If the Media Type Object's parent key is `application/linkset+json`, then the serialization is trivial, however this format cannot be used in the HTTP `Link` header.
If the Media Type Object's parent key is `application/linkset`, then the serialization MUST be the equivalent representation of the `schema`-modeled links in the `application/linkset` format.
If the `application/linkset` Media Type Object is used in the `content` field of a Header Object (or a Parameter Object with `in: "header"`), the serialization MUST be made compatible with the HTTP field syntax as described by [[!RFC9264]] [Section 4.1](https://www.rfc-editor.org/rfc/rfc9264.html#name-http-link-document-format-a).

The following example shows how the same data model can be used for a collection pagination linkset either in JSON format as message content, or in the HTTP `Link` header:

```yaml
components:
schemas:
SimpleLinkContext:
type: array
items:
type: object
required:
- href
properties:
href:
type: string
format: uri-reference
CollectionLinks:
type: object
required:
- linkset
properties:
linkset:
type: array
items:
type: object
required: [first, prev, next, last]
properties:
anchor:
type: string
format: uri
additionalProperties:
$ref: '#/components/schemas/SimpleLinkContext'
responses:
CollectionWithLinks:
content:
application/json:
schema:
type: array
headers:
Link:
required: true
content:
application/linkset:
schema:
$ref: '#/components/schemas/CollectionLinks'
StandaloneJsonLinkset:
content:
application/linkset+json:
schema:
$ref: '#/components/mediaTypes/CollectionLinks'
```

##### Header Object Example

A simple header of type `integer`:
Expand Down Expand Up @@ -4293,6 +4354,7 @@ This will expand to the result:

[RFC6570](https://www.rfc-editor.org/rfc/rfc6570)'s percent-encoding behavior is not always appropriate for `in: "header"` and `in: "cookie"` parameters.
In many cases, it is more appropriate to use `content` with a media type such as `text/plain` and require the application to assemble the correct string.
Other media types, such as `application/linkset` (see [Modeling Link Headers](#modeling-link-headers)), are directly suitable for use as `content` for specific headers.

In some cases, setting `allowReserved: true` will be sufficient to avoid incorrect encoding, however many characters are still percent-encoded with this field enabled, so care must be taken to ensure no unexpected percent-encoding will take place.

Expand Down