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