Hi Rupert.
I updated twice since your mail, now at revision 1356930, but I still
get exactly the same response for that request.
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)
(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
