[
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
while working with the existing API (by Holger) I noticed some issues,
I'd love to get your feeback on and hopefully get a solution for my
usecase. The issues exist in the former incarnation and your new
implementation. I did not use your new version yet, just looked through
the code:
- - The current implementation allways creates a fresh instance of the
httpClient:
RestClientService:
protected Object callHttpMethod(final IRemoteCall call, final
IRestCallable callable) throws ECFException {
String uri = prepareRequestURI(call, callable);
HttpMethod httpMethod = createHttpMethod(uri, call, callable);
// add additional request headers
addRequestHeaders(httpMethod, call, callable);
HttpClient httpClient = new HttpClient();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I need the httpClient to be reused in order to keep the HTTP session
state and so that existing cookies are re-sent in a later call.
As far as I understand the code so far the user programmer holds the
instance of the RestClientService.and may decide whether to reuse it or
not. It should therefore be sufficient to move the httpClient to an
instance variable of RestClientService.
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 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.
Scott
