5 Mar
2008
5 Mar
'08
10:48 a.m.
On 5 mars 08, at 10:11, Vincent Massol wrote:
On Mar 5, 2008, at 9:59 AM, Fabio Mancinelli wrote:
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
On 4 mars 08, at 16:23, Sergiu Dumitriu wrote:
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).
>
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.