REST/WebArch question

Does the httpRange-14 resolution imply that HTTP PUT and DELETE are in general not allowed on resources that answers to GET with a 303 redirect?

I take the answer to be yes, because asking a server to delete something that may be a real-world object seems unreasonable.

(POST seems less clear-cut. POSTing to my URI, for example, could send an email to me.)

Thoughts?

This entry was posted in General, Semantic Web. Bookmark the permalink.

8 Responses to REST/WebArch question

  1. karl says:

    DELETE on real world object = Death penalty? :)

  2. polaar says:

    I would assume that you can, but the server will just reply with a 303 redirect again. The point of a redirect is that you should now use the URI given in the Location header field (which may not be present for 303 responses). So: if there is a Location URI given, and it is a http URI, it would make sense to use that to re-send your request to. If there isn’t, that would imply that the initial URI refers to a real-world object (or other resource that is not http-accessible)
    This is not explicitly mentioned in the httpRange-14 resolution, but if a server wants to use a http-URI for a real-world object, and would therefore not answer with 200 OK, but with 303 Found, why would it want to provide ANOTHER http URI to use?

  3. Max says:

    Why should POST differ from the others? PUTin could also send an email to you, DELETE as well. With a URI X for which you GET a 303 to Y, you can of course PUT/POST/DELETE X, which correctly means, PUT/POST/DELETE Y (because you get redirected). Hmm, do you? Can I put another redirection target to X? What is the state of X, what is it modelling? We can say, it is modeling a single web document URI. So, by DELETING x, there will be no 303 on furher GETs. That’s fine according to range-14 and allows remote admins to change the redirection target of x, e.g. by PUTin a new one. So, I don’t see a general problem with allowing P/P/D on a URI like x.

  4. leobard says:

    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

  5. polaar says:

    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.

  6. Mark Baker says:

    PUT on a real-life lightbulb should be able to turn it on and off, no?

  7. 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.

  8. Mark Baker says:

    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.