On 5 mars 08, at 10:11, Vincent Massol wrote: > > On Mar 5, 2008, at 9:59 AM, Fabio Mancinelli wrote: > >> >> On 4 mars 08, at 16:23, Sergiu Dumitriu wrote: >> >>>>> >>>> There is a long debate about REST vs. SOAP (the comparison here >>>> is a >>>> bit wrong since REST is not a protocol), anyway REST and WS à la >>>> SOAP >>>> are two ways of doing WebServices that exploit rather opposite >>>> paradigms. So definitely I would say that we DO NOT want to do >>>> SOAP! :) >>> >>> No, I would say that we'd rather have REST at this point as it has >>> more >>> direct benefits than SOAP, since REST does not need special tools to >>> be >>> used by simple users, while SOAP is mostly for machines. >>> >>> But I think that this project should not be done this way. It will >>> mean >>> that we'll have the application login in 4 places (struts, xmlrpc, >>> gwt, >>> reast). I'd rather we created a distinct application logic layer >>> which >>> can be used by all these communication interfaces (this is what they >>> are, communication interfaces, and they should not contain logic). >>> If we >>> do this, then adding a SOAP protocol would be as simple as creating >>> the >>> listeners and the bridge to the application logic (2 weeks of work >>> at >>> most?). And it will be a little easier to update all the protocols >>> at once. >> >> Not sure of understanding what you say here. >> The XMLRPC login already uses, for example, the >> xwiki.getAuthService().authenticate method. >> Isn't this already the application logic layer you are talking about? >> Why do you need another? > > What I'd like to see is a common description of APIs in a language > neutral format (like XML) and then have generators (build time or > runtime) that generate the bridge layer for the different technology > (REST, XMLRPC, SOAP, etc). > The problem here is that a REST solution and a SOAP one are incompatible. I am talking of pure-REST of course. REST talks about nouns, SOAP/ XMLRPC/etc. talk about verbs (the API).
To me something like http://site/space/page?action=delete is NOT RESTful. So the "interface to the RESTful XWiki" (or more correctly the URI space) cannot be generated on the fly simply by exposing APIs encoded using URIs. This is not the RESTful XWiki I was talking about (actually it's not even REST). In fact, by doing this we would just introduce another XMLRPC API in disguise, and that's not interesting. Anyway, since there is already a misunderstanding at the possible mentoring meta-level :) maybe we should rule out this proposal and go for the WebDAV one that is already something that matches what I was originally proposing :) Cheers, Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
