Re: [Resteasy-developers] RESTEasy client changes

[Solomon D. <sd...@gm...>]

sorry...  I meant that I built these classes off of the 1.0 beta 8 source
distribution.

On Tue, Oct 7, 2008 at 9:46 PM, Solomon Duskis <sd...@gm...> wrote:

> I refactored the ProxyFactory code a bit, and attached it as a .zip file to
> this email.
>
> Here's a summary of what I did:
>
> 1) ClientInvoker:
>   A) I refactored the invoke method into smaller, overridable methods:
>      - generate base URI
>      - populate parameters
>      - retrieve results
>
>   B) I moved the creation of Get/Put/Post/Delete HttpMethodBase into a
> factory (HttpMethodBaseFactory).  I got rid of GetInvoker/PutInvoker... and
> replaced them with a call to
> HttpMethodBaseFactoy.createDefaultFactory(String method) which gets called
> as part of the "retrieve results" step.  I did this so that the methods in
> 1A can be overridden in an without interfering with the HttpMethodBase
> object creation.
>
>   The combination of those two changes should allow clever subclassing,
> like adding extra parameters or caching a GET call.  An interface would
> allow some fancy decorations: CachingClient ->
> ProprietaryParameterAddingClient -> BaseClientInvokerl; however, I didn't
> want to build that just yet without vetting the general idea with the group.
>
> 2) ProxyFactory;
>   A) I made it into an abstract class (I didn't bother with an interface,
> so that I can keep the existing static methods and still keep the
> ProxyFactory class)
>
>   B) I added an abstract method createFactory(Class<T>) along with a
> DefaultProxyFactory implementation that that has the original ProxyFactory
> functionality.  A user will need to override the
> ProxyFactory.createClientInvoker() in order to create the clever subclass of
> ClientInvoker
>
>
> As far as the caching client goes: I'm not quite sure which existing
> caching solution best fits a RESTful request.  If I understand HTTP
> correctly, I believe that the server side determines how long to cache a
> resource.  I'm not quite sure how that fits in with existing caching
> solutions which usually have full control over the caching strategies.
> Also, I'm not quite sure how ETags fit in here.
>
> BTW, I used the source from the 0.8 source distribution.
>
> -Solomon
>