Client abstraction

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Client abstraction

Andreas Egloff
We're happy campers with the server side capabilities Restlet provides us; particularly the dynamic ability to define and register resources has set this apart from other (to remain unnamed) frameworks we used. This is crucial in the declarative and pluggable environment we have.

Now I have a question on the client abstraction though in Restlet.

In our use cases it is common that we're essentially proxying some kind of RESTful call. We may be augmenting some of the call details (e.g. authentication, additional headers etc), or these may already be contained in the original caller's details.

If we use the client resource abstraction that gives us a nice interface for when we need to augment the request (e.g. setting basic auth settings). But, it also explicitly prevents us from passing through/setting headers directly if the same header is also exposed through the API. If we drop down to a lower level API then we maybe would just as well go to plain http client calls.

For our purposes it would be ideal to allow both; having a way to set/pass through headers and other request details; yet, also allow us access to a higher level API abstraction to manipulate/augment when desired.

Any suggestions?

Thanks,
Andi

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2877010
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Client abstraction

jlouvel
Administrator
Hi Andi,

Thanks for the feed-back on the dynamic capabilities of Restlet. Note that
those capabilities combined with OSGi dynamic features make a great
combination (see new OSGi edition and upcoming OSGi extension).

Back to your question. As Restlet is both a client-side and server-side API,
you can perfectly take the Request instance received and pass it to a client
connector with no modification beside the target resource URI and any
property you want to set or update. You don't need to recreate a Request
from scratch. The Redirector class provides a simple reverse proxy working
just like that.

Also, it is possible to create a ClientResource by wrapping an existing
Request object that will serve as a prototype object to be cloned for each
call.

Best regards,
Jerome
--
http://www.restlet.org
http://twitter.com/#!/jlouvel



-----Message d'origine-----
De : Andreas Egloff [mailto:[hidden email]]
Envoyé : jeudi 10 novembre 2011 19:02
À : [hidden email]
Objet : Client abstraction

We're happy campers with the server side capabilities Restlet provides us;
particularly the dynamic ability to define and register resources has set
this apart from other (to remain unnamed) frameworks we used. This is
crucial in the declarative and pluggable environment we have.

Now I have a question on the client abstraction though in Restlet.

In our use cases it is common that we're essentially proxying some kind of
RESTful call. We may be augmenting some of the call details (e.g.
authentication, additional headers etc), or these may already be contained
in the original caller's details.

If we use the client resource abstraction that gives us a nice interface for
when we need to augment the request (e.g. setting basic auth settings). But,
it also explicitly prevents us from passing through/setting headers directly
if the same header is also exposed through the API. If we drop down to a
lower level API then we maybe would just as well go to plain http client
calls.

For our purposes it would be ideal to allow both; having a way to set/pass
through headers and other request details; yet, also allow us access to a
higher level API abstraction to manipulate/augment when desired.

Any suggestions?

Thanks,
Andi

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=28770
10

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2877261
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Client abstraction

Tim Peierls
On Fri, Nov 11, 2011 at 10:25 AM, Jerome Louvel <[hidden email]> wrote:
Also, it is possible to create a ClientResource by wrapping an existing
Request object that will serve as a prototype object to be cloned for each call.

Is that the ClientResource(Request, Response) constructor? Or something else?

--tim
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Client abstraction

jlouvel
Administrator

Hi Tim,

 

Yes, this is the right constructor to use! Just pass “null” for the response.  

 

In addition, I also added new constructors with the Response parameter in SVN trunk to make this usage easier.

 

Best regards,
Jerome
--

http://www.restlet.org

http://twitter.com/#!/jlouvel

 

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Tim Peierls
Envoyé : vendredi 11 novembre 2011 16:47
À : [hidden email]
Objet : Re: Client abstraction

 

On Fri, Nov 11, 2011 at 10:25 AM, Jerome Louvel <[hidden email]> wrote:

Also, it is possible to create a ClientResource by wrapping an existing
Request object that will serve as a prototype object to be cloned for each call.

 

Is that the ClientResource(Request, Response) constructor? Or something else?

 

--tim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Client abstraction

jlouvel
Administrator
In reply to this post by Tim Peierls

I meant “without the Response parameter”.

 

Cheers,

Jerome

 

De : Jerome Louvel [mailto:[hidden email]]
Envoyé : vendredi 11 novembre 2011 16:50
À : 'discuss'
Objet : RE: Client abstraction

 

Hi Tim,

 

Yes, this is the right constructor to use! Just pass “null” for the response.  

 

In addition, I also added new constructors with the Response parameter in SVN trunk to make this usage easier.

 

Best regards,
Jerome
--

http://www.restlet.org

http://twitter.com/#!/jlouvel

 

 

 

De : [hidden email] [hidden email] De la part de Tim Peierls
Envoyé : vendredi 11 novembre 2011 16:47
À : [hidden email]
Objet : Re: Client abstraction

 

On Fri, Nov 11, 2011 at 10:25 AM, Jerome Louvel <[hidden email]> wrote:

Also, it is possible to create a ClientResource by wrapping an existing
Request object that will serve as a prototype object to be cloned for each call.

 

Is that the ClientResource(Request, Response) constructor? Or something else?

 

--tim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Client abstraction

Tim Peierls
Gotcha, thanks.

I don't want to be a nag, but could you (in both of those constructors, new and old) indicate in the javadocs that the arguments are used as prototypes?

--tim

On Fri, Nov 11, 2011 at 11:16 AM, Jerome Louvel <[hidden email]> wrote:

I meant “without the Response parameter”.

 

Cheers,

Jerome

 

De : Jerome Louvel [mailto:[hidden email]]
Envoyé : vendredi 11 novembre 2011 16:50
À : 'discuss'
Objet : RE: Client abstraction

 

Hi Tim,

 

Yes, this is the right constructor to use! Just pass “null” for the response.  

 

In addition, I also added new constructors with the Response parameter in SVN trunk to make this usage easier.

 

Best regards,
Jerome
--

http://www.restlet.org

http://twitter.com/#!/jlouvel

 

 

 

De : [hidden email] [hidden email] De la part de Tim Peierls


Envoyé : vendredi 11 novembre 2011 16:47
À : [hidden email]
Objet : Re: Client abstraction

 

On Fri, Nov 11, 2011 at 10:25 AM, Jerome Louvel <[hidden email]> wrote:

Also, it is possible to create a ClientResource by wrapping an existing
Request object that will serve as a prototype object to be cloned for each call.

 

Is that the ClientResource(Request, Response) constructor? Or something else?

 

--tim


Loading...