Re: PUT to create new resource in container?

On 25 October 2015 at 18:34, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 25 October 2015 at 18:09, Tom Johnson <tom@dp.la> wrote:
>
>> Hi Rob,
>>
>> Your reading aligns with mine.
>>
>> In Lamprey[0], the default behavior is to create a new, uncontained
>> resource with the specified interaction model at the PUT target. This makes
>> it easy to create new "root" containers, or free-floating direct/indirect
>> containers.
>>
>> I know that Marmotta takes a different tack where, in your example,
>> /foo/bar would be contained in /foo. I believe it errors if you try to use
>> PUT to create, e.g., /foo/not-a-container/bar.
>>
>> Are there other behaviors in existing implementations? What are the
>> trade-offs?
>>
>
> "
>
> An alternative, though not standard way of creating new resources is to
> use HTTP PUT. Although HTTP PUT is commonly used to overwrite resources,
> this way is usually preferred when creating new non-RDF resources (i.e.
> using a mime type different than *text/turtle*).
>
> REQUEST:
>
> PUT /picture.jpg HTTP/1.1
> Host: example.org
> Content-Type: image/jpeg
> ...
>
> RESPONSE :
>
> HTTP/1.1 201 Created
> "
>
> Read more at:
>
> https://github.com/solid/solid-spec
>
>
And

HTTP PUT to create

Another useful feature that is not yet part of LDP deals with using HTTP
PUT to create new resources. This feature is really useful when the clients
wants to make sure it has absolute control over the URI namespace -- e.g.
migrating from one pod to another. Although this feature is defined in
HTTP1.1 RFC2616 <https://tools.ietf.org/html/rfc2616>, we decided to
improve it slightly by having servers create the full path to the resource,
if it didn't exist before. For instance, a calendar app uses a URI pattern
(structure) based on dates when storing new events (i.e. yyyy/mm/dd).
Instead of performing several POST requests to create a month and a day
container when switching to a new month, it could send the following
request to create a new event resource called *event1*:

REQUEST:

PUT /2015/05/01/event1 HTTP/1.1
Host: example.org

RESPONSE:

HTTP/1.1 201 Created

This request would then create a new resource called *event1*, as well as
the missing month (i.e. 05) and day (i.e. 01) containers under /2015/.

To avoid accidental overwrites, Solid servers must support ETag checking
through the use of If-Match or If-None-Match
<https://tools.ietf.org/html/rfc2616#section-14.24> HTTP headers.


https://github.com/solid/solid-spec#http-put-to-create



>
>
>
>>
>> [0] https://github.com/ruby-rdf/rdf-ldp/
>>
>> On Sun, Oct 25, 2015 at 1:07 AM, Robert Sanderson <azaroth42@gmail.com>
>> wrote:
>>
>>>
>>> Am I correct in my reading that if there is a container /foo and I use
>>> PUT rather than POST to create a resource /foo/bar, then it is undefined in
>>> the specification whether that new resource is ldp:contained by the
>>> container?
>>>
>>> Justification:
>>>
>>> 5.2.4 does not mention using PUT to create new resources, just specifies
>>> behavior for updating resources.
>>> 5.2.3 only talks about POST in terms of adding new ldp:contains triples
>>> 4.2.4.6 specifically allows creation of resources via PUT
>>>
>>> Bug, or intentional loophole?
>>>
>>> Rob
>>>
>>> --
>>> Rob Sanderson
>>> Information Standards Advocate
>>> Digital Library Systems and Services
>>> Stanford, CA 94305
>>>
>>
>>
>