Re: PUT to create, was Re: Proposal: normative changes for profiles

> I was trying to explain this to someone recently and it seemed to us
> there's a big whole in this design.  How is a client supposed to 
> know where it can PUT things? 

Valid question.  Applies to PATCH-as-create too, I suspect.  I hedge only 
because I remember that 5789 does say PATCH can be used to create new 
resources, but I don't remember if it suggests a PUT-like, POST-like, or 
no (silent on) interaction model.

> And if it does PUT things there, do
> they end up linked from anywhere?    What seems right to me, taking 
> a stab in the dark, is that at LDPC can have some associated URL 
> space, and if you do a PUT-to-create in that space, it's pretty much
> the same as POSTing to the LDPC.     So the new PUT URL ends up as a
> resource in the LDPC as well. 

As long as the URL you selected is not already in use, that's the fuzzy 
model I've had in my head.  Given that I don't know of anyone on my end 
planning to implement create-via-PUT, I have not thought it through deeply 
myself.

IMO the important distinction is the "create" semantic, not the HTTP 
method used.  I would expect the same consequences on membership triples 
as the result of any create, irrespective of the HTTP method employed on 
the request.

> I imagine an LDPC could advertise 
> this functionality with a triple or like: { <> 
ldp:memberCreationURLPrefix 
> "http://example.org/container75_" }. 

> Alternatively, we might 
> just agree the URL prefix is the LDPC URL (plus a slash). 
> Then we 
> just need a flag like { <> a ldp:Puttable }. 

The Allow response headers seem sufficient to convey the semantic I infer 
from your choice of predicate.
I don't know that it's the semantic you want though - saying that PUT is 
allowed gives a client no guarantees that Create is allowed via PUT.  This 
is analogous to the issue I raised when we were naming the proposed 
Accept-Post header.

>  ... and I guess you 
> don't even need that flag with Vanilla servers, which always have 
> that flag set?

If we decide (as proposed) that vanilla servers MUST support PUT, then yes 
knowing that it's a vanilla server is enough *for an LDP-aware client* to 
know that create-via-PUT is supported by the server.  If your goal is to 
have a more broadly useful flag (ala the Accept-Post discussion) that any 
*"new-flag-aware" HTTP client* could use, then you'd still want some 
additional message content.

Betcha can't tell I've been looking at the Conformance section changes 
over the past 2 days (not committed yet though - tease).

> I'm not sure why anyone would want to do this.  Maybe for some apps 
> the clients have an algorithm for picking the URLs and the server 
> doesn't know it or can't implement it, itself?   Dunno.

I'm unclear on what/how much of the preceding you mean by "this".  Your 
"it seemed to us there's a big whole" statement implied to me that we're 
discussing something likely to result in/seed a new issue, but your ending 
calls that into question.

I could posit cases where the server might not know (all) the potential 
URL space(s), but without a concrete use case that would just be random 
speculation (and the one I have in mind I could probably play the "it's an 
access control issue" Jedi mind trick with).


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario