Re: REST and HTTP Update

On 6 Oct 2009, at 21:26, Chimezie Ogbuji wrote:
> On 10/6/09 12:18 PM, "Steve Harris" <steve.harris@garlik.com> wrote:
>> I share Kjetil's concerns about the REST thing, but on the other hand
>> I think it's a very important aspect of the protocol.
>>
>> An alternative, which I believe to be RESTful is to target requests  
>> to
>>
>>   $endpoint + uriencode($graph)
>>
>> This is compatible with PUT and POST semantics, and I believe that it
>> conforms to REST ideals, though that may be arguable.
>
> This is the problem and the point where the question of what is  
> RESTful
> drifts from best practice to philosophy IMHO.  .

[snip]

> So the question here is, given your example, can the user expect  
> that if the
> following requests are sent:
>
> 1) PUT http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
> 2) GET http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
> 3) GET http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
>
> Where the third GET is conditional, will we have desired effect?  
> I.e., will
> the server return a 304 (Not Modified) if the RDF graph with the URI
> http://example.com/data.rdf has not changed since the second  
> request? Does
> encoding the graph URI as a query string instead of as part of the  
> path make
> a difference?

Whether a 304 can be returned depends on the capabilities of http://localhost:8080/data/ 
, but certainly nothing prevents it.

I'm not sure if the encoding makes a difference or not, but having ?s  
in your URIs often seems to be the tipping point for being not RESTful  
in peoples opinions. I don't have any real view on that, and I'm not  
sure if that's the consensus.

There's also the issue of PUT and POST, it's at least rare, and  
possibly unheard of to have PUT or POST URIs with GET-style CGI  
arguments. It's not illegal by my reading of the HTTP RFC, but it's  
unconventional at best, and doesn't have any particular meaning.

> REST allows [2] resources to have many identifiers (though it frowns  
> upon
> these identifiers changing over time).  This is why one possible
> interpretation of using a query string or path to encode the URI of  
> a graph
> is that it is a different identifier for the same resource  
> (represented by
> an RDF graph at the server).

I think that's only true in a very narrow sense. The local copy is  
frozen at the time it was copied, and can be locally modified, and may  
have had extra data attached to it at load time, for example.
Granted it /might/ be the same as the remote one, but I think the  
chances of
    GET http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
returning the same bytes as
    GET http://example.com/data.rdf
are slim.

> If you peruse popular REST lore, you find discussion threads [3]  
> that show
> that it is still an open question whether decoding part of the URI  
> of a
> request in order to determine what is being addressed is a bad thing.

I'm sure :) But if the addressed thing contains characters that cannot  
legally be included in that part of the URI (as is the case for us)  
then you have no choice, surely?

> From an engineering perspective, I think the question regarding the  
> ability
> to cache is the more relevant one.  I don't know of any other design
> principle that can be reasonably stated as the reason why using a  
> query
> parameter (or part of the path) to provide the URI of an RDF graph to
> manipulate (via its representations) is a bad thing.

I think it's a question of style as much as anything else. However,  
it's a popular principle, so I can see the argument for being in-tune  
with it, as long as it's not to the detriment of the specification.

- 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 21:22:32 UTC