Interested in branching out as of late, but not really having a particular direction, I decided to build out a set of classes to utilize the REST API, thinking it could be useful for a fun photo-based application -- think, "What Character from [insert movie here] do you most look like" (depending on what I can actually do with it).

The result of this undertaking is Face_Service_Face, a fun exercise in extending the Zend_Service_Abstract class. It's well on its way to becoming a useful interface to a service with a lot of potential for the future. Because the Zend Framework is such a great resource for developing excellent sites with consistent coding and design standards, I think having a service patterned after its finer points freely available to the public will definitely be a benefit. However, the code is not yet production ready -- there are a few caveats.

I decided that I should build the library before anything else. I still need to find a use for it, and then implement it. That's where most of the bug identifying and fixing would come from. The project is on GitHub, so if you get a chance to use it before me, feel free to contribute!

There is actually already a PHP implementation of the API from And I'm sure at this state, it works more consistently than my initial go at it the task. However, it requires a couple of extensions that don't come standard with every build of PHP. For instance, the JSON PHP extension can just as easily be handled using Zend_Json. This could be more graceful and less frustrating for deploying across servers with slightly different versions of PHP.

Another issue I found with's PHP API is that the coding conventions are a little inconsistent. Brackets aren't always used in conditionals, which is a huge maintenance pitfall. There is at least one function definition with the opening bracket on the same line, where most of the others do follow the more generally accepted conventions of opening on the following line.  In general, the standard API seems to use the class definition as a namespace for a variety of loosely-related functions. Although it utilizes OOP, the fact that it sets environment variables instead of class constants for a couple of parameters is a little confusing and, again, inconsistent.  There are definite areas for improvement. A lot of it could be done in the original API itself. However, a perfectly functioning API package for PHP in the style of the Zend Framework should prove to be more legible and easier to interact with. It would also be an appropriate complement to a site implementing the framework.

My package is modeled mainly after Zend_Service_Yahoo, with modifications from its core behavior as I learned more about the API and confronted its unique challenges.  I also added model and object classes for tags, users, and photos, which can be extended to interact with a database or interact directly with the API service, making calls within the controller less convoluted. Future directions for this package would be to extends the model and object classes further to simplify interaction with the API. Rather than having to dictate what can be a vast number of variables, it may be more useful for a developer to have a wider number of functions available that may build off of the same API call. Building out models and objects also allows users to interact with information easier, and store it -- either straight from or modified in some way -- in a local database.

I'll publish updates as I get the opportunity to interact more with the API and the code base I have developed. At this point, I encourage you to check out my code on GitHub and explore it for yourself.