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
[EMAIL PROTECTED]
http://wagenknecht.org/
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
