THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Jamie Thomson

This is the blog of Jamie Thomson, a data mangler in London working for Dunnhumby

Twitter status id conundrum

I have an interest, a slightly perverse one some might say, in using online services and trying to figure out what the underlying (logical) data model is and in this day and age Twitter is one that lends itself very well to scrutiny. Consider this recent tweet of mine:

odata rdf tweet screenshot

The URL that enables you to see that tweet is We can interpret that URL to mean "a tweet by jamiet with an id of 12154647354" and hence we might further assume that the unique identifier for the tweet is {jamiet,12154647354}.

However, its well-known that Twitter gives each status a unique ID regardless of who tweeted it so we might expect we could reach that tweet just by using a URL of however (at the time of writing) that only redirects to Twitter's homepage. That seems strange to me especially given that we can use Twitter's API to access information about that tweet using only the id of the status. Witness

screenshot of twitter api result

[We can also access a JSON version of that information using]

I'm puzzled as to why a tweet can't be accessed using on the main twitter website using the id alone. Anyone have any suggestions?


Published Sunday, April 18, 2010 5:05 PM by jamiet

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Brian Fending said:

Thinking of the working URI as arg1/arg2/arg3, twitter is using the presence of arg1 for validation against the value of arg3 for return of the result. (e.g.: ./jamiet/status/12154647354 works but ./fendinggroup/status/12154647354 does not work.) The API call uses arg4.xml to retrieve... so the real question about this syntax is why the heck wouldn't twitter want to return based on an arg2 request or, for that matter arg1 ( ?  The reason would seem in the validation of arg1 in the URI - taking care to not allow for screwy http bots deciding to scrape[autoincrement] - it's a dumb reason, but the practical one. They can probably lock down API.* better than the www.* for whatever reason, and the result is your apparent discrepancy in the handling, forcing a user handle on the "normal" http request, but giving it a pass on the API. The result is services wrapped around the API that  - in a controlled way - collect statistics on tweets.

In short: a-holes.

April 18, 2010 11:58 AM

Darren Gosbell said:

This is just a guess, but another reason could be because some people have restricted access to their status and by having the user in the URI, twitter can check if the current users has access to the URI without having to read the main status table.

April 19, 2010 12:44 AM

jamiet said:


That's a fair point however it doesn't explain why a tweet can be accessed via the API using only an id because they would have to make the same check there would they not?


April 19, 2010 5:03 AM


Isn't the obvious answer that they just haven't coded the site to work that way.  Could just be that's how it evolved and how they wanted to present URLs from a UX point of view.  

April 20, 2010 9:47 AM

jamiet said:

Yeah its possible. I wouldn't necessarily say it was obvious.

April 20, 2010 9:50 AM

Leave a Comment


This Blog


Privacy Statement