[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-incubator-e4-dev] [resources] REST (Representational StateTransfer)
|
On Oct 20, 2008, at 1:13 PM, Oberhuber, Martin wrote:
this is very interesting, but I don't currently understand
how REST would map to what we do in Resources.
Could somebody with a RESTful background help out?
For now, I just have a faint feeling that a client/server
architecture where an Eclipse Workspace is located on a
server and a local client interacts with that workspace
through an RPC-Style IResource API would likely *not*
be RESTful, because the Eclipse Workspace maintains State
(e.g. IResource#isSynchronized()) whereas a RESTful system
needs to be stateless.
Or am I misunderstanding?
IResource#isSynchronized() is perhaps a bad API to be considering
here. I'm not familiar with the Eclipse APIs, but the javadoc says
"returns whether this resource and its descendents to the given depth
are considered to be in sync with the local file system." What is the
"local file system" in this case? The file system the RESTful client
is running on? Or is there a "local file system" running on the
server, as well as a "workspace".
In the first case, isSynchronized() doesn't make any sense on the
server, since the server can't know what's actually on the client
machine, unless it's tracking the state of the client (ie, is
stateful, which you want to avoid in the RESTful world).
In the second case, the API makes sense, but I don't know that it
makes sense to maintain a "workspace" AND a "local file system" copy
of the workspace on the server.
I think we need to have a definition of what we're talking about w/r/t
workspaces and such in the web-based world. Since Eclipse is heavily
"file" based, we also need to consider whether we're talking about
running in a traditional web browser or not, as web browsers don't
have an easy way to access the local file system. Or you already
defined all this and I missed it.
None-the-less, the "stateless" bit of REST is application state, not
resource state. Resources can change state, no problem. The server,
however, should not maintain the state of the application, the client
should.
Patrick Mueller
http://muellerware.org/