Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-incubator-e4-dev] Re: [resources] REST(RepresentationalStateTransfer)

Oberhuber, Martin schrieb:
> So, from your experience... does it make sense to
> work on API being more RESTful or not? 

Definitely. Creating RESTful APIs helps with implementing a stateless
server which just scales better than a server that needs to synchronize
state with others.

> Or am I misunderstanding, because it doesn't make sense
> to try and use similar APIs for "local" and "remote"
> scenarios anyways (as Scott has mentioned)? In other
> words, would a remote-enabled workspace work totally
> different than a local one anyways?

>From my experience it does not always make sense to expose the same
local API to a remote client. Well, you certainly can do this.

> But how would clients then write code which they intend
> to be using in both Local and Remote workspace scenarios?
> Would they code against the Remote Service only and have
> a "local server" translate that into local calls?

I'm not quite sure I understand that requirement correctly. Of course,
you can implement an IResource remote API which emulates as much as
possible from a local IResource API. However, the implementation would
not be RESTful as a whole. Some parts of the API can be implemented
RESTful but others may require to keep state on the server when
communicating with the server requires multiple different requests.

I wonder if there is also a whole new layer of API complexity here. IMHO
the idea of a RESTful API exposed as a service over HTTP introduces a
new HTTP API. Other non-Java clients might find it interesting to make
use of this API. A Java client may use the HTTP API to implement a
subset of the IResource API. This would at least make it easy for Java
based clients because you can define a subset of the resource API which
works locally as well as remotely.

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/



Back to the top