GSOC idea: RESTful XWiki

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GSOC idea: RESTful XWiki

Fabio Mancinelli-4
Hi everybody,

since I've mentioned it in a previous email almost as a joke, maybe it  
could be interesting to propose it in a more serious way as a GSOC  
project.

So the idea is to implement the infrastructure for exposing XWiki as a  
fully RESTful WebService for example by using RestLet. This can have  
some repercussions even on semantic features that Stèphane was  
proposing on the chat.

It might be interesting to implement a separate module that leverages  
the XWiki API and exposes it in a RESTful way and build on top of it  
some semantic infrastructure. Since in this scenario everything will  
have an URI, it should be easier to leverage RDF and other semantic  
frameworks.

This is just an idea to be worked on, if we are interested of course :)

WDYT?

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Asiri Rathnayake
Hi,

On Tue, Mar 4, 2008 at 2:28 PM, Fabio Mancinelli <[hidden email]> wrote:
Hi everybody,

since I've mentioned it in a previous email almost as a joke, maybe it
could be interesting to propose it in a more serious way as a GSOC
project.

So the idea is to implement the infrastructure for exposing XWiki as a
fully RESTful WebService for example by using RestLet.

First of all, I'm pretty new to this topic. But please help me clear some of my doubts. :)

What functionality of XWiki will be exposed via the new WebService ? same stuff as in XMLRPC ? or more ?

And why REST and not SOAP ?

This can have
some repercussions even on semantic features that Stèphane was
proposing on the chat.

Can we discuss those here as well ? :)

Thannks a lot.

- Asiri
 

It might be interesting to implement a separate module that leverages
the XWiki API and exposes it in a RESTful way and build on top of it
some semantic infrastructure. Since in this scenario everything will
have an URI, it should be easier to leverage RDF and other semantic
frameworks.

This is just an idea to be worked on, if we are interested of course :)

WDYT?

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator
In reply to this post by Fabio Mancinelli-4
Definitely a good idea.

Could you please create a project page for it on
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ ?

Thanks
-Vincent

On Mar 4, 2008, at 9:58 AM, Fabio Mancinelli wrote:

> Hi everybody,
>
> since I've mentioned it in a previous email almost as a joke, maybe it
> could be interesting to propose it in a more serious way as a GSOC
> project.
>
> So the idea is to implement the infrastructure for exposing XWiki as a
> fully RESTful WebService for example by using RestLet. This can have
> some repercussions even on semantic features that Stèphane was
> proposing on the chat.
>
> It might be interesting to implement a separate module that leverages
> the XWiki API and exposes it in a RESTful way and build on top of it
> some semantic infrastructure. Since in this scenario everything will
> have an URI, it should be easier to leverage RDF and other semantic
> frameworks.
>
> This is just an idea to be worked on, if we are interested of  
> course :)
>
> WDYT?
>
> Cheers,
> Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4
In reply to this post by Asiri Rathnayake

On 4 mars 08, at 13:27, Asiri Rathnayake wrote:

> First of all, I'm pretty new to this topic. But please help me clear  
> some of my doubts. :)
>
> What functionality of XWiki will be exposed via the new WebService ?  
> same stuff as in XMLRPC ? or more ?
>
Basically the idea is to make XWiki interoperable and addressable  
using the REST architectural style principles.

At a high level of abstraction, yes the services will be provide the  
same functionalities of XMLRPC.
But in a REST oriented solution the "interface" will be the one  
provided by HTTP (the 4 verbs), not a custom API like the one already  
present in the XMLRPC extension.

> And why REST and not SOAP ?
>
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! :)

To be concise the idea, following rest principles, is:
1) Give every XWiki resource an ID (i.e., an URI)
2) Make everything accessible through a uniform interface (i.e. HTTP  
or WebDAV)

This implies:
1) Do some "resource" engineering in order to well define the URI space
2) Think about resource representations
3) Build the "business logic" to map the new way of accessing resources.

Just an example for what it could look like.

GET http://site/spaces -> gets the list of the available spaces
POST http://site/spaces [SPACEINFO] -> create a new space
DELETE htp://site/spaces/foo -> delete space foo
PUT http://site/spaces/foo [SPACEINFO] -> Update space info (like  
description, etc.)
etc.

The trick here is that you have all the relevant things directly  
addressable and accessible through a uniform interface (i.e., HTTP or  
WebDAV). You will be able, for example, to say something like
"GET http://site/space/page/object/field" and retrieve the value of  
the field of the object associated with a given page on a given space.  
Doing a PUT on that URI will set the value.

Currently you have to do something like:
XMLRPCClient
.getSpace
("space").getPage("page").getObject("Object").getField("field");

The uniform interface (HTTP) allows you also to write the previous URI  
in a browser instead of compiling java code with brittle APIs :) An it  
would work :)

Of course this is only the tip of the iceberg (and of the problems :))


> This can have
> some repercussions even on semantic features that Stèphane was
> proposing on the chat.
>
> Can we discuss those here as well ? :)
>
Yes :)

The foundation of RDF and all the semantic frameworks (à la semantic  
web) are the fact that "things" can be expressed and referenced  
through URI.

In RDF, in fact, triples that establish relationships between thing  
are in the form

SubjectURI PredicateURI [ObjectURI | Literal]

To be more concrete I might say something like:

person://fabiomancinelli http://ontology/fullname "Fabio Mancinelli"
That basically states that my name is "Fabio Mancinelli", provided  
that person://fabiomancinelli is the URI that identifies the "physical  
person" that's me.

Now, by exposing XWiki resources in a RESTful way we are basically  
exposing all the relevant XWiki "things" via a URI. We can use those  
URI for describing semantic relationships. So we could say something  
like

http://site/space/page http://ontology/tag http://ontology/Technology
http://site/space/page http://ontology/tag http://ontology/News

In order to state that a given page has the Technology and News tags.

Of course I've been very concise because it's not that easy and what  
I've described requires a lot of effort despite its simplicity.

But if the engineering is done well this could result in a very  
powerful extension.

It would be nice to send an email saying:

"Hey Asiri look at the paragraph http://site/space/page/paragraph/1 
and review it", then you do a "PUT on http://site/page/paragraph/1"  
and boom, the page will be updated reflecting the changes you did with  
respect to that paragraph. :)

I hope that I've been clear.
I know that's a not easy topic and it has a lot of nuances.

Feel free to ask other questions.

> Thannks a lot.

You are welcome.

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4
In reply to this post by vmassol

On 4 mars 08, at 14:02, Vincent Massol wrote:

> Definitely a good idea.
>
> Could you please create a project page for it on
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ ?
>
> Thanks
> -Vincent
>

Hi Vincent,

there is already an "XWiki Pure REST Api (compatible with GWT Apis,  
XML-RPC, SOAP)" but I don't understand where the corresponding project  
page is.

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Asiri Rathnayake
In reply to this post by Fabio Mancinelli-4
Hi,

On Tue, Mar 4, 2008 at 6:36 PM, Fabio Mancinelli <[hidden email]> wrote:

On 4 mars 08, at 13:27, Asiri Rathnayake wrote:

> First of all, I'm pretty new to this topic. But please help me clear
> some of my doubts. :)
>
> What functionality of XWiki will be exposed via the new WebService ?
> same stuff as in XMLRPC ? or more ?
>
Basically the idea is to make XWiki interoperable and addressable
using the REST architectural style principles.

At a high level of abstraction, yes the services will be provide the
same functionalities of XMLRPC.
But in a REST oriented solution the "interface" will be the one
provided by HTTP (the 4 verbs), not a custom API like the one already
present in the XMLRPC extension.

> And why REST and not SOAP ?
>
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! :)

To be concise the idea, following rest principles, is:
1) Give every XWiki resource an ID (i.e., an URI)
2) Make everything accessible through a uniform interface (i.e. HTTP
or WebDAV)

This implies:
1) Do some "resource" engineering in order to well define the URI space
2) Think about resource representations
3) Build the "business logic" to map the new way of accessing resources.

Just an example for what it could look like.

GET http://site/spaces -> gets the list of the available spaces
POST http://site/spaces [SPACEINFO] -> create a new space
DELETE htp://site/spaces/foo -> delete space foo
PUT http://site/spaces/foo [SPACEINFO] -> Update space info (like
description, etc.)
etc.

The trick here is that you have all the relevant things directly
addressable and accessible through a uniform interface (i.e., HTTP or
WebDAV). You will be able, for example, to say something like
"GET http://site/space/page/object/field" and retrieve the value of
the field of the object associated with a given page on a given space.
Doing a PUT on that URI will set the value.

Currently you have to do something like:
XMLRPCClient
.getSpace
("space").getPage("page").getObject("Object").getField("field");

The uniform interface (HTTP) allows you also to write the previous URI
in a browser instead of compiling java code with brittle APIs :) An it
would work :)

Of course this is only the tip of the iceberg (and of the problems :))


> This can have
> some repercussions even on semantic features that Stèphane was
> proposing on the chat.
>
> Can we discuss those here as well ? :)
>
Yes :)

The foundation of RDF and all the semantic frameworks (à la semantic
web) are the fact that "things" can be expressed and referenced
through URI.

In RDF, in fact, triples that establish relationships between thing
are in the form

SubjectURI PredicateURI [ObjectURI | Literal]

To be more concrete I might say something like:

person://fabiomancinelli http://ontology/fullname "Fabio Mancinelli"
That basically states that my name is "Fabio Mancinelli", provided
that person://fabiomancinelli is the URI that identifies the "physical
person" that's me.

Now, by exposing XWiki resources in a RESTful way we are basically
exposing all the relevant XWiki "things" via a URI. We can use those
URI for describing semantic relationships. So we could say something
like

http://site/space/page http://ontology/tag http://ontology/Technology
http://site/space/page http://ontology/tag http://ontology/News

In order to state that a given page has the Technology and News tags.

Of course I've been very concise because it's not that easy and what
I've described requires a lot of effort despite its simplicity.

But if the engineering is done well this could result in a very
powerful extension.

It would be nice to send an email saying:

"Hey Asiri look at the paragraph http://site/space/page/paragraph/1
and review it", then you do a "PUT on http://site/page/paragraph/1"
and boom, the page will be updated reflecting the changes you did with
respect to that paragraph. :)

This sounds really cool.

Thanks a for the detailed explanation. :)

- Asiri
 

I hope that I've been clear.
I know that's a not easy topic and it has a lot of nuances.

Feel free to ask other questions.

> Thannks a lot.

You are welcome.

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4
In reply to this post by Fabio Mancinelli-4

On 4 mars 08, at 14:30, Fabio Mancinelli wrote:

>
> On 4 mars 08, at 14:02, Vincent Massol wrote:
>
>> Definitely a good idea.
>>
>> Could you please create a project page for it on
>> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ ?
>>
>> Thanks
>> -Vincent
>>
>
> Hi Vincent,
>
> there is already an "XWiki Pure REST Api (compatible with GWT Apis,
> XML-RPC, SOAP)" but I don't understand where the corresponding project
> page is.

Please ignore this mail... I didn't notice the "Add this Project" form  
on the page :)
Gonna add it ASAP.

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator

On Mar 4, 2008, at 2:45 PM, Fabio Mancinelli wrote:

>
> On 4 mars 08, at 14:30, Fabio Mancinelli wrote:
>
>>
>> On 4 mars 08, at 14:02, Vincent Massol wrote:
>>
>>> Definitely a good idea.
>>>
>>> Could you please create a project page for it on
>>> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ ?
>>>
>>> Thanks
>>> -Vincent
>>>
>>
>> Hi Vincent,
>>
>> there is already an "XWiki Pure REST Api (compatible with GWT Apis,
>> XML-RPC, SOAP)" but I don't understand where the corresponding  
>> project
>> page is.
>
> Please ignore this mail... I didn't notice the "Add this Project" form
> on the page :)
> Gonna add it ASAP.

Ludovic has already added it. You might want to edit it and add more  
info though.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Sergiu Dumitriu-2
In reply to this post by Fabio Mancinelli-4
Fabio Mancinelli wrote:

> On 4 mars 08, at 13:27, Asiri Rathnayake wrote:
>
>> First of all, I'm pretty new to this topic. But please help me clear  
>> some of my doubts. :)
>>
>> What functionality of XWiki will be exposed via the new WebService ?  
>> same stuff as in XMLRPC ? or more ?
>>
> Basically the idea is to make XWiki interoperable and addressable  
> using the REST architectural style principles.
>
> At a high level of abstraction, yes the services will be provide the  
> same functionalities of XMLRPC.
> But in a REST oriented solution the "interface" will be the one  
> provided by HTTP (the 4 verbs), not a custom API like the one already  
> present in the XMLRPC extension.
>
>> And why REST and not SOAP ?
>>
> 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.

Also, this should be done in the new component-based architecture.

How's that for a nice SoC project?

> To be concise the idea, following rest principles, is:
> 1) Give every XWiki resource an ID (i.e., an URI)
> 2) Make everything accessible through a uniform interface (i.e. HTTP  
> or WebDAV)
>
> This implies:
> 1) Do some "resource" engineering in order to well define the URI space
> 2) Think about resource representations
> 3) Build the "business logic" to map the new way of accessing resources.
>
> Just an example for what it could look like.
>
> GET http://site/spaces -> gets the list of the available spaces
> POST http://site/spaces [SPACEINFO] -> create a new space
> DELETE htp://site/spaces/foo -> delete space foo
> PUT http://site/spaces/foo [SPACEINFO] -> Update space info (like  
> description, etc.)
> etc.
>
> The trick here is that you have all the relevant things directly  
> addressable and accessible through a uniform interface (i.e., HTTP or  
> WebDAV). You will be able, for example, to say something like
> "GET http://site/space/page/object/field" and retrieve the value of  
> the field of the object associated with a given page on a given space.  
> Doing a PUT on that URI will set the value.
>
> Currently you have to do something like:
> XMLRPCClient
> .getSpace
> ("space").getPage("page").getObject("Object").getField("field");
>
> The uniform interface (HTTP) allows you also to write the previous URI  
> in a browser instead of compiling java code with brittle APIs :) An it  
> would work :)
>
> Of course this is only the tip of the iceberg (and of the problems :))
>
>
>> This can have
>> some repercussions even on semantic features that Stèphane was
>> proposing on the chat.
>>
>> Can we discuss those here as well ? :)
>>
> Yes :)
>
> The foundation of RDF and all the semantic frameworks (à la semantic  
> web) are the fact that "things" can be expressed and referenced  
> through URI.
>
> In RDF, in fact, triples that establish relationships between thing  
> are in the form
>
> SubjectURI PredicateURI [ObjectURI | Literal]
>
> To be more concrete I might say something like:
>
> person://fabiomancinelli http://ontology/fullname "Fabio Mancinelli"
> That basically states that my name is "Fabio Mancinelli", provided  
> that person://fabiomancinelli is the URI that identifies the "physical  
> person" that's me.
>
> Now, by exposing XWiki resources in a RESTful way we are basically  
> exposing all the relevant XWiki "things" via a URI. We can use those  
> URI for describing semantic relationships. So we could say something  
> like
>
> http://site/space/page http://ontology/tag http://ontology/Technology
> http://site/space/page http://ontology/tag http://ontology/News
>
> In order to state that a given page has the Technology and News tags.
>
> Of course I've been very concise because it's not that easy and what  
> I've described requires a lot of effort despite its simplicity.
>
> But if the engineering is done well this could result in a very  
> powerful extension.
>
> It would be nice to send an email saying:
>
> "Hey Asiri look at the paragraph http://site/space/page/paragraph/1 
> and review it", then you do a "PUT on http://site/page/paragraph/1"  
> and boom, the page will be updated reflecting the changes you did with  
> respect to that paragraph. :)
>
> I hope that I've been clear.
> I know that's a not easy topic and it has a lot of nuances.
>
> Feel free to ask other questions.
>
>> Thannks a lot.
>
> You are welcome.
>
> Cheers,
> Fabio


--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator

On Mar 4, 2008, at 4:23 PM, Sergiu Dumitriu wrote:

> Fabio Mancinelli wrote:
>> On 4 mars 08, at 13:27, Asiri Rathnayake wrote:
>>
>>> First of all, I'm pretty new to this topic. But please help me clear
>>> some of my doubts. :)
>>>
>>> What functionality of XWiki will be exposed via the new WebService ?
>>> same stuff as in XMLRPC ? or more ?
>>>
>> Basically the idea is to make XWiki interoperable and addressable
>> using the REST architectural style principles.
>>
>> At a high level of abstraction, yes the services will be provide the
>> same functionalities of XMLRPC.
>> But in a REST oriented solution the "interface" will be the one
>> provided by HTTP (the 4 verbs), not a custom API like the one already
>> present in the XMLRPC extension.
>>
>>> And why REST and not SOAP ?
>>>
>> 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.

+1

And you can include Velocity to the list of APIs (and possibly Groovy  
although Groovy API == Java API).

> Also, this should be done in the new component-based architecture.

+1

> How's that for a nice SoC project?

+1

-Vincent

>> To be concise the idea, following rest principles, is:
>> 1) Give every XWiki resource an ID (i.e., an URI)
>> 2) Make everything accessible through a uniform interface (i.e. HTTP
>> or WebDAV)
>>
>> This implies:
>> 1) Do some "resource" engineering in order to well define the URI  
>> space
>> 2) Think about resource representations
>> 3) Build the "business logic" to map the new way of accessing  
>> resources.
>>
>> Just an example for what it could look like.
>>
>> GET http://site/spaces -> gets the list of the available spaces
>> POST http://site/spaces [SPACEINFO] -> create a new space
>> DELETE htp://site/spaces/foo -> delete space foo
>> PUT http://site/spaces/foo [SPACEINFO] -> Update space info (like
>> description, etc.)
>> etc.
>>
>> The trick here is that you have all the relevant things directly
>> addressable and accessible through a uniform interface (i.e., HTTP or
>> WebDAV). You will be able, for example, to say something like
>> "GET http://site/space/page/object/field" and retrieve the value of
>> the field of the object associated with a given page on a given  
>> space.
>> Doing a PUT on that URI will set the value.
>>
>> Currently you have to do something like:
>> XMLRPCClient
>> .getSpace
>> ("space").getPage("page").getObject("Object").getField("field");
>>
>> The uniform interface (HTTP) allows you also to write the previous  
>> URI
>> in a browser instead of compiling java code with brittle APIs :) An  
>> it
>> would work :)
>>
>> Of course this is only the tip of the iceberg (and of the  
>> problems :))
>>
>>
>>> This can have
>>> some repercussions even on semantic features that Stèphane was
>>> proposing on the chat.
>>>
>>> Can we discuss those here as well ? :)
>>>
>> Yes :)
>>
>> The foundation of RDF and all the semantic frameworks (à la semantic
>> web) are the fact that "things" can be expressed and referenced
>> through URI.
>>
>> In RDF, in fact, triples that establish relationships between thing
>> are in the form
>>
>> SubjectURI PredicateURI [ObjectURI | Literal]
>>
>> To be more concrete I might say something like:
>>
>> person://fabiomancinelli http://ontology/fullname "Fabio Mancinelli"
>> That basically states that my name is "Fabio Mancinelli", provided
>> that person://fabiomancinelli is the URI that identifies the  
>> "physical
>> person" that's me.
>>
>> Now, by exposing XWiki resources in a RESTful way we are basically
>> exposing all the relevant XWiki "things" via a URI. We can use those
>> URI for describing semantic relationships. So we could say something
>> like
>>
>> http://site/space/page http://ontology/tag http://ontology/Technology
>> http://site/space/page http://ontology/tag http://ontology/News
>>
>> In order to state that a given page has the Technology and News tags.
>>
>> Of course I've been very concise because it's not that easy and what
>> I've described requires a lot of effort despite its simplicity.
>>
>> But if the engineering is done well this could result in a very
>> powerful extension.
>>
>> It would be nice to send an email saying:
>>
>> "Hey Asiri look at the paragraph http://site/space/page/paragraph/1
>> and review it", then you do a "PUT on http://site/page/paragraph/1"
>> and boom, the page will be updated reflecting the changes you did  
>> with
>> respect to that paragraph. :)
>>
>> I hope that I've been clear.
>> I know that's a not easy topic and it has a lot of nuances.
>>
>> Feel free to ask other questions.
>>
>>> Thannks a lot.
>>
>> You are welcome.
>>
>> Cheers,
>> Fabio
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4
In reply to this post by Sergiu Dumitriu-2

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



_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator

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).

This is what Modello does: http://modello.codehaus.org/

Here's for example Maven's data model in XML:

I've found some old email I sent on this list. Here's an extract:

"
* I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/src/main/mdo/maven.mdo

The reason is that this will allow us to generate lots of things from this model:
- Java bindings
- XSD
- Documentation
- Any other language bindings
- etc

We could use Modello for doing this. It's well integrated into Maven2 and is easy to use.
"

This allows having a single API definition and then generate bindings for anything and everything. Easier maintenance, consistency, etc.

Thanks
-Vincent

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


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4

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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator

On Mar 5, 2008, at 10:48 AM, Fabio Mancinelli wrote:

>
> 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.

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

> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4

On 5 mars 08, at 11:07, Vincent Massol wrote:

>> To me something like http://site/space/page?action=delete is NOT
>> RESTful.
>
> 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?
>

It's not just a problem of "uri syntax".
It's a semantic problem. REST applied to the WEB prescribes that the  
HTTP uniform interface (and its semantics) should be used to access  
resources.

Now if you have http://site/space/page/action/delete
and you do a GET on it you are actually *deleting* a page.

So basically you are subverting the semantics of the HTTP interface  
that says that
GET is safe (doesn't have side effects on the resource state) and  
idempotent and returns a representation of the resource identified by  
the URI.

This is valid for every "action" encoded in the URI (this is why I was  
saying that REST talks about nouns and not actions). Basically, by  
doing this (encoding an action in the URI), you "transfer" the  
semantics of the request from the HTTP method to the URI and that's  
not what REST says.

Doing this kind of things is detrimental. Sometimes ago Google  
released this web-accelerator product that basically built a cache by  
performing GET requests in background. A sort of local crawler for  
speeding up the navigation. It has to be retired because people were  
implementing things in a non RESTful way (i.e., by subverting the  
semantics of HTTP through URIs). What happened is that the crawler,  
when was GETting some URI like the one you wrote, it was actually  
*modifying* the underlying resource. People were loosing data!

So my proposal was in the direction of building a pure RESTful XWiki,  
as much as possible (i.e., one that comply with the HTTP semantics),  
not an hybrid thing (like many services that are already present:  
flickr, delicious, etc.). This is not interesting from my point of  
view and was not the spirit of my proposal.

I understand, however, that this goal might be a bit "academic" and  
too research-oriented and might not be well suited for.

But doing what you proposed, i.e. automatically generating a URI based  
API by simply encoding the backend API calls in URIs is not REST, and  
might do more harm than good.

> 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.
>
Indeed. Maybe it's going to be very complex.
Being RESTful has tons of advantages but this comes at a price. A  
complete change of perspective.

When designing RESTfully you stick to a fixed "client API" that is the  
uniform interface you choose, and on the Web is:

class ClientAPI {
   Response GET(Request r);
   Response PUT(Request r);
   Response DELETE(Request r);
   Response POST(Request r);
}

With http://www.w3.org/Protocols/rfc2616/rfc2616.html as the  
"Javadoc" :)

Then you start mapping what a POST or a GET or a DELETE on a given URI  
means in terms of your backend API (e.g., the XWiki API), in order to  
generate the Response. But the client has to see and use that API with  
the given semantics.

I was saying that the WebDAV proposal was similar because in this case  
you would have this:

class ClientAPI {
   /* HTTP */
   Response GET(Request r);
   Response PUT(Request r);
   Response DELETE(Request r);
   Response POST(Request r);

   /* WebDAV */
   Response PROPPATCH(Request r);
   Response PROPFIND(Request r);
   Response MKCOL(Request r);
   Response COPY(Request r);
   Response MOVE(Request r);
   Response LOCK(Request r);
   Response UNLOCK(Request r);
}

With http://www.w3.org/Protocols/rfc2616/rfc2616.html and http://www.webdav.org/specs/rfc2518.html 
  as the corresponding "Javadocs".

But still you have to design what can be GETted, PROPPATCHed, LOCKed,  
i.e., the URI space and what this means.

To conclude, I am not saying that the automatic generation of URI  
mapping is bad (people are doing it most of the time and time) But  
from my point of view, the two proposals are totally different. This  
is the reason why I didn't agree with Sergiu: it's not just a question  
of implementation but rather a question of design.

Anyway, nice discussion! This is really interesting and helps me to  
better understand these concepts that are not easy at all and  
sometimes very blurred :)

Cheers,
Fabio
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

vmassol
Administrator

On Mar 5, 2008, at 11:58 AM, Fabio Mancinelli wrote:

>
> On 5 mars 08, at 11:07, Vincent Massol wrote:
>>> To me something like http://site/space/page?action=delete is NOT
>>> RESTful.
>>
>> 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?
>>
>
> It's not just a problem of "uri syntax".
> It's a semantic problem. REST applied to the WEB prescribes that the
> HTTP uniform interface (and its semantics) should be used to access
> resources.
>
> Now if you have http://site/space/page/action/delete
> and you do a GET on it you are actually *deleting* a page.

Yep for a moment I had forgotten about the HTTP verbs... ;)

[snip]

Thanks
-Vincent
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Sergiu Dumitriu-2
In reply to this post by Fabio Mancinelli-4
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?

Sorry, my typo, I mean application LOGIC, not login.

> 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
>
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Sergiu Dumitriu-2
In reply to this post by Fabio Mancinelli-4
Fabio Mancinelli wrote:

> On 5 mars 08, at 11:07, Vincent Massol wrote:
>>> To me something like http://site/space/page?action=delete is NOT
>>> RESTful.
>> 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?
>>
>
> It's not just a problem of "uri syntax".
> It's a semantic problem. REST applied to the WEB prescribes that the  
> HTTP uniform interface (and its semantics) should be used to access  
> resources.
>
> Now if you have http://site/space/page/action/delete
> and you do a GET on it you are actually *deleting* a page.
>
> So basically you are subverting the semantics of the HTTP interface  
> that says that
> GET is safe (doesn't have side effects on the resource state) and  
> idempotent and returns a representation of the resource identified by  
> the URI.
>
> This is valid for every "action" encoded in the URI (this is why I was  
> saying that REST talks about nouns and not actions). Basically, by  
> doing this (encoding an action in the URI), you "transfer" the  
> semantics of the request from the HTTP method to the URI and that's  
> not what REST says.
>
> Doing this kind of things is detrimental. Sometimes ago Google  
> released this web-accelerator product that basically built a cache by  
> performing GET requests in background. A sort of local crawler for  
> speeding up the navigation. It has to be retired because people were  
> implementing things in a non RESTful way (i.e., by subverting the  
> semantics of HTTP through URIs). What happened is that the crawler,  
> when was GETting some URI like the one you wrote, it was actually  
> *modifying* the underlying resource. People were loosing data!
>
> So my proposal was in the direction of building a pure RESTful XWiki,  
> as much as possible (i.e., one that comply with the HTTP semantics),  
> not an hybrid thing (like many services that are already present:  
> flickr, delicious, etc.). This is not interesting from my point of  
> view and was not the spirit of my proposal.
>
> I understand, however, that this goal might be a bit "academic" and  
> too research-oriented and might not be well suited for.
>
> But doing what you proposed, i.e. automatically generating a URI based  
> API by simply encoding the backend API calls in URIs is not REST, and  
> might do more harm than good.
>
>> 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.
>>
> Indeed. Maybe it's going to be very complex.
> Being RESTful has tons of advantages but this comes at a price. A  
> complete change of perspective.
>
> When designing RESTfully you stick to a fixed "client API" that is the  
> uniform interface you choose, and on the Web is:
>
> class ClientAPI {
>    Response GET(Request r);
>    Response PUT(Request r);
>    Response DELETE(Request r);
>    Response POST(Request r);
> }
>
> With http://www.w3.org/Protocols/rfc2616/rfc2616.html as the  
> "Javadoc" :)
>
> Then you start mapping what a POST or a GET or a DELETE on a given URI  
> means in terms of your backend API (e.g., the XWiki API), in order to  
> generate the Response. But the client has to see and use that API with  
> the given semantics.
>
> I was saying that the WebDAV proposal was similar because in this case  
> you would have this:
>
> class ClientAPI {
>    /* HTTP */
>    Response GET(Request r);
>    Response PUT(Request r);
>    Response DELETE(Request r);
>    Response POST(Request r);
>
>    /* WebDAV */
>    Response PROPPATCH(Request r);
>    Response PROPFIND(Request r);
>    Response MKCOL(Request r);
>    Response COPY(Request r);
>    Response MOVE(Request r);
>    Response LOCK(Request r);
>    Response UNLOCK(Request r);
> }
>
> With http://www.w3.org/Protocols/rfc2616/rfc2616.html and http://www.webdav.org/specs/rfc2518.html 
>   as the corresponding "Javadocs".
>
> But still you have to design what can be GETted, PROPPATCHed, LOCKed,  
> i.e., the URI space and what this means.
>
> To conclude, I am not saying that the automatic generation of URI  
> mapping is bad (people are doing it most of the time and time) But  
> from my point of view, the two proposals are totally different. This  
> is the reason why I didn't agree with Sergiu: it's not just a question  
> of implementation but rather a question of design.

No, we didn't quite disagree. I was not talking about the
implementation, but about the design of the implementation. If we would
write some restlets, then they would do what?

Let's say we have the URL http://server/Space/Page/ and do a:
- GET: duplicate some of the code in ViewAction
- PUT: duplicate some of the code in SaveAction
- DELETE: duplicate some of the code in DeleteAction
- POST: duplicate some other code in SaveAction
- HEAD: write some new code, as this is not done yet

So I was saying that when designing the URLs, we should redesign the
application logiC (and this is something you implied, too), but put it
not in the restlets, but in another layer, so that it can be reused by
other protocols. You do agree that we can't just design new URLs (or
should we say IRIs?), without designing the logic behind them.

Currently the logic is spread around all the platform. There is code in
the Struts actions, in the XWiki giant, in the data model, in templates,
in documents, in plugins (FileUpload, for example), so writing restlets
that reuse this spread logic will be very inefficient:
- search all around the code to see how to do something
- duplicate code
- copy the bugs along with the code
- increase even more the mess

And we can't just completely replace the servlets (and their URLs) with
the new REST approach, as all the bookmarks and knowledge about the URLs
would be broken, so people will not upgrade. So we either reimplement
them using the new app logic layer, or write an URL rewrite engine that
forwards to the new IRIs.

> Anyway, nice discussion! This is really interesting and helps me to  
> better understand these concepts that are not easy at all and  
> sometimes very blurred :)
>
> Cheers,
> Fabio


--
Sergiu Dumitriu
http://purl.org/net/sergiu/

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

ebullient
On Wed, Mar 5, 2008 at 10:38 AM, Sergiu Dumitriu <[hidden email]> wrote:

>  No, we didn't quite disagree. I was not talking about the
>  implementation, but about the design of the implementation. If we would
>  write some restlets, then they would do what?
>
>  Let's say we have the URL http://server/Space/Page/ and do a:
>  - GET: duplicate some of the code in ViewAction
>  - PUT: duplicate some of the code in SaveAction
>  - DELETE: duplicate some of the code in DeleteAction
>  - POST: duplicate some other code in SaveAction
>  - HEAD: write some new code, as this is not done yet
>
>  So I was saying that when designing the URLs, we should redesign the
>  application logiC (and this is something you implied, too), but put it
>  not in the restlets, but in another layer, so that it can be reused by
>  other protocols. You do agree that we can't just design new URLs (or
>  should we say IRIs?), without designing the logic behind them.
>
>  Currently the logic is spread around all the platform. There is code in
>  the Struts actions, in the XWiki giant, in the data model, in templates,
>  in documents, in plugins (FileUpload, for example), so writing restlets
>  that reuse this spread logic will be very inefficient:
>  - search all around the code to see how to do something
>  - duplicate code
>  - copy the bugs along with the code
>  - increase even more the mess
>
>  And we can't just completely replace the servlets (and their URLs) with
>  the new REST approach, as all the bookmarks and knowledge about the URLs
>  would be broken, so people will not upgrade. So we either reimplement
>  them using the new app logic layer, or write an URL rewrite engine that
>  forwards to the new IRIs.
>
>
> --
>  Sergiu Dumitriu
>  http://purl.org/net/sergiu/
>

I completely agree with this, and think that consolidating the logic
so it isn't spread across so many places would also simplify life for
those of us that want to put a completely new face on things (so to
speak).

I have also been bitten by the crawler bug: Some of the delete actions
are/were regular URLs relying on Javascript for confirm/deny... I've
seen a bot with read access start deleting things.. (in the absence of
javascript, the URL is effectively "clicked", causing the action to
happen.. ). That's a little tangential to the discussion, but
consolidating where the logic is for managing deletes, etc. would be
good.. It might also make the path length a little shorter, if you do
it right..


--
'Waste of a good apple' -Samwise Gamgee
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: GSOC idea: RESTful XWiki

Fabio Mancinelli-4
In reply to this post by Sergiu Dumitriu-2

On 5 mars 08, at 16:38, Sergiu Dumitriu wrote:

> Currently the logic is spread around all the platform. There is code  
> in
> the Struts actions, in the XWiki giant, in the data model, in  
> templates,
> in documents, in plugins (FileUpload, for example), so writing  
> restlets
> that reuse this spread logic will be very inefficient:
> - search all around the code to see how to do something
> - duplicate code
> - copy the bugs along with the code
> - increase even more the mess
>
> And we can't just completely replace the servlets (and their URLs)  
> with
> the new REST approach, as all the bookmarks and knowledge about the  
> URLs
> would be broken, so people will not upgrade. So we either reimplement
> them using the new app logic layer, or write an URL rewrite engine  
> that
> forwards to the new IRIs.

After your message things are a more clear.
I was just assuming that the "XWiki API" was already the layer you  
were talking about. But it is clearly not the case.

And, of course, I totally agree on having a layer that factors things  
for maximum reuse in different contexts.

So maybe we could rule out the RESTful XWiki, leave the WebDAV one  
(that on the user side is actually a super-set) and replace it with  
what Sergiu was proposing?

WDYT?

Cheers,
Fabio

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12