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.
Paul.
* 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
class.