On Tue, Jul 3, 2012 at 5:18 PM, Rupert Westenthaler <[email protected]> wrote: > Hi Melanie, > > I think this is because the parsed RDF data do not contain any > information (rdf triples) about the parsed id > > http://developer.yahoo.com/javascript/howto-proxy-falseaddress.htm > > I will add a check that ensures that a BAD_REQUEST is thrown in those cases. >
fixed with http://svn.apache.org/viewvc?rev=1356788&view=rev > best > Rupert > > > On Tue, Jul 3, 2012 at 3:02 PM, Melanie Reiplinger > <[email protected]> wrote: >> Hi Alessandro and all. >> >> Today we found a strange behaviour in one of my tests that uses update >> functionality of the entityhub/entity. When trying to update a non-existing >> entity ( = erroneous or non-existing id), an error code 304 (Not Modified) >> is returned. >> This makes my test notify me of a success, although intuitively, one would >> think of this as a fail (since I tried to update something that does not >> exist). >> >> curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity.rdf >> "http://lnv-89012.dfki.uni-sb.de:9001/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"; >> HTTP/1.1 100 Continue >> >> HTTP/1.1 304 Not Modified >> Server: Jetty(6.1.x) >> >> Best, >> melanie >> >> >> Am 28.06.2012 08:13, schrieb Fabian Christ: >> >>> 2012/6/27 Alessandro Adamou<[email protected]>: >>>> >>>> So far I've made these methods return 303 See Other with the created >>>> resource, basically because I wanted browsers to automatically redirect >>>> to >>>> that URL when the ontology is added using the HTML form. But I've been >>>> thinking that perhaps returning a 201 CREATED would be more appropriate >>>> on >>>> the REST side. >>> >>> I think 201 is the right way to go. The response of a POST just tells >>> you that the resource was created and optionally where it was created >>> using the Location header. >>> >>> You can also use 303 and hope that the client interprets it correctly. >>> But this response may not be the right one for all clients. Another >>> client than a browser may not need the redirect and will perhaps be >>> confused. >>> >>> Therefore, the 201 is IMO the best solution and instead implement the >>> redirect separately. >>> >>> Best, >>> - Fabian >> >> > > > > -- > | Rupert Westenthaler [email protected] > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
