Comments on: REST/WebArch question http://richard.cyganiak.de/blog/2006/11/restwebarch-question/ A weblog by Richard Cyganiak Wed, 03 Aug 2011 12:16:08 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Mark Baker http://richard.cyganiak.de/blog/2006/11/restwebarch-question/#comment-14914 Mark Baker Fri, 17 Nov 2006 05:07:23 +0000 http://dowhatimean.net/2006/11/restwebarch-question#comment-14914 I should have added a smiley; I think that the resolution to httpRange-14 is a bad one. But I suggest you take this to the TAG to request clarification. I should have added a smiley; I think that the resolution to httpRange-14 is a bad one. But I suggest you take this to the TAG to request clarification.

]]> By: Richard Cyganiak http://richard.cyganiak.de/blog/2006/11/restwebarch-question/#comment-14588 Richard Cyganiak Tue, 14 Nov 2006 15:29:03 +0000 http://dowhatimean.net/2006/11/restwebarch-question#comment-14588 No, Mark, it's not that easy after httpRange-14. Because by the same line of reasoning, GET on a real-life lightbulb should tell me if it's on or off, no? httpRange-14 gives a clear negative answer to that question. So this line of reasoning doesn't work. No, Mark, it’s not that easy after httpRange-14.

Because by the same line of reasoning, GET on a real-life lightbulb should tell me if it’s on or off, no?

httpRange-14 gives a clear negative answer to that question. So this line of reasoning doesn’t work.

]]> By: Mark Baker http://richard.cyganiak.de/blog/2006/11/restwebarch-question/#comment-14585 Mark Baker Tue, 14 Nov 2006 14:36:17 +0000 http://dowhatimean.net/2006/11/restwebarch-question#comment-14585 PUT on a real-life lightbulb should be able to turn it on and off, no? PUT on a real-life lightbulb should be able to turn it on and off, no?

]]> By: polaar http://richard.cyganiak.de/blog/2006/11/restwebarch-question/#comment-14568 polaar Tue, 14 Nov 2006 11:07:42 +0000 http://dowhatimean.net/2006/11/restwebarch-question#comment-14568 Oops, I was not completely right it seems, according to the http spec, "The new URI is not a substitute reference for the originally requested resource". Which means that my suggestion to re-send the request to that URI doesn't make sense. If the 303 response includes a location header field with a URI, then that is the URI of another resource, and any actions on that resource should be seen as separate from the actions on the original URI. Oops, I was not completely right it seems, according to the http spec, “The new URI is not a substitute reference for the originally requested resource”. Which means that my suggestion to re-send the request to that URI doesn’t make sense. If the 303 response includes a location header field with a URI, then that is the URI of another resource, and any actions on that resource should be seen as separate from the actions on the original URI.

]]> By: leobard http://richard.cyganiak.de/blog/2006/11/restwebarch-question/#comment-14474 leobard Mon, 13 Nov 2006 16:27:55 +0000 http://dowhatimean.net/2006/11/restwebarch-question#comment-14474 a 303-concept server should throw an internal server error or 404 on a delete and POST request. the 303 was intentionally added to say that the URL is NOT a document, but a resource identifier. To GET the RDF document of the uri A, you are redirected to the uri A-RDF. The RDF document downloadable at A-RDF should then be changeable by POST or DELETE. on the other hand, POST and DELETE is nearly impoossible anyway, because the semantics of "what to delete" is not clear. The rdf document retrieved from A-RDF may have more information than just about A. so a SPARQL endpoint which allows changes may be better. I would be against POST and DELETE on 303 URIS, to hard to understand, to hard to define strictly, just a source of problems. Lets wait another year to get used to 303 first a 303-concept server should throw an internal server error or 404 on a delete and POST request.

the 303 was intentionally added to say that the URL is NOT a document, but a resource identifier. To GET the RDF document of the uri A, you are redirected to the uri A-RDF. The RDF document downloadable at A-RDF should then be changeable by POST or DELETE.

on the other hand, POST and DELETE is nearly impoossible anyway, because the semantics of “what to delete” is not clear. The rdf document retrieved from A-RDF may have more information than just about A. so a SPARQL endpoint which allows changes may be better.

I would be against POST and DELETE on 303 URIS, to hard to understand, to hard to define strictly, just a source of problems. Lets wait another year to get used to 303 first

]]>