Gallery3:API:Flickr - Gallery Codex
Personal tools


From Gallery Codex

If looking for REST docs, (See Gallery3:API:REST).

We're building a new API based on the [Flickr API]. To figure out scope, we'll be picking a few popular Flickr API clients, analyzing what API calls and transports they use, and building endpoints as a module in Gallery 3 so that these clients can work with Gallery 3 just by changing the API endpoints that they use.

Popular Photo Management Tools and How They Talk To Flickr

Client API Usage

iPhoto Native Flickr Support

got a capture of creating a private set with 2 items and then deleting it

$ sudo tcpdump -s 0 -A -i en1 port 80 > dump.txt
$ egrep "GET" dump.txt | cut -d '=' -f 5 | cut -d '&' -f 1 | cut -d ' ' -f 1 | grep -v 0 | sort | uniq


POST stuff was harder to nab but ends up being calls to: /services/upload/ following the upload API and posts to /services/rest/ for:

iPhoto Flickr Export Plugin

got a capture of creating a private set with 1 new item uploading


POST to /services/upload and post to /services/rest/ for:

Lightfroom Flickr Plugin

got a capture of creating a new set with one photo uploading

$ sudo tcpdump -s 0 -A -i en1 port 80 > dump.txt


POST: just to /services/upload/

Notable Details

  • Some other people are mirroring Flickr's API: Other people mirroring flickr's API:
  • Flickr uses "keys" that are application specific, and has "shared secrets" that are associated with keys and required for some API calls
  • Flickr client config is the api key and shared secret. API entry points are coded into libraries somewhere but can be changed in some implementations ($f->REST = "http://foo/entry" in one of the php clients)
  • Method calls are named flickr.*. We should call our subset gallery3.* but should also respond to flickr.* calls
  • We should treat photosets as albums, Flickr doesn't support nesting so we would use path for title and use Gallery's auto url stuff. ex: "Spring Break/2009/Awesome Stuff" would be a collection title, that would be come spring_break/2009/awesome_stuff on G3
  • Photos uploaded aren't put into a set by default. Do we have a config for default upload location or add parameter for "set"? (see )
  • Flickr auth uses keys/etc for login, so our login process will have to work differently. Can we squish user/pass into this or use our own auth api? (see )
  • Plenty of things work with unauthenticated calls, do we want to let this happen?
  • The API has tight integration with tags, do we make this API depend on tags?
  • entry points like:
    • services/auth/ -> special case
    • services/upload/ -> special case, http post with binary data
    • services/replace/ -> special case, http post with binary data
    • services/rest/
    • services/xmlrpc -> can do this later
    • services/soap -> can do this later
  • response format can be specified as a paramater
    • rest
    • xmlrpc
    • soap
    • json
    • PHP serialize/unserialize

Usage Scenarios

Step 1: Logging in



  1. post of user/password to url
  2. gets back status code, session token, and request token
  • Gallery3 authenticates the user, assigns a token for this session, and gives a request token (like existing security form tokens) that changes every request

Step 2: Uploading a photo


(inspiration: )

  1. post of photo and information, including album path
  2. gets back status code, image ID, image URL, and a new request token.