I wasn't thinking of hashbangs, which will ultimately be noise in the history of Twitter. (I could get into a debate about why they weren't that bad, but it's all (HTML5) history now, so I'll move on.)
I was thinking mostly about the clean, namespaced, REST scheme for their API, which you can see at https://dev.twitter.com/docs/api. And it's not just a separate API, as it corresponds closely to the website URLs too.
Generally, Twitter and Digg were the best examples of real-world REST implementations around that time. That people like Oatmeal are making fun of the crazy-long Plus URIs [1] shows it's not just RFC longbeards pontificating about The Right way to build web apps. At least some end-users notice and care about this stuff too.
This is really interesting. I don't do as much REST API work as I'd like to, and I assumed twitter's scheme was standard rather than a shining exception. Thanks for teaching me something new :)
If they're smart, they'll HTTP 301 redirect these old URLs to new ones, if they ever decide to change them.
URI design is hard, especially when you're dealing with a single namespace on a site with massive scale like Twitter. But if everyone has their own namespace (it seems Medium is a good candidate for this), then you could as well use a human-readable timestamp in UTC (yyyy/mm/dd/hh-mm-ss), but they might be an eyesore for some.
The fashion these days tends to be short, mixed-case, untypable URIs that don't look like they'll stand the test of time.
Hopefully it's just a prototype thing, but you'd think they'd want even these early URLs to be shared with love.