Oh, it wasn’t in that github issue itself - it was in the comment here that led me to that issue! Links Object Clarification Needed
If we understand the spec correctly, this means “self” and “related” are
the only links we can specify.
Right now, yes, that’s correct.
I’m not sure if the spec has changed since then, but the issue linked to in that thread is still open. And there doesn’t seem to be any positive language in the current spec that suggests links objects are extendable with additional members. The spec does say this:
Note: Additional members may be specified for links objects and link objects in the future. It is also possible that the allowed values of additional members will be expanded (e.g. a
collectionlink may support an array of values, whereas aselflink does not).
This doesn’t suggest APIs are free to add their own links; but it does suggest you should take care if you do choose to do so, in case your custom links should conflict with future additions to the spec.
The 1.1 spec goes into much more detail about what “link objects” (distinct from the “links object”) may contain, but I still don’t see any language that counters the overarching
Unless otherwise noted, objects defined by this specification MUST NOT contain any additional members. Client and server implementations MUST ignore members not recognized by this specification.