5 Mar
2008
5 Mar
'08
9:59 a.m.
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?
In the REST approach we would call this very same method in order to
authenticate a request on a URI
that is "protected", for example a PUT on a http://site/space/page.
But maybe I have misunderstood something.
Anyway, what is done in the "backend" doesn't prevent the fact that
you must
expose a URI space for addressing xwiki resources. This URI space
engineering is the first step and doesn't involve implementation
details [1].
Also, this should be done in the new component-based
architecture.
Of course.
But I was not talking about implementation details in my previous email.
How's that for a nice SoC project?
Actually I have a problem with another project proposal...
I think there is some overlapping between the WebDAV and RESTful XWiki
proposal because the description in
http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService
is exactly what I called "resource namespace engineering" in a
previous message, and it's an integral part (actually it is the
foundation) of the RESTful XWiki proposal.
In fact for the RESTful XWiki we need a "view" of the XWiki system in
order to make XWiki elements addressable through URIs that can be
referenced by HTTP methods GET, PUT, POST, DELETE and, in case, by
WebDAV methods PROPPATCH, PROPFIND, MKCOL, COPY, MOVE, LOCK, UNLOCK.
Whenever a method is applicable, of course.
So maybe the WebDAV and RESTful XWiki are actually the *same* proposal.
WDYT?
Cheers,
Fabio
[1] http://www.infoq.com/articles/rest-introduction