Creating an API - Twitlbl v1.0

This is really just a random assortment of ideas in my head while writing the Twitlbl (formerly available at API.

  • The biggest concern is ease of modification. I know this version of the API will be wrong and incomplete, but I don't want to alienate anyone who does decide to use it when I try to fix it. To that end, the version of the API is included in the service endpoints. Future versions of the API will make use of the same structure, without breaking the existing implementors.
  • To a degree, the implementation of the external API is validation of the internal API. It was fairly easy to create the API and make it work.
  • I spent more time writing the documentation than I did writing the implementation of the API. I'm not happy with the documentation, but I feel it is a good start.
  • Dogfooding your own external API is invaluable. My initial design for it was a lot different. After attempting to work with it, a lot has been changed to make it easier to work with.

At this point, I feel have a decent first pass. I'm hoping that someone other than myself will try playing with it I would love to get some feedback on it, and the service in general.

As for planning future expansion, I'm currently evaluating oEmbed, oData, and JSON support to broaden adoption and use. I'm hoping in the coming days to post a development roadmap of sorts as well an architecture writeup.


  • Design Considerations
  • Twitlbl


  • 2/28/2010 - Article published.