Flickr API: people.getPublicPhotos vs photos.search
The Flickr API is an incredibly well done API, allowing for very easy queries that provide a ton of information about photos, people, places, and more. Sometimes, however, results from different api calls overlap, and it's hard to decide which to use.
The most common overlap is the flickr.photos.search with many other photo fetching calls. The reason is because you can pass in countless amounts of parameters to narrow down your search, which can be replaced by other more simple searches.
I encountered an overlap when I was returning a page full of thumbnails from a particular Flickr user. I was using the people.getPublicPhotos, passing in the nsid for the user. This returned the latest photos the user posted, which was great. I left it as is until I needed to get a few extras, including sorting. The flickr.getPublicPhotos is very generic, and doesn't accept any other parameters, which is very limiting, so I turned to the flickr.photos.search to do a search with the nsid passed in, and I got the same results but with more control!
I'm wondering if this would yield a slower query, but in my tests there were no differences on my end. Everything probably funnels eventually to the photos.search query on their end, with some nice wrappers that simplify some of the simpler use cases.
Anyhow, I grouped all my photo lookups into one function, and made it super DRY by giving a type for the search. Here's an example (using the Flickraw ruby flickr api wrapper):
begin
extras = 'owner_name, views, date_taken, geo'
if params[:category] == 'user'
user = flickr.people.findByUsername(:username => params[:search_term])
search_term = user.nsid
type = 'user_id'
params[:sort] = 'date-posted-desc' if params[:sort].nil?
else
search_term = params[:search_term]
type = 'text'
params[:sort] = 'relevance' if params[:sort].nil?
end
@photos = flickr.photos.search(:sort => params[:sort], type.to_sym => search_term, :extras => extras)
rescue Exception => e
flash[:error] = 'No results'
logger.info "#{e.message}"
end
The above is simplified, but I funnel keyword searches with username searches by doing a lookup on the category of the search parameters. The search is by username, so I have to do an extra call to get the user data which includes the nsid, and set that to the search term.
Try out the Flickr API, and if writing in ruby, the Flickraw gem kicks ass. When the flickraw library loads, it fetches methods from flickr using introspective capabilities. Thus the flickraw library does not need to update everytime flickr updates their api. Flickraw has been my favorite solution so far in terms of flickr wrappers.
