Limitations of the Flickr API

The Flickr API is extensive. The methods of the Flickr API are a fairly stable,
well-­supported way for your program to access data about most resources from
Flickr. As one would expect, the functionality of the Flickr API overlaps strongly with
that of the Flickr UI—but the two are not identical. There are currently things
you can do in the UI that you can’t do in the API. For example:

Although you can access a Flickr group’s photo pool, you can’t
read or write to the group discussions with the API (though you can get at the
latest comments in a group discussion through Flickr feeds).

You can’t add, delete, and configure a weblog for your Flickr account
including layout and settings with the API.

You can’t add or delete contacts via the API.

You can’t delete your Flickr account with the API or do most of the
account management elements such as changing your e-mail or using a different
Yahoo! ID for this Flickr account.

Some of limitations of the API are probably intentional design decisions that are
unlikely to change (such as not being able to programmatically delete your entire
account). Other discrepancies reflect that new features in Flickr tend to show up first
in the UI and then in the API. I would guess, for instance, that there will eventually
be support for Flickr collections in the API.

I will point out another class of differences between the API and UI. There is,
however, some information from Flickr that is available from both the UI and the
API—but that is easier to derive from screen-­scraping the UI and through
using the API. Take this, for example:

http://www.flickr.com/photos/{user-id}/archives/

This lists for every year and month the number of photos that the user has taken or
uploaded. Accessing this information from the UI involves one HTTP GET and
screen-­scraping the HTML. In contrast, generating the same dataset using the
Flickr API requires calculating Unix timestamps for the beginnings and ends of months
(for the time zone of the user, which is not available via the API) so that you can feed
those time boundaries to flickr.photos.getCounts.

What’s the point here? Although the API provides the flexibility to calculate
the number of photos taken or uploaded between any two arbitrary times, the UI for the
archives provides a count of the photos for a very useful default case (that by month),
which turns out to require a bit of work to get from the API. In other words, the UI of
an application gives insight into what the mainstream use cases for the API are.

I’ve found such examples about limitations of APIs with respect to the UI a bit
surprising at first. I would have expected a given functionality to be purposely
excluded from the API (because of a policy decision) or easier to programmatically
access via the UI—but not harder than screen-­scraping using the API.
Otherwise, there’s a disincentive to use the API in that case.