This site is archived.

Making a new API for Drupal? Easy. Making one that's worth using? Not so simple. This session will cover best practices and common pitfalls for developers who want to expose new functionality in a re-usable fashion.

This session will be presented by puppets.


Jeff Eaton

Drupal's increasingly modular architecture makes the need for reliable, feature-rich APIs critical. The cost of working with a badly designed API -- in lost time and lost hair -- can turn even well-planned projects into a roller coaster ride. Attendees will see examples of successful APIs in the Drupal ecosystem, discover what sets the good ones apart from the crowd, and learn how they can make their own APIs a pleasure to use.

Topics covered in this session will include:

  • What's an API? (And why helper functions aren't)
  • Building in layers (What we can learn from Earl)
  • The Seven Deadly API Sins
  • The tools Drupal gives us
  • FakePI: A quick tour of an example API
  • Caring for your API once it's in the wild

Developers attending this session should be familiar with Drupal module building and the core Drupal APIs.


I was really looking forward to this session, but unfortunately I won't be arriving until 10am Wednesday morning. Any chance you could provide some of the documents you might be using?

Clarification: this talk is about Drupal internal APIs (voting api, token, etc.) rather than external web service APIs (REST, SOAP, XML-RPC, etc.), correct?


While some of the discussion could be useful, the session will be focusing on best practices and patterns for internal and module-exposed APIs.

OK - not only is the ability to build APIs in Drupal something I am going to sit in on, but puppets?
That can't be beat.