Fabio Mancinelli wrote: > On 5 mars 08, at 11:07, Vincent Massol wrote: >>> To me something like http://site/space/page?action=delete is NOT >>> RESTful. >> Yes I agree but how is that incompatible? >> >> You can easily rewrite it to http://site/space/page/action/delete, no? >> >> Isn't it possible to conceive of an automatic transformation by using >> a rule such as: >> for each API method parameter, take the parameter name, add "/" and >> then add the parameter value? >> > > 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. > >> Note that this is pure brainstorming at this stage since I have never >> done that and I have no idea if it's doable or not. I tend to think >> it's going to be too complex but still we need to consider this way of >> doing things even if in the end we conclude that we're not going to >> use it for such and such reason. >> > 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.
No, we didn't quite disagree. I was not talking about the implementation, but about the design of the implementation. If we would write some restlets, then they would do what? Let's say we have the URL http://server/Space/Page/ and do a: - GET: duplicate some of the code in ViewAction - PUT: duplicate some of the code in SaveAction - DELETE: duplicate some of the code in DeleteAction - POST: duplicate some other code in SaveAction - HEAD: write some new code, as this is not done yet So I was saying that when designing the URLs, we should redesign the application logiC (and this is something you implied, too), but put it not in the restlets, but in another layer, so that it can be reused by other protocols. You do agree that we can't just design new URLs (or should we say IRIs?), without designing the logic behind them. Currently the logic is spread around all the platform. There is code in the Struts actions, in the XWiki giant, in the data model, in templates, in documents, in plugins (FileUpload, for example), so writing restlets that reuse this spread logic will be very inefficient: - search all around the code to see how to do something - duplicate code - copy the bugs along with the code - increase even more the mess And we can't just completely replace the servlets (and their URLs) with the new REST approach, as all the bookmarks and knowledge about the URLs would be broken, so people will not upgrade. So we either reimplement them using the new app logic layer, or write an URL rewrite engine that forwards to the new IRIs. > 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 -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
