v3.2: Add support for application/linkset[+json] #4740
Conversation
These media types solve our long-standing problems with modeling HTTP Link headers. We do not need to define anything beyond noting how to use them media types in a Media Type Ojbect.
|
I am always glad to see standards being useful and being adopted. And of course even more so when I played a role in creating these standards. But, @handrews, is there anything I need to actually review here other than being happy to see this happening? |
| @@ -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. | |||
There was a problem hiding this comment.
I am assuming this pulls in the reference info automatically? If not, it probably needs to be added somewhere in the references section.
There was a problem hiding this comment.
@dret yes, the [[!]] adds it to the normative references. Which I think is correct as we do that with the main multipart RFCs? Although I see I added the RFCs for application/json-seq and +json-seq to informative using [[?]]... so maybe I don't have the best grasp on which goes where.
Fixes:
These media types solve our long-standing problems with modeling HTTP Link headers. We do not need to define anything beyond noting how to use them media types in a Media Type Ojbect. RFC9264 already defines the mapping between the JSON data model, the standalone HTTP-like format, and the actual HTTP
Linkheader syntax. This fits well with our 3.2 theme of data modeling improvements.When someone hands us a standardized solution for our problem, we should improve the standards ecosystem by adopting it :-) Note that this is much more powerful and flexible than the hack I used as an example elsewhere, which required a mind-boggling combination of
anyOf,contains, andpatternand can't do much beyond checking for the link relations that way. Its also fragile due to the need to manage quoting and whitespace concerns, and the possibility of something elsewhere in a header matching a link relation type string. RFC9264 has none of these problems.