[eclipse-incubator-e4-dev] Re: [resources] REST (RepresentationalStateTr

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Oberhuber, Martin schrieb:
> I guess I get the meaning of "stateless" now :-)

I guess the last missing piece is the "request" scope. I think it's hard
to draw a strong line here because the "request" scope is different for
an HTTP REST services than a regular API call.

> Hm, so what would that mean for WorkspaceModifyOperation?
> Isn't that a transaction in some sense? Also, what does it
> mean for the Visitor pattern... isn't that also embedding
> client state in some sense? See IResourceProxyVisitor,
> IResourceVisitor

I don't think that a HTTP REST service would actually expose
WorkspaceModifyOperation, IResourceProxyVisitor, IResourceVisitor & co.
It would expose functionality on a higher level.

Example:
GET
/resources/myworkspace/myproject/?patter=*.java&include=hidden&depth=infinite&result=name,modificationStamp

This would be the request to a HTTP REST service. The service
implementation would create a IResourceProxyVisitor and traverse
"myproject" in "myworkspace" and return a list of names including their
modification stamps.

There is no "user" state which needs to be maintained by the resource
API across the IResource#accept call.

There is also no "user" state which needs to be maintained by the HTTP
REST service across the GET request.

> So, if transactions are out of reach, how would larger 
> modifications to a workspace be done but consistency
> still be ensured?

They are not out of reach. They just have a fixed atomicity for a HTTP
REST service.

Examples:
(1) DELETE /resources/myworkspace/myproject/myfolder/myfile
(2) DELETE /resources/myworkspace/myproject/myfolder/
(3) DELETE /resources/myworkspace/myproject/

In (1) your atomicity is the file whereas in (2) it's the folder and in
(3) it's the whole project.

What you can't do is

a. POST /resource/api/transaction/start
b. DELETE /this
c. PUT /that
d. DELETE /blah
e. GET /that
f. POST /resource/api/transaction/stop

This would require to maintain state about the transaction on the
server. Some implement it by returning a transaction id in (a) and then
submitting it back in (f) but I think it's questionable if this can be
called RESTful. For the individual calls this might be true but for the
whole process it's questionable. Suddenly the server has to monitor
activity, track open transactions, rollback timed out transactions, etc.

-Gunnar


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