-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
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? |
Co-authored-by: Lorna Jane Mitchell <[email protected]>
I like the concept here and support adding this feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
@darrelmiller Do you like it enough to approve this PR? 😎 |
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 in a Media Type Ojbect. RFC9264 already defines the mapping between the JSON data model, the standalone HTTP-like format, and the actual HTTP
Link
header 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
, andpattern
and 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.