Drupal as the CMS for a restful API for an iPhone App.
For a recent contract the client stipulated Drupal as the CMS to support the web services for their iPhone App. Our advice was to go for a lighter framework that better supports web services and gives better control over things like http headers and the json output. But sometimes you just have to suck it in and do the best you can with what the client wants...
We made our start with a Drupal 7 minimal install profile and used a number of contributed modules to provide the bulk of the required functionality, with some enhancements via custom coded modules.
Views content based RESTful server
These are the core and contributed modules we used to set up the base RESTful service:
ctools- a low level module with an tools required by other modules
entity- provides and API for defining and managing custom Entities
entityreference- provides the ability to build relationships between entities
features- allows us to package configurations and dependencies
field_ui- core module for adding fields to entities
file- core module for allowing uploads to entities
image- core module for managing image content
inline_entity_form- interface for adding related entities within the 'parent' entity edit form
list- core field input module
module_filter- interface enhancement for managing modules
number- core input field
options- core input field
rest_server- provide a RESTful server as part of services
services- module to manage web services endpoints and output formats
services_entity- module to make custom entities available to services
services_views- module to make views available to services
taxonomy- core module
views- essentially a query builder with some output formatting
views_ui- interface for managing views
The data output for the services endpoint in this application is defined in queries built using Views.
Using these tools has some drawbacks. If you're used to building RESTful services closer to the metal, may come as a shock.
- all returned values are strings. The iOS devs hate it when their IDs are not numeric. We eventually did some post-processing to the JSON as it really did improve client side performance.
- strings are escaped for HTML output - so entities like ampersands and special chars are represented as XML friendly (e.g.
&for & and
'for apostrophes). This reflects what Drupal considers normal output.
- empty properties are sometimes presented as an empty array, even if the expected non-empty property should be a string (or stringified number). Words fail me on this one.
- related content types are problematic to embed - so normal 'hasmany' or 'belongsto' relationships one can get easily from an MVC framework are not available. This potentially means more queries to the server than desired, which can be problematic for low bandwidth situations on mobile.
- last modified is a unix timestamp - can't seem to be able to format the output as a date
Don't try this at home.
I wouldn't recommend using Drupal to build web services. We took a contributed module approach with the hope that this would provide more stability in handover to the client. I'm still not sure about this - I think we could have achieved better control if we had done less 'the Drupal way' and trusted our code query the database and output the raw json, without dressing it up Views and the CMS interface, and introducing a level of cruft to the output. If you have the option to use other PHP tools, or Ruby on Rails, or something like Restify on node.js - I would recommend it.