A very simple web service was required to give Moodle access to person, groups and membership information from the central database system located on a separate machine. This information was required to be in structure IMS-E XML format for use by an IME-E plug-in for Moodle. [plug-in reference details needed]
Although there are a number of differing ways to connect to and consume information from web services (SOAP, XML-RPC, etc.) it was decided to follow a REST approach as this did not force any additional structure for the data, which could then be output directly in IMS-E format.
PHP is the language used to create the web service. Smarty is used as the template engine. PEAR::DB is the base database abstraction layer, with a wrapper factory class employed for ease of use. No other third-party libraries were used.
The web service is set up to handle GET requests to output information in a safe manner. (A complete REST-based web service may also handle POST, PUT and DELETE HTTP requests.) A user connects to it simply by sending a GET request to a structured URL which contains the function to process and any variable parameters. In the instance of this web service, the URL looks something like:
http://www.yrdomain.com/yrpath/getall/An additional parameter can be added to specify an academic session:
http://www.yrdomain.com/yrpath/getall/06/An Apache htaccess file is used to rewrite the URL so that they can remain in a simply format. The web service breaks down the URL in to its constituent parts and uses them to decide which function to call and what parameters to pass. The is a direct mapping between the URL function parameter and the name of functions written in PHP for handling the output.
The called function completes all required processing, connecting directly to the database if required, and then outputs the IMS-E structure to the HTTP stream for consumption by the client. The IMS-E structure is in a template file which gets populated with information from the database.
In the above URL example, the constituent parts would be getall and 06. On failure to gather any information for output the client will be sent an HTTP/1.0 204 No Content header.
The data being of a sensitive nature needs to have access controlled in some way. The web services uses the remote address of the client to compare against an approved list of clients. On failing to pass a correct remote address the client will be sent an HTTP/1.0 403 Forbidden header. On failure to call a valid function the client will again be sent a 403 header.
The web service is also written as a GET-only service and so there are no updates or modifications to the data stored in the core database.
As this is a REST-based web service the client doesn't have to use a specific library. In the case of Moodle, also written in PHP, a simply file_get_contentsfunction can be employed, supplying the web service URL as the parameter. A slightly more advanced technique used to connect to the web service is to open a direct HTTP socket to the URL, send a GET request with the function and academic session and then read the contents in to an string for further processing. This has the advantage of being able to control the time out and gather error information should the socket fail to open or closes unexpectedly.
For automation of the getting information from the web service, the client can be ran automatically via a cron job.
The web service is not concerned with how the client then processes the IMS-E structure.
$url = 'http://www.yrdomain.com/getall/06/';
$ims = file_get_contents($url);
header('HTTP/1.0 403 Forbidden');
exit; $call = ucfirst(strtolower($urlSections[0]));
if (!function_exists($call)) {
forbidden();
}
$call($db, $template, $paramSections);
header('HTTP/1.0 403 Forbidden');
exit; header('HTTP/1.0 204 No Content');
exit; $tpl->assign(array(
'data' => $data,
'datasource' => IMS_DATA_SOURCE,
'session' => $acSession,
'comments' => "For academicsession $acSession"
));
header('Content-type: text/xml');
$tpl->display('enterprise.xml');