Hi all,
Sorry for replying to this old message, but I'm bitten by this issue
once again while migrating from 2.0.11 to 2.1-RC4. In contrast to the
previously reported issue, I'm now having trouble getting an object for
which we've written a custom ConverterHelper. The behaviour of 2.1
appears to be different than the behaviour of 2.0 in this respect.
On the server side, I've got a resource that returns Graph objects like
so:
@Get
public Graph getGraph() { ...}
On the client side, we're requesting the graph using:
clientResource.get(Graph.class)
The (de-)serialization is handled by a custom GraphConverter. The
issue that I'm running into now concerns empty graphs. GraphConverter
converts such graphs to 0-byte text documents (of type text/turtle). On
the client side, such a 0-byte text document would have been converted
to an empty Graph object, but the get(Graph.class) method call returns
<null> instead. The GraphConverter is never called.
The reason that GraphConverter isn't called is because of the
if-statement on line 153 in ConverterService, which bypasses the
converters for empty representations. This is where this issue relates
to the previously reported problem.
Has there been any progress on the resolution of this issue? Any chance
there'll be a fix some time soon?
Regards,
Arjohn Kampman
On 03/10/2011 15:11, Arjohn Kampman wrote:
> Related to my previous question regarding empty string parameter values:
>
> I have written a server resource that returns String values. The
> DefaultConverter takes care of converting this to/from a text/plain
> representation. The restlet framework does a brilliant job at taking
> care of all this, except when the result is an empty string. In this
> case, restlet returns a 204 "no content" result.
>
> While the 204 result might look accurate, it doesn't look semantically
> correct to me. There's a difference between "no content" and "empty
> content". RFC 2616 says the following about 204 codes:
>
> "... If the client is a user agent, it SHOULD NOT change its
> document view from that which caused the request to be sent..."
>
> So, in a browser, you'll never see the empty result. The request appears
> to be ignored instead.
>
> On the client resource side, the 204 response is converted to a <null>
> value, rather than an empty string. This requires me to add a null-check
> in all client resources that return Strings.
>
> Any thoughts on this?
>
> Regards,
> Arjohn Kampman
--
Arjohn Kampman - www.aduna-software.com
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2950796
