Hello, a "generic webservice infrastructure" is indeed a nice idea and I'd like to check out how people would feel about using some standard like WSDL (http://en.wikipedia.org/wiki/Web_Services_Description_Language) to describe and implement it.
There's nothing magical or fantastic about WSDL, it's just a system for declaring how to call a method by a client. The call is normally super simple, like wsdlFile = 'http://somewhere/echo.wsdl' server = WSDL.Proxy(wsdlFile) x = server.echo("hello world") In this case the response is a string. But it can be any type of object as well. "Distributed methods" people, like computer scientists that have done JavaEE, XML-RPC, software agents, CORBA, Grid etc. seem to like WSDL a lot since the WSDL files can be used to document the purpose of the method. WSDL has also been a buzzword for interoperability. Is it slow? A bit, a "hello world" with WSDL is rather meaningless, since getting the WSDL file takes more time than calling the service. Most client libraries implement caching, however. Yours, Marko > Here it comes a generic webservice infrastructure where e.g.: > > http://cdsweb.cern.ch/webapi?id=choose_reviewer&egroup=ATLAS&startswith="Don"; > > would return a JSon object with the list of all the ATLAS possible author > with a name starting with Don. This would be called by Javascript inside a > form to let the user (who has typed Don) to choose from a drop down menu the > next > authors to add) > > The generic webservice might be built with the usual plugin fashion, where a > > plugin should simply implement a function receiving some parameters (coming > from the form-GET parameters) and should return a Python object suitable to > be encoded in Json (which is automatically understood by Javascript)... > > This interface might be used anywhere is needed some Ajax webservice. > > In Invenio some WEBAPI already exists (e.g. /search?of=xm, bibknowledge, > future bibedit, the suggestion engine) (and they even already return AJAX > sometimes). > > This webapi handler might redirect directly to this already existing specific > WEBAPIS, thus behaving as a centralized interface to find all of them (in this > case the output is not automatically json), plus it would support > administrator-designed new APIs, by dropping simple python functions into a > given folder, that would automatically transform them into AJAX-ish APIs (by > transforming into JSON their output). > > The framework might give the user a standard way to restrict access and to > provide errors, ... >
