Mike's Blog
ELib and Twitter
I've been working on a PHP library that can sit alongside Empathy (lightweight MVC) on a purely non-dependant way. The idea being that some of my semi-duplicate code across projects can be re-factored into a central toolkit.Instead of dealing with the boring re-factoring straight away I wanted to work on a simple PHP library for making calls to the Twitter Api (excluding the search API so far). What I think I've ended up with is potentially a nice utility for accessing any REST-ful API with a clean way of defining the API 'specification', perhaps with little-to-no performance hit.I didn't want to look at any existing offerings of PHP library to make it more enjoyable while I pondered an elegant solution of my own. In a fairly paradoxical fashion (as is often the case) the main features revealed themselves in reverse order. I started by building a static array, which could contain the specification of the public API. By doing so I forced myself to consider (sometimes subconciously) the different logic that might be involved in ensuring each variety of call could be easily accessed with a standard interface. Eventually it occured to me that a typical call from a web app might look like this:
$t->doCall('url/to/call/'.$id,
array( 'param1' => $value1, 'param2 => $value2),XML);
The trick is that the first paramater is used as a kind of namespace to find the call in the loaded array of calls. The library will be aware that it might need to substitute parts of the any required numeric values for the placeholders defined in the full API call. The paramerters in the second arguement are 'expoliated' to from a signature with which to cache the results of the call.