Skip to main content

[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

Back to the top