First, it’s important to make a distinction between a content API and a plugin API. A lot of what I’m thinking about involves a content API, so that we have alternate ways of making content available to third parties.
There are a couple of uses where a content API would be helpful; one is in content syndication, but the big one is in creating mashups that would combine content from a Campsite server with info from other servers, such as Google Maps or the Sunlight Foundation or what have you. In this way, content delivered via such an API with a key may even become a source of revenue for publishers.
The question I had about doing something like this via an API was this: Can Smarty deliver content on the basis of XML-RPC requests that would then get translated through templates? I presume it’s pretty easy to add some XML-RPC tags to the returned content, too, right? If that were the case, it would be a lot easier to create such an API because it could leverage many (if not all) of the functions already included in the Campsite templating language; very loosely defined, the templating language is an API, right?. If that were the case, I suppose you’d have to have a module listening for XML-RPC calls on one side, then acting on those calls. The steps could look like this:
– Third party user calls the Campsite server via XML-RPC (or REST or whatever)
– Smarty on the Campsite server has a module listening for XML-RPC
– User is authenticated (presumably with LiveUser?)
– User request, including any Campsite templating command, is passed to Campsite templating/Smarty for action
– Campsite templating/Smarty returns content
– Module returns content to third party user in XML-RPC format
We already use Campsite templating to create RSS feeds, so not much changes there. I suppose the big difference is in having the templating commands accessible via XML-RPC.
