Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] rest API work 
Hi Andre,

Andre Dietisheim wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Scott


This can/could be fairly easily done (i.e make it an option to create a
new HttpClient or reuse an existing one), but it would be an addition. Please open an enhancement request to this effect (i.e. 'reuse 
httpclient for rest calls' or something like that), and we'll get to it.


I filed a new bugzilla entry:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=297062

I wonder if there's any good reason to create a new instance on each
call.   What prohibits ECF to reuse a httpClient instance? Do I miss
something?
Just tell me wich solution you'll opt for and I'll be glad to provider a
patch.


Hi Andre.
I had originally intended to allow subclasses (of RestClientService class) to override the creation of HttpClient instances (one per call)...but this was mistakenly left out (i.e. HttpClient httpClient = new HttpClient). So, to make it possible for subclasses of RestClientService to override the default behavior I introduced a new protected method:
protected HttpClient getHttpClientForCall(HttpMethod httpMethod, IRemoteCall call, IRestCallable callable) { // By default, create a new HttpClient instance for every request. return httpClient; 
   }
The intention is that subclasses can override this behavior if they wish...e.g. to reuse an HttpClient for all calls. This change is now committed to HEAD.
Now the question is: what should the default behavior be in RestClientService? (i.e. a separate HttpClient for each call, or one that is shared for all calls)? My initial inclination was that the default should be a new HttpClient for each call (i.e. creating/returning a new one each time getHttpClientForCall is called), but I think upon reflection that having an HttpClient that is reused for each call is probably a better default...and so I've changed the default implementation in RestClientService to reuse the httpClient (created upon construction) for each call. Subclasses may override this behavior simply by implementing getHttpClientForCall in a different manner (i.e. returning a new HttpClient for each instance). 


- - I need to be able to elaborate on the specific HTTP error.In some
cases my REST service answers 404 to signal me that there's no
information present. I'll have to react by not showing any information
for this call. On the other hand I'd have to popup an error for any
other error that may occur (authentication, transport etc.). I'd suggest
to pass an IStatus to the ECFException instead of a plain string. I'll
then be able to fetch it's code.

The newly revised RestClientContainer and RestClientService classes
can/would/do allow subclassing to implement alternative strategies for
particular rest APIs...e.g. for handling http responses in custom ways
for a particular rest api.   That is, it's intended that for *some* rest
clients, subclasses of RestClientContainer and RestClientService might
be created to customize the runtime behavior (since rest is more a
family of protocols than it is a single protocol).
In addition, it's possible that we could introduce some more flexibility
into these classes....e.g. RestClientService...through some
generalization of the protected and public methods...or by introducing
interfaces for delegation.



sound good! I'll catch up with the latest incarnation and try to
subclass to get what I need.
On the other hand, I wonder here too, if there's any good reason to
deliberately loose the error code. What do I miss?
I've introduced an new class: RestException that provides access to the error code. This is/also been committed to HEAD. It allows receivers/handlers of the RestException to get at the error code if they wish. 


Hi Scott, Hi Holger

sorry, for being too quick with my posts. I guess your API suggests to
subclass IRestCallable and augment it to have request entities.
Am I right?
Well, unfortunately I don't think subclassing RestCallable will properly do the trick WRT request entities...so we probably need to figure out how to allow people to specify a RequestEntity for post parameter in some way that is not yet in the API. I removed it from the old API for simplicity...but I think I forgot to put it back in.
I agree that there should be some way of specifying that a RequestEntity is to be used for post requests, but I'm not clear on the 'best' or 'clearest' way to represent it in the API. Any thoughts/comments would be appreciated...and we will get it back in there. 

Scott


Thanks + Cheers!
André

- --
André Dietisheim
Head of Eclipse Development

Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00
Fax     +41 31 370 22 01
Mobile  +41 76 423 03 02

Abonnieren Sie unsere News:
<http://www.puzzle.ch/follow-us>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdATMACgkQxpTsx9UecrlGngCfVWbkXAoSOUedFUHbH+c76lVc
wkcAoMgac8zsfzvsauVVCdXaMFkYGrW4
=joLo
-----END PGP SIGNATURE-----
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top