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.
There is no support for Flickr collections in the API.
I don’t think there is currently support for tag clusters in the API
(http://?tech.groups.?yahoo.com/group/yws-flickr/message/1596).
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.