Specify semantics of resource creation via PUT

[acoburn]

The PUT method can be used to replace or create resources. This is explicitly allowable under both LDP and HTTP.

What does the Solid specification say about PUT to create resources (MAY, SHOULD or MUST)?

Specifically, if a resource is created via PUT, what is the expectation about how this operation interacts with LDP containment?

For example, if a client creates a resource via PUT at /foo/bar/baz, should an ldp:contains triple be added to the container /foo/bar?

What if /foo/bar does not exist? Should the server create the container automatically or should the server reject the operation?

What if /foo/bar is a non-container resource (ldp:RDFSource or ldp:NonRDFSource)?

[csarven]

Just to eliminate any ambiguity, by "create resources", we consider all ldp Resources; (Non)RDFSources as well as Containers:

What does the Solid specification say about PUT to create resources (MAY, SHOULD or MUST)?

The thing is that LDP doesn't recommend containment triples to be updated through PUT ( https://www.w3.org/TR/ldp/#ldpc-put-mbrprops ):

5.2.4.1 LDP servers SHOULD NOT allow HTTP PUT to update a LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

The reason I'm mentioning is that, if PUT is used, Solid needs to make a decision on whether when a resource is created, it should update the containment triples right there and then, or not. Otherwise, it has to go against the stream (re "SHOULD NOT"). Putting aside the case where the SHOULD NOT recommendation is ignored, PUT without updating containment triples would entail that the created resources won't be discoverable through the container.

Aside: that doesn't imply that created resource is not discoverable through a property other than ldp:contains, most likely through membership properties.

It is kind of a one way street. I would suggest that to keep PUT as a MAY (as LDP), but add that server if PUT is used, server MUST update containment triples. Otherwise, containment triples are confined to POST. I'm not sure about any downsides to not updating the containment triples other than the challenge of determining the right container.

I suppose that non-overly LDP-centric clients can still operate in PUT mode without having to rely on POST or POST w/ Slug, if they are authorised and the server is willing any way.

AFAIK, LDP implementations generally do support PUT, however I don't know what they do with regards to managing containment triples.

The fundamental issue is that PUT has no context about where it belongs with regards to containers. Either additional hacking is required (eg URI parsing), default to root container as its container, or the server finds the closest container. I don't think the client should mess around with URIs and assume what the server actually claims the URI to be. (Not to mention being subject to potential differences with URI's HTTP header and/or body).

For example, if a client creates a resource via PUT at /foo/bar/baz, should an ldp:contains triple be added to the container /foo/bar?

I find this to be difficult to answer right now because it depends on resolving #35 . Provided that if 1) PUT changes containment triples (as mentioned above) and 2) /foo/bar/ is a container, then yes. If 1) but not 2) (or unknown), I suppose "/ contains /foo/bar/baz"? What I think may be reasonable to expect from clients is that, they identify the container in which they want to PUT a resource into. That eliminates relying on a URI pattern or parsing URI strings. However!!! The server doesn't explicitly know where it should be contained.. other than itself finding the most appropriate spot, possibly checking the URI pattern or throwing it under the root container.

What if /foo/bar does not exist? Should the server create the container automatically or should the server reject the operation?

The server should keep the number of operations to minimum with respect to creating new containers. Answering if/how containment is done, this may be easier to answer provided that we know the closest container.

Aside, FWIW:

$ touch /tmp/foo/bar/baz
touch: cannot touch '/tmp/foo/bar/baz': No such file or directory

What if /foo/bar is a non-container resource (ldp:RDFSource or ldp:NonRDFSource)?

Same as above. Server probably needs to find the closest or most meaningful container and link to the resource from there. However, unpopular opinion but keeping URIs opaque: if /foo/bar is a (Non)RDFSource resource, /foo/bar/baz can be a (Non)RDFSource ie. not caring about it being associated to a filesytem. I realise the obvious advantages to keeping it close to filesystem's directory/file relationship. I'm not strongly opposed to that,.. just sayin'.

More discussion and implementation experience (on different code from different implementers) would be useful here.

If PUT is supported and assuming that its is desirable to have the interaction model for POST and PUT aligned, then clients intending to create an LDPR as well as subsequent requests to it with PUT should be honoured the same way by servers as that of POST: https://www.w3.org/TR/ldp/#ldpc-post-createrdf .

Edit: Mentioned PUT LDPR expectation.

[pmcb55]

Just my initial thoughts (mainly due to 'keeping the server dumb'):

What does the Solid specification say about PUT to create resources (MAY, SHOULD or MUST)?

Like LDP, optional (so MAY).

Specifically, if a resource is created via PUT, what is the expectation about how this operation interacts with LDP containment?
For example, if a client creates a resource via PUT at /foo/bar/baz, should an ldp:contains triple be added to the container /foo/bar?

If /foo/bar is already explicitly an ldp:Container then yes, otherwise, no.

What if /foo/bar does not exist? Should the server create the container automatically or should the server reject the operation?

Server MUST reject the operation. (Client should explicitly create '/foo/bar' first as an 'ldp:Container'.)

What if /foo/bar is a non-container resource (ldp:RDFSource or ldp:NonRDFSource)?

Server MUST reject the operation. (Client should update '/foo/bar' first (via PATCH or PUT) to try and explicitly make it an 'ldp:Container' first.)

[dmitrizagidulin]

Question:

What if /foo/bar does not exist? Should the server create the container automatically or should the server reject the operation?

@pmcb55:

Server MUST reject the operation. (Client should explicitly create '/foo/bar' first as an 'ldp:Container'.)

That seems like a reasonable policy. I do want to point out, though, that the current behavior (and I believe spec) for both PATCH and POST in Solid is to follow the mkdir -p semantics (to automatically create the intermediate containers).
So, at very least, I'd like whatever policy we settle on to be consistent, among PUT, POST and PATCH.

(Personally, I vote for the mkdir -p behavior.)

[dmitrizagidulin]

@acoburn - I hope you don't mind, I changed the title of this issue slightly (so I can point the various scattered PUT-related issues to it)

[dmitrizagidulin]

Related issues:

• solid-spec/201 - PUT should not switch resources between container and non-container
• solid-spec/198 - Is PUT a standard?
• solid-spec/185 - Does PUT /foo/bar add a containment triple for /foo/ ldp:contains /foo/bar?
• solid-spec/30 - PUT for create requires extension of LDP
• solid/71 - container type for container that creates subdomains
• solid/42 - Disable random slug generation for containers