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