Hi On Fri, Jul 6, 2012 at 9:51 AM, Melanie Reiplinger <[email protected]> wrote: > curl -i -X PUT -H "Content-Type:application/rdf+xml" -T someEntity > "http://<stanbol>/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) >
One question: does the RDF data "someEntity" contain triples for the URL "http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html";? If not, than you should get the exact same response as I do. curl -i -X PUT -H "Content-Type:application/rdf+xml" -T Valentino_Rossi.rdf "http://localhost:8080/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html&create=false"; HTTP/1.1 100 Continue HTTP/1.1 400 Bad Request Accept: application/json Content-Type: text/plain Transfer-Encoding: chunked Server: Jetty(6.1.x) Parsed RDF data do not contain any Information about the parsed id 'http://developer.yahoo.com/javascript/howto-proxy-falseaddress.html' When repeating the request with an Entity where data are present in the sent RDF file I do get the following result curl -i -X PUT -H "Content-Type:application/rdf+xml" -T Valentino_Rossi.rdf "http://localhost:8080/entityhub/entity?id=http://dbpedia.org/resource/Valentino_Rossi&create=false"HTTP/1.1 100 Continue HTTP/1.1 400 Bad Request Accept: application/json Content-Type: text/plain Transfer-Encoding: chunked Server: Jetty(6.1.x) Unable to create an Entity http://dbpedia.org/resource/Valentino_Rossi becuase it does not and creating new is deactivated. You might want to set the 'does not exists' parameter to TRUE in your Request So I am unable to reproduce this. If you can give me access to the Stanbol Server you test against I could try to further look into this. best Rupert > (where I try to update a non-existing entity). > > Best > > melanie > > Am 03.07.2012 17:48, schrieb Rupert Westenthaler: >> >> 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
