Drupal Camp Alberta

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

I recently attended Drupal Camp Alberta with about another 50 people. The reason for my attendence was that I had been invited to speak about the drupal services module as one of the co-maintainers of the project.

The drupal services module is maintained by myself, Rob Loach and Scott Nelson and has been existence as a drupal module for about 18 months. The module attempts to abstract both servers and services to allow multiple protocols to have to the same data. This opens opportunities for drupal to act as true server and a remote data repository for distripate clients. Services is currently under going active dvelopment and is maturing rapidly as a module. The module ships with a number of services being available:

  • Node service. This provides the ability to create, save and delete nodes.
  • Search service. This provides the ability to initiate user or node based searches.
  • System service. This provides utility functions to get and set variables and re-start connections when using a cookie-less client.
  • Taxonomy service. This allows as a client to retrieve a hierarchy of the taxonomy on a site and the nodes related to a given term.
  • Users service. This allows users to login and logout. Work needs to be done on the registration process but given the different options that can be configured adds an additional level of complexity.

Each method defined by a service has a signature. This signature provides a number of parameters:

  • Method. This is the name that is exposed to the calling client.
  • Callback. This is the internal function that the method maps too.
  • Args. These are the parameters passed into the function that is being called.
  • Access callback. This is the fucntion that will be used to validate if a user has the right to access a given service. This defaults to user_access.
  • Access arguments. These are the parameters passed into the access function.
  • Return. This is the data type that is being passed back to the calling object.

The services module allows for multiple servers to be set up a single site. The only server that ships with the services module is the xml-rpc server. However additional servers are available.

  • The xml-rpc server is intended as a replacement for xmlrpc.php. The new version of the server is integrated with drupal permissions checking and therefore does not require a lot module specific code. The core xmlrpc.inc files are used by this server.
  • JSON. Provides a JSON interface to drupal.
  • REST. Requires the zend framework currently. This dependency will be removed in future versions
  • SOAP. Relies on NU-SOAP.

In part 2 I'll look at some of the configuration settings and admin options provided by the services module.