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