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) 
Michael,

Comments below.

Michael Scharf wrote:

Hi Martin,
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.
I can't claim to be an expert either although I've been claiming EMF's resource "model" is fully RESTful as of EMF 2.4 with the addition of support for delete. 
Here is how I think
it could help. Let's look at the properties described in:
http://en.wikipedia.org/wiki/Representational_State_Transfer#Principles:

That's exactly the point about REST.  It's a set of principles.


> * Application state and functionality are abstracted into resources

well files are naturally resources.....

Yep, and in EMF we call them Resource to make it simple. :-P


> * Every resource is uniquely addressable using a universal syntax
>   for use in hypermedia links

this we have at the EFS layer.....
Yes, and similarly each EMF resource has a getURI. We also hook into the platform's workspace (platform:/resource), EFS directly (any EFS-registered schema), the file system (file:), nested archives (archive:<URI>!/path1/x.jar!/path2/file), and any arbitrary URL (http:). 

> * 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)).
Technically move/rename can be accomplished with PUT and DELETE. EMF delegates all state transfer to a URI converter, i.e., createInputStream, createOutputStream, delete, exists, get/setAttributes, contentDescription are the small number of well-defined operations. 


>     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.
EMF's content type support is very similar to the platform's and generally delegates to the platform when the platform is present. 

> * 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
All persistent state is maintained by the server and as you say, the server doesn't know the state of the client. It's often a confusion that the server is stateless when obviously the server is the thing maintaining the state. A server might even allow files to be locked by a client; I think that would still be RESTful, but obviously could get into problems if a client fails to reset that state... 

>     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.
I think the discussions about isSynchronized represent some issues related to caching. 


>     o Layered

layering and caching comes from the fact that REST is
stateless.
In the end, EMF resources don't care nor know anything about what's happening within the URI converter in order to fetch and alter the state of the persistent store. 


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.
Or rather a view of it. A server without clients accessing the state would be like the tree falling in the forest without anyone to hear it... 
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.
EMF provides access to timestamps and a resource's timestamp is set during loading and saving. All this to support things like optimistic concurrency. 


Or am I misunderstanding?


For me the key attributes are the statelessness and the fact that
caching is part of the architecture.

I'd also argue the small number of well-defined operations is important.


Here is a naive approach. Suppose we would use http as
a protocol:
- each file has a URI
- directories return list of file URIs (that is
  efficient because it can just return relative
  URIs)
I've never figured out a uniform way to access folders. It's quite sad. :-( 
- 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.
I'm not sure I get this part. I assume by state here you mean state attributes, like timestamp, as opposed to the state of the content... 
- 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....

So the ports aren't blocked by over zealous admins...


But I am not a REST expert. So, I don't have a strong opinion
here....

What you describe pretty much matches my understanding too.


Michael


Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Scharf 
Sent: Friday, October 17, 2008 6:11 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] [resources] REST (Representational StateTransfer) 

In the call today some asked for some links to an introduction
to REST. Wikipedia is a good starting point:
   http://en.wikipedia.org/wiki/Representational_State_Transfer

Some important attributes of the RESTful approach is:
     * Client-server
     * Stateless
     * Cacheable
     * Layered

Here is a podcast (~1h) introducing the REST concepts (and some links):
http://www.se-radio.net/podcast/2008-05/episode-98-stefan-tilkov-rest 
e.g.:
   http://www.infoq.com/articles/rest-introduction

Michael
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

Back to the top