Re: Precondition support

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 10 Apr 2007 23:00:42 +0200

On Apr 10, 2007, at 8:14 PM, Jerome Louvel wrote:

> Paul,
>>> Yes, but the status is related to the Resource POJO, not to the
>>> Representation POJO.
>> Oh!, my bad, i mistakenly assumed from the context of the
>> email threads that such methods were part of the resource.
> No problem :)
>> So are you proposing that a HTTP method on a resource return a
>> representation instance even if that representation is not serialized
>> because precondition are met?
> Did you mean "aren't met"? If so, yes this is the idea.

Yes, i meant "aren't met" :-)

Perhaps we need two solutions for the following cases:

1) returning Representation<T>*; and

2) when creation of T is costly but obtaining the etag and/or last
modified is relatively cheap.

1 works really well for the case when returning say FileInputStream
or File but if say you have to return a Feed instance containing 100
Entry instances transformed from a DB query only for it never to be
serialized then it can be a waste of CPU for the web container and
the database.

The API proposal currently specifies support for 2 (via precondition
checking on the request context and returning HttpResponse), but it
did not occur to me that we could also support 1, which is nice :-).
2 also allows for extended precondition support.


* This is another use case in favour of reusing Representation<T> as
opposed to mandating that developers modify T or wrap T in their own