Re: [Resteasy-developers] RESTEasy client changes

[Bill B. <bb...@re...>]

Solomon Duskis 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
>  

This wasn't the approach I was thinking of.  Think Servlet Filters but 
on the client.  Each filter (interceptor) could add whatever 
headers/data it wanted to the request (i.e. a custom security 
interceptor).  Each filter could process the response in a special way 
(for instance, the client-caching interceptor looks for Cache-Control 
headers in the response and caches accordingly).


> 
> As far as the caching client goes: I'm not quite sure which existing 
> caching solution best fits a RESTful request.

Read up on Cache-Control header.  Basically the server passes a response 
header that states the cache policy.  Its a pretty rich protocol.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com