W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: REST and HTTP Update

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 6 Oct 2009 21:45:00 +0100
Message-Id: <D3F73331-D12C-47C2-9CD8-3C1C36F875AA@garlik.com>
To: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 6 Oct 2009, at 20:25, Kjetil Kjernsmo wrote:

> On Tuesday 6. October 2009 18:18:27 Steve Harris wrote:
>> This is compatible with PUT and POST semantics, and I believe that it
>> conforms to REST ideals, though that may be arguable.
>
> I may be pedantic, but it means you are modifying a resource with a
> different URI than the one you are POSTing and PUTting to. I'm not  
> sure,
> but I think this isn't RESTful...

I don't believe that I am modifying a resource with a different URI,  
but I may well be missing some subtlety.

In the example I gave, the modified resource is
http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf

If this was a local copy of some remote data (which it is, in effect)  
then it would be a reasonable, RESTful URI for the local copy of the  
data, wouldn't it? If not, what would a RESTful URI for this local  
copy be?

I can GET, PUT and POST to this URI, so it's RESTful in that regard,  
I'm not modifying the resource <http://example.com/data.rdf>, as I  
have no way to write to it, even if I wanted to. In much the same way  
as someone who has a local copy of dbpedia.org can't modify that, only  
their local copy, which could be reflected through http://endpoint/dbpedia/ 
... or wherever.

Regardless, Chimezie's proposal allows for RESTful access (as I  
understand it), if the other operations, acting on cached graphs can  
be done RESTfully (as above, I believe) then that's good, if not, then  
so be it.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Tuesday, 6 October 2009 20:45:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT