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:
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

  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.


Back to the top