- From: Yves Lafon <ylafon@w3.org>
- Date: Mon, 15 Oct 2012 08:45:49 -0400 (EDT)
- To: Henry Story <henry.story@bblfish.net>
- cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp-wg <public-ldp-wg@w3.org>
On Thu, 11 Oct 2012, Henry Story wrote:
>> The complete solution is POST to container, get back a Location:, maybe a 301 (Moved Permanently), and PUT or POST to the location.
>
> One can do a LOT better. Just follow RFC5995
Which is an application of the definition of POST in RFC2616:
<<
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).
>>
(meaning that in this case, the ;add-member URI parameter is not
necessary, nor the title header).
>
> http://tools.ietf.org/html/rfc5995#section-3.4
>
>>> Request
>
> POST /collection;add-member/ HTTP/1.1
> Host: example.com
> Content-Type: text/plain
> Slug: Sample Title
> Content-Length: 67
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/>
> <> a foaf:Document .
>
>
>>> Response
>
> HTTP/1.1 201 Created
> Location: http://example.com/collection/sample%20title
>
>
>> But it's a round trip and (arguably) an impractical nuisance.
>>
>> If you want to use N-triples (no base URI), and the subject is the BPR, then you have to know the BPR URI before creating the N-Triples.
>>
>> Andy
>>
>
> Social Web Architect
> http://bblfish.net/
>
>
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Monday, 15 October 2012 12:45:52 UTC