{"id":51102,"date":"2026-02-28T15:31:36","date_gmt":"2026-02-28T20:31:36","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51102"},"modified":"2026-03-04T11:29:19","modified_gmt":"2026-03-04T16:29:19","slug":"flickrs-url-scheme","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/02\/28\/flickrs-url-scheme\/","title":{"rendered":"Flickr’s URL Scheme"},"content":{"rendered":"

Marcin Wichary<\/a> (Hacker News<\/a>):<\/p>\n

\n

Half of my education in URLs as user interface came from Flickr in the late 2000s.<\/p>\n

[…]<\/p>\n

This was incredible and a breath of fresh air. No redundant www.<\/code> in front or awkward .php<\/code> at the end. No parameters with their unpleasant ?&=<\/code> syntax. No %<\/code> signs partying with hex codes. When you shared these URLs with others, you didn’t have to retouch or delete anything. When Chrome’s address bar started autocompleting them, you knew exactly where you were going.<\/p>\n

[…]<\/p>\n

It was a beautiful and predictable scheme. Once you knew how it worked, you could guess<\/em> other URLs. If I were typing an email or authoring a blog post and I happened to have a link to your photo in Flickr, I could also easily include a link to your Flickr homepage just by editing the URL, without having to jump back to the browser to verify.<\/p>\n<\/blockquote>\n\n

Nick Heer<\/a>:<\/p>\n

\n

It is the kind of logical directory-style scheme I wish I would see in library-based desktop applications, too. I still have copies of my libraries for Aperture and iPhoto on the same Mac as I use for Photos. Each of those has a pretty understandable structure within the library package: the most substantial part is a “Masters” folder containing a year, month, day, and then project folder hierarchy; among others, there is also a “Database” folder with nondestructive edit operations, though that becomes less intelligible structure if you drill down to the project level.<\/p>\n<\/blockquote>\n\n

Marcin Wichary<\/a>:<\/p>\n

\n

My post about Flickr URLs<\/a> gathered some interesting responses (especially on Mastodon<\/a>, thank you all!), so I thought I’d do what podcasts call a “mailbag episode”!<\/p>\n

[…]<\/p>\n

Both Erin Sparling<\/a> and Nelson Miner<\/a> highlighted how much the craft of Flickr URLs related to the craft of its API:<\/p>\n

Literally used to talk about how good this URL scheme was in class, it was so informative. The Flickr API still informs everything I do these days, URLs included.<\/p><\/blockquote>\n<\/blockquote>\n\n

steerpike<\/a>:<\/p>\n

\n

Flickr deserves a lot of praise for a number of technical advances that I wish had seen wider adoption. Their API was one of the first and honestly still one of the most enjoyable to actually use as a developer. It’s still full of incredibly interesting API calls that you wouldn’t expect from it unless you read carefully. Did you know, for example, that flickr API will provide you with the bounding box co-ordinates of different types of places? From a neighbourhood all the way up to a continent?<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n