Re: [eclipse-incubator-e4-dev] [resources] REST (Representational StateTransfer)
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?
I do not have a RESTful background. Here is how I think
it could help. Let's look at the properties described in:
> * Application state and functionality are abstracted into resources
well files are naturally resources.....
> * Every resource is uniquely addressable using a universal syntax
> for use in hypermedia links
this we have at the EFS layer.....
> * All resources share a uniform interface for the transfer
> of state between client and resource, consisting of
> o A constrained set of well-defined operations
HTTP has POST, GET, PUT and DELETE. Well MOVE/RENAME would
be helpful as well (I really don't understand why such a
fundamental operation is missing in HTTP (I think WebDAV
adds those methods)).
> o A constrained set of content types, optionally
> supporting code on demand
If the remote site has files compressed or encoded
in a special form and the client communicates which forms
it understands. If the client does not have a decoder, then
then the server could do the decoding. Or if the client
supports compression then the server could send data compressed.
> * A protocol which is:
> o Client-server
> o Stateless
Stateless means that the server does not remember a state of
the client. Protocols that include state are often much
more complicated because the client
> o Cacheable
that is interesting, because caching not trivial. The
http world has very successfully shown how caching works
and how this can improve performance.
> o Layered
layering and caching comes from the fact that REST is
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.
Stateless means stateless on the server. The server does
not maintain the state of the client. The client might
maintain the state of the server. In http there there are
ETag and times stamps used to minimize the transfer of resources
from the server to the client. IResource#isSynchronized() would
then check if the client resource is the same as on the server.
With http one would use GET with a If-Modified-Since or If-None-Match
header. This means the server would only return the resource
if its state has changed.
Or am I misunderstanding?
For me the key attributes are the statelessness and the fact that
caching is part of the architecture.
Here is a naive approach. Suppose we would use http as
- each file has a URI
- directories return list of file URIs (that is
efficient because it can just return relative
- we use ETag to represent the state of a file or
directory. The client has to poll the state, but
it could use a If-None-Match header.
- caching could be done locally using an efficient
cache like squid
- users behind a firewall could use this remote file system
There might be more efficient ways of implementing a
remote file system, but I like the idea of having a simple
universal set of operations....
I think this is one of the differences between subversion
and CVS is that subversion uses http....
But I am not a REST expert. So, I don't have a strong opinion
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
Behalf Of Michael Scharf
Sent: Friday, October 17, 2008 6:11 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] [resources] REST
In the call today some asked for some links to an introduction
to REST. Wikipedia is a good starting point:
Some important attributes of the RESTful approach is:
Here is a podcast (~1h) introducing the REST concepts (and
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev mailing list