Re: Context Link Header on PUT/POST?

Thanks Gregg!

Comments inline...

On Thu, Mar 5, 2015 at 5:13 PM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> > On Mar 5, 2015, at 2:34 PM, Robert Sanderson <azaroth42@gmail.com>
> 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:
> >     http://www.w3.org/TR/json-ld/#interpreting-json-as-json-ld
> >
> > 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 5.2.3.4 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
headers.

Thanks!

Rob

[2] http://www.w3.org/TR/ldp/#ldpc-container


Gregg
> [1] http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
>
>
-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305