Link set profile#180
Conversation
| New resources are created using POST to a target <a>container</a> URI, with the server assigning the final identifier. Clients MAY suggest a name via the `Slug` header. Clients MAY provide initial user-managed metadata for the new resource by including one or more `Link` headers in the POST request, following the syntax of Web Linking in [[RFC8288]]. Server-managed metadata MUST be generated automatically by the server upon creation and MUST NOT be overridden by client-provided links. | ||
|
|
||
| On success, the server MUST return the 201 status code with the new URI in the `Location` header. The server MUST include `Link` headers for key server-managed metadata, including a link to the parent <a>container</a> (`rel="up"`), and a link to the created resource's dedicated <a>linkset resource</a> (`rel="linkset"; type="application/linkset+json"`). Additional links SHOULD include `rel="type"` (indicating `https://www.w3.org/ns/lws#Container` or `https://www.w3.org/ns/lws#DataResource`). The body MAY be empty or include a minimal representation of the resource. All metadata creation and linking MUST be atomic with the resource creation to maintain consistency. | ||
| On success, the server MUST return the 201 status code with the new URI in the `Location` header. The server MUST include `Link` headers for key server-managed metadata, including a link to the parent <a>container</a> (`rel="up"`), and a link to the created resource's dedicated <a>linkset resource</a> (`rel="linkset"; type="application/linkset+json"; profile="lws-meta"`). Additional links SHOULD include `rel="type"` (indicating `https://www.w3.org/ns/lws#Container` or `https://www.w3.org/ns/lws#DataResource`). The body MAY be empty or include a minimal representation of the resource. All metadata creation and linking MUST be atomic with the resource creation to maintain consistency. |
There was a problem hiding this comment.
Adding a profile="..." shifts the problem rather than resolves it. The earlier concern was that an LWS server could not store a DataResource with media type application/linkset+json, but by adding a profile, it means that an LWS server cannot store a DataResoruce with a media type of application/linkset+json; profile="...". And that is true of any arbitrary profile string.
One way around this would involve using Prefer headers. For example:
For a DataResource stored with media type application/linkset+json, a client can request the linkset representation via (as an example):
Prefer: return=representation; include="https://www.w3.org/ns/lws#Linkset"
In this way, for the normal case of a GET request with no special headers, the response would be:
Content-Type: application/linkset+json
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
The response from a server that supports content negotiation via Prefer headers would be:
Content-Type: application/linkset+json
Link: <https://www.w3.org/ns/lws#Linkset>; rel="type"
which would be sufficient to know that the response is the linkset and not the data resource.
This approach would require the addition of a vocabulary term (e.g. https://www.w3.org/ns/lws#Linkset). An alternative terms may be preferred.
There was a problem hiding this comment.
Adding a profile ... means that an LWS server cannot store a DataResource with a media type of
application/linkset+json; profile="...". And that is true of any arbitrary profile string.
That depends on how we define the profile, i.m.o... Since we would define the profile ourselves, we can include in its meaning that it is a server-managed resource/representation. Then there is no semantically valid reason why someone would to store a data resource of that type.
The Prefer header is an option I suggested earlier, and indeed avoids your issue as well. However, contrary to the profile parameter, there is afaik no standardized way to indicate in a rel=linkset link that the link set should be requested with such a header.
There was a problem hiding this comment.
I could live with this PR (I agree that we could decide that this particular profile is "reserved" for LWS's auxiliary resources).
However, I share @acoburn's concern (which echoes the concerns I expressed on #165) that content-type is not the right place to negotiate between the primary resource from the auxiliary resource.
If we want to provide such a feature, I would suggest something like
GET /some-primary-resource HTTP/1.1
Prefer: auxiliary; rel=linkset
there is afaik no standardized way to indicate in a rel=linkset link that the link set should be requested with [the Prefer header].
Agreed, my proposal above would need to be registered in IANA's Preference Registry.
3 participants
As discussed in last week's meeting (2026-06-22), this minor addition to the merged #167 preserves part of the practical advantages of #165: in line with RFC 9264 (and the Content Negotiation by Profile draft) this PR adds a
profile="lws-meta"parameter torel=linksetweb links, and theContent-TypeandAcceptmedia types for link sets, so that there can be no confusion between linksets as auxiliary resources and link sets as data resources.Preview | Diff