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