jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR

From: Markus KARG <markus_at_headcrashing.eu>
Date: Wed, 18 May 2011 19:47:09 +0200

Marek,

thanks for asking.

Just one example:

Our company is an ISV (besides other divisions). Our customers are using the services provided by our software. Those services are RESTful. The entities sent back to the clients are (in part) very huge, containing a lot of images and XML files having lots of URIs. The typical client GETs such an entity, inspects it, then follows the URIs to get the referenced data (just like a browser parses a HTML file to learn about <IMG> and then downloads those PNGs). Now it happens that many of those URIs are found several times in the same XML document, so the clients requests the same PNGs again and again. Or, a client received two different XMLs containing the same PNG URIs. The result is that the line between client and server is rather crowded and you have long loading times (for stuff already transferred to the client). The solution currently is to tell our customers that when they write clients, they must somehow detect that the do not need to load again (like using a LRU Map<URI,Image> for example). The problem is that (a) every customer must write that again in every client he's coding. (b) least customer's understand that when using a specialized client API, that API does not implement that caching since RFC2616 tells how to do that. (c) customers dislike our services as they think the performance problem is in the service, while it actually is in their missing client side cache. So, what we want is that we can tell our customers: "You can safely go with JAX RS 2.0 Client API, all you need to do is adding a single line.". This is one example of many where caching is essential. As neither our customers nor our company wants to check out different proprietary caching tools, the solution just can be to have a non-proprietary solution. As we (in theory) could also put some default-config'ed SQUID on-premise (which would solve the problem in part) we do not see any of the mentioned concerns of having to discuss lots of things. But as the charter of this EG is to provide a *RESTful* API (not just *some* API), and as caching is part of RFC2616, we just do not accept that every customer shall either fiddle with proprietary caching products or install a SQUID box. This just has to be in a *RESTful* API, or the API is just ignoring the fact that http *contains* caching and RESTful applications often *need* caching to prevent flooding the net with repeated calls.

Hope that makes the situation clear. If we omit a standard API for enabling a cache, our customers just do not need another Client API, as they are already able to run a http GET. The benefits left over are just marginal so I could nobody convince to use JAX RS Client API instead of what they already run now. And if I cannot convince them, I wonder whom else to convince then?

Regards
Markus

> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Mittwoch, 18. Mai 2011 16:52
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> Markus,
> I'd like to better understand your motivation for pushing so hard for
> including this feature in the spec. When you say
> "this feature is essential for us", who are you referring to?
>
> Thanks,
> Marek
>
> On 05/16/2011 06:50 PM, Markus KARG wrote:
> > Caching is one of the most important things on my list, so I'm sorry,
> but independent of what else we will do in this future, a JAX RS 2 spec
> without a vendor-independent way to enable caching will not get my
> vote. Just to make clear how essential this feature is for us.