Thanks for the quick reply, Doug. From that I would create: http://twitter.com/dougw/status/1472669360
if you change your screen name, that link is going to break. If it didn't, I'd be fine with the Search API since it include screen_names and status ids. Or am I being obtuse and missing something in the status/show call's return value that is permanently linkable? On Jun 25, 11:54 am, Doug Williams <d...@twitter.com> wrote: > With one call to the statuses/show method [1] you could have all of the > information you need to construct the permanent URL. > > 1.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0show > > Thanks, > Doug > > > > On Thu, Jun 25, 2009 at 8:31 AM, jesse <je...@mailchimp.com> wrote: > > > I've been browsing the archives and I believe I know the answer to > > this, but want to confirm. > > > I'm about to start using the Search API to, obviously, collect tweets > > and then store summaries of them grouped by matching terms. That will > > give us some overview stats to display for users which we'd like for > > them to be able to drill into to see individual tweets. At that point > > we would like to make them status and the username clickable to take > > the user to the original status message on the twitter.com . > > > The issue I'm seeing is that I can't reliably create that link > > because: > > 1) users can change their screen names > > 2) there's no way to link directly to a tweet using it's status id > > > I also would rather not start over-using the normal API just to > > recheck usernames to see if they've changed, especially since my > > experience is that that's generally infrequent and eventually I'm > > going to have a lot of cached user data. > > > Am I missing something? > > > Assuming not, and since I also imagine that click-throughs from my > > site will be low, my current plan is to link to my site w/ the status > > id, look it up in real-time, and redirect to the actualy twitter.com > > status message. > > > Anyone have thoughts on that? Additionally, since I may be in a > > position to provide that as a service, would that be something > > whitelist-able if we made it publicly available?
