Re: ldp-ISSUE-80 (post create media type): How does a client know which POST requests create new resources [Linked Data Platform Spec]

hello john.

On 2013-06-07 11:19 , "Linked Data Platform (LDP) Working Group Issue
Tracker" <sysbot+tracker@w3.org> wrote:
>ldp-ISSUE-80 (post create media type): How does a client know which POST
>requests create new resources [Linked Data Platform Spec]
>HTTP tells a client how to know (after the fact) if it created a resource
>(201 status code), but not *in advance* how to know if thatıs the
>semantic it will get should its POST be accepted.
>Proposal: define a new HTTP header Accept-Post-Create whose value is a
>media type list to communicate which media types the server accepts when
>creating resources.

while it is possible to define and register new HTTP headers, it is not
the only (and many would argue not the best) way to go. all depends on
context and preferences, but just to get things going, here are some
considerations:

- if the accepted media types of POST are fix, this can be defined in the
media type (or in our case in the vocabulary) and then the rules of
engagement are well-defined. but i think in this case, they are not fix;
each LDP server can decide to accept different media types.

- if this is runtime, then one pattern to do this is to do what AtomPub
did, by including this information as part of the vocabulary:
http://tools.ietf.org/html/rfc5023#section-8.3.4

- another way to go is to try to make this concept reusable but still
within the context of vocabularies (i.e., not minting a new header), and
introduce the concept of "link hints", currently proposed (but not yet
standardized) here:
http://tools.ietf.org/html/draft-nottingham-json-home-03#section-4.4

so i would at least not jump to the conclusion that you need such a new
header field. btw, if you want to go "header field shopping",
http://www.iana.org/assignments/message-headers/perm-headers.html is a
good place to see what's already there. i don't think what you're looking
for is in there, though.

personally, i'd rather handle this in the vocabulary than in a header.
also, i think it would be great to handle this generically (a la link
hints) and thus allow other hints to be used as well, without having to
change the vocabulary. but that may be a bit ambitious at this point in
time, especially since the link hint registry is not yet existing. so
pragmatically, i would probably add something along the lines of AtomPub's
approach, i.e. something in the vocabulary that represents this link hint.

cheers,

dret.

Received on Friday, 7 June 2013 22:56:18 UTC