Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-incubator-e4-dev] Re: [resources] REST (Representational StateTransfer)

Hi,

Oberhuber, Martin schrieb:
> 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.

I do have some REST background and you asked a very good question.
Although REST typically applies to Client/Server communication it is
important that the underlying APIs are stateless as well. As others
already mentioned, the "state" is a different "state".

It's the state related to a "user" ("application", "client") session.
IResource#isSynchronized is state related to a workspace, i.e. all
workspace users are affected by the state. If one user refreshes the
resource, it will be synchronized for all users.

Another example (although not supported by the resource API) are
transactions. They maintain "user" state, i.e. a user starts a
transaction, changes resources and eventually commits it later. During
the transaction the server has to maintain transactional state for that
particular "user". Therefore, it's impossible to turn this into a
RESTful service.

But REST still allows ACID. This may be imported for a RESTful resource
service. Typically, the atomicity of a RESTful HTTP service is defined
by the targeted resource.

Another interesting read is this one:
http://www.artima.com/lejava/articles/why_put_and_delete.html

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/



Back to the top