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