Against DoS you should use an apache as entry point to your application..
these read-only resources should be cached in the client side, never
in the server side.. (unles operations to retrieve them are really
heavyweight, then you have other problems than your http layer....)
On Tue, Jan 19, 2010 at 12:41 PM, Casper Bang <casper.bang_at_gmail.com> wrote:
> 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.
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
------------------------------------------
Felipe Gaúcho
10+ Java Programmer
CEJUG Senior Advisor