Re: Context Link Header on PUT/POST?

Thanks Gregg!

Comments inline...

On Thu, Mar 5, 2015 at 5:13 PM, Gregg Kellogg <>

> > On Mar 5, 2015, at 2:34 PM, Robert Sanderson <>
> wrote:
> > The specification is clear about the use of a link header to provide a
> context for JSON to upgrade to JSON-LD when a document is being retrieved
> via HTTP GET:
> >
> >
> > Can, and if so should, this pattern also be available when accepting
> *requests* via PUT, POST or PATCH where the entity body's content-type is
> specified to be application/json?  In other words, should a well-behaved
> application also look for a link header on requests giving a context,
> rather than assuming it will be in the JSON itself?
> The spec only concerns itself with retrieving JSON documents where a Link
> header might provide a context. Moreover, it's limited to application/json;
> if provided with application/ld+json it should be ignored.

Yup, for retrieval it's very clear.

>From Wikipedia [1], it seems that the Link header may just be valid for
> Response objects, not Request objects, but I confess that I can't really
> tell what Header fields (request or response) are defined for HTTP 2.0.

The recently finalized LDP specification assumes that it is possible on
requests, [2] in section requires servers to respect the link
header provided by a client with an entity body for example.  If there's a
more authoritative source for which headers can be used by a client, that
would be very useful!  Anyone?

Were it legal, then IMO supplying a Link to the context as part of a
> POST/PUT/PATCH would be reasonable, but why do it? The main intention of
> the Link header is to either provide a context for a document that can't
> otherwise be modified to include it inline, or when the client might not be
> able to handle anything other than application/json. Obviously, in the
> request case, both client and server must be JSON-LD aware, so placing it
> within the body makes the most sense (to me, anyway).

The use case would be when the interaction pattern has already been
established from client to server, in the same way that from server to
client is c
covered in the spec.  If servers are expecting a certain JSON structure to
be sent to them, but some also do JSON-LD, then the same body would be
handled potentially differently but compatibly across the board.

Imagine, for example, if twitter or github were to JSON-LD-ify their main
APIs... this would let them treat older clients the same way as newer
clients without changing the representations sent back and forth, just the




> [1]
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

Received on Friday, 6 March 2015 01:28:50 UTC