Re: [xwiki-devs] GSOC idea: RESTful XWiki

On 5 mars 08, at 11:07, Vincent Massol wrote: It's not just a problem of "uri syntax". It's a semantic problem. REST applied to the WEB prescribes that the HTTP uniform interface (and its semantics) should be used to access resources. Now if you have http://site/space/page/action/delete and you do a GET on it you are actually *deleting* a page. So basically you are subverting the semantics of the HTTP interface that says that GET is safe (doesn't have side effects on the resource state) and idempotent and returns a representation of the resource identified by the URI. This is valid for every "action" encoded in the URI (this is why I was saying that REST talks about nouns and not actions). Basically, by doing this (encoding an action in the URI), you "transfer" the semantics of the request from the HTTP method to the URI and that's not what REST says. Doing this kind of things is detrimental. Sometimes ago Google released this web-accelerator product that basically built a cache by performing GET requests in background. A sort of local crawler for speeding up the navigation. It has to be retired because people were implementing things in a non RESTful way (i.e., by subverting the semantics of HTTP through URIs). What happened is that the crawler, when was GETting some URI like the one you wrote, it was actually *modifying* the underlying resource. People were loosing data! So my proposal was in the direction of building a pure RESTful XWiki, as much as possible (i.e., one that comply with the HTTP semantics), not an hybrid thing (like many services that are already present: flickr, delicious, etc.). This is not interesting from my point of view and was not the spirit of my proposal. I understand, however, that this goal might be a bit "academic" and too research-oriented and might not be well suited for. But doing what you proposed, i.e. automatically generating a URI based API by simply encoding the backend API calls in URIs is not REST, and might do more harm than good. Indeed. Maybe it's going to be very complex. Being RESTful has tons of advantages but this comes at a price. A complete change of perspective. When designing RESTfully you stick to a fixed "client API" that is the uniform interface you choose, and on the Web is: class ClientAPI { Response GET(Request r); Response PUT(Request r); Response DELETE(Request r); Response POST(Request r); } With http://www.w3.org/Protocols/rfc2616/rfc2616.html as the "Javadoc" :) Then you start mapping what a POST or a GET or a DELETE on a given URI means in terms of your backend API (e.g., the XWiki API), in order to generate the Response. But the client has to see and use that API with the given semantics. I was saying that the WebDAV proposal was similar because in this case you would have this: class ClientAPI { /* HTTP */ Response GET(Request r); Response PUT(Request r); Response DELETE(Request r); Response POST(Request r); /* WebDAV */ Response PROPPATCH(Request r); Response PROPFIND(Request r); Response MKCOL(Request r); Response COPY(Request r); Response MOVE(Request r); Response LOCK(Request r); Response UNLOCK(Request r); } With http://www.w3.org/Protocols/rfc2616/rfc2616.html and http://www.webdav.org/specs/rfc2518.html as the corresponding "Javadocs". But still you have to design what can be GETted, PROPPATCHed, LOCKed, i.e., the URI space and what this means. To conclude, I am not saying that the automatic generation of URI mapping is bad (people are doing it most of the time and time) But from my point of view, the two proposals are totally different. This is the reason why I didn't agree with Sergiu: it's not just a question of implementation but rather a question of design. Anyway, nice discussion! This is really interesting and helps me to better understand these concepts that are not easy at all and sometimes very blurred :) Cheers, Fabio