My Situation

I have a small app with a public interface. I'm interested in making an API for this to be used in a mobile environment and even eventually as a public API. I want to keep it simple with the priority on aspects like security and performance.

My Plan

Why Drupal? Well, I know Drupal and I can envision a setup where I have 2 sites. www.mygui.com (default) and api.mygui.com (API). All database structure is determined by the work done in the default site. Using the Drupal Services Module (and only a few other necessary core modules) on the API site I plan to allow authenticated updates to the database by way of JSON and the drupal_internal_api.

My Problem

I already have a prototype (not in drupal) that uses tokens. I'm new to services and don't really know all its limits and capabilities yet. This looks promising but still in the pipeline: Drupal Services Auth Token Module. I would like advice or resources regarding a good authentication strategy. For example, which is best? Keep the user base the same with assigned "API Uer" roles or have a completely separate user base specifically for the API site? Keeping in mind that an API username is a long term setup where the username/password or token should not change until the API user is ready with a new app release? Can I have a nice GUI for users to manage their API site credentials on the default site?

  • 1
    Do you absolutely need your API endpoints on a different subdomain? This would probably be a lot easier if you could settle on something like www.mysite.com/api as your endpoint, then you won't have to worry about setting up multiple sites with access to the same database. You could even do an apache rewrite from api.mysite.com to mysite.com/api if you need to
    – Clive
    Sep 20, 2012 at 11:41
  • Could be. I don't think the multisite is the issue here though. In fact it might be beneficial to keep my gui users and api users separate. I'm interested in hearing from anyone who's traveled down this road before and knows the caveats of one way or the other.
    – Akahadaka
    Sep 20, 2012 at 13:33
  • I can't comment on the separate method I'm afraid (never tried that), but I've set up services on dozens of sites in the way I've described above and it's always worked well
    – Clive
    Sep 20, 2012 at 13:48

1 Answer 1


This can certainly be achieved without any multisite. Meaning you could always house the API on the same site and proxy the path api.mysite.com to mysite.com/api thus allowing it to be invisible to the user. (Make sure your webhost supports mod_proxy or you have some external proxy you can use for this task)

As for the actual authentication, I don't bother with tokens. Use credentials. This way people can get and keep a session (in line with however long you want them to based on session_lifetime in your settings.php) - After an initial call to a log in path, they can then subsequently call the API over and over again by passing the unique session they are assigned.

Go with the single site approach and use web proxy magic to make it look like a different domain. Easy enough.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.