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 [EMAIL PROTECTED] http://wagenknecht.org/ _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
