Curlr API Implementation - part 3

As you can see, I've been diverted from this series by getting the web site together, and trying out the Flickr API - a lot more fun than documenting and testing it. But it's time to put the manual touches to the generated api.

The main idea has been that there is a separate class for each Flickr method, with the intent that a single object handles the call and the interpretation of the response. Using the Curl IDE we get the bonus of auto-completion for the arguments of the request method, so the basic programming is straight forward enough with the api decribed previously. But there are 88 classes, and they all have very similar constructor signatures - requiring the secret and api_key. It will get to be tedious having to type these values in more than once, and a programm may well need to set / reset the authorization token on many of these objects. There may be other tasks that require handling all of the constructed API objects, so we need an organizing entity to make life a little easier.

The shape of an organizing class is simple, once we know what it is that we need. The base class can be generated by the build process - ensuring that it is complete - and looks like this:

I've shown the pattern for only the authorization methods, but it's identical for all the other methods. So for a very small startup oveherhead, a BaseFlickrAPI object creates instances of each of the methods and stores them in a HashTable. The setter code for the auth_token shows how this is used to perform global assignments.

It isn't my intention that BaseFlickrAPI is used directly in an application - we'll actually be using a subclass - if it was, a request might look like this:

The class helps organize the methods, and is useful for implementing higher level functionality.