Could you expand on that a little and perhaps provide a reference? I can
not remember having met such guidelines anywhere.
I use ehcache (specifically a subclass of
SimpleCachingHeadersPageCachingFilter) with a short lifespan in order to
transparently cache responses from read-only resources. It not only
improves performance, but also would appear to add a certain level of
security against DoS.
/Casper
Felipe Gaúcho wrote:
> humm.. no problem to cache server resources (memcache) for performance
> reasons.. and other tricks...., but just keep in mind that in REST you
> should never cache "http responses payload" in the server side.... it
> always should be cached in the client side (one of principles of
> rest).....
>
>
> On Tue, Jan 19, 2010 at 12:07 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>> On Jan 14, 2010, at 3:16 PM, Comerford, Sean wrote:
>>
>> So I’m slowly working through a prototype application and have a couple of
>> high level newbie questions.
>>
>> Q1) How to best provide a “light” XML/JSON feed?
>>
>> Initial testing has shown that (due to performance considerations) I need to
>> slim down the markup I’m outputting. Un/marshalling costs are just too high
>> if I output all the fields we have in our POJOs.
>>
>> I can easily accomplish that by marking a lot of stuff @XmlTransient so it’s
>> omitted.
>>
>> But the problem with that is there are SOME cases where I really do need
>> want those fields in the markup.
>>
>> So what I’m looking to do is develop a “light” and “full” version of my
>> output. Short of basic coding conventions (i.e. gving multiple classes
>> representing the same underlying data but with differing JAXB annotations),
>> does jersey or JAXB provide anything in this respect?
>>
>>
>> No, currently the application developer has to do that when using JAXB.
>>
>> Creating resource “views” is one possible solution I guess but I’m not sure
>> that feels right and it certainly loses some of the “automagic” benefit of
>> the Jersey+JAXB framework but perhaps I’m missing something.
>>
>> Q2) Controlling the Jersey life cycle... I could have sworn I saw an example
>> of this but can’t seem to find now. Let’s say for the sake of argument I
>> want to marshal my Java objects to XML myself (maybe to cache the JAXB
>> generated markup) and have my @GET method return that instead of a JAXB
>> annotated POJO instance.... How do I do that / can someone point me to an
>> example?
>>
>>
>> You could make the resource class a singleton and cache in a field of byte[]
>> of the serialization on the first request.
>> @Singleton
>> public class MyResource {
>> byte[] xyz;
>> @GET
>> public byte[] get() {
>> synchronized(this) {
>> if (xyz == null) {
>> // cache
>> }
>> return xyz;
>> }
>> }
>> }
>>
>> I think there may be more general solutions using etags and ehcache or using
>> a web proxy with appropriate cache-control headers.
>> Paul.
>>
>
>
>
>