Welcome the users/show returns data when no user is specified issue to the crew [1].
1. http://code.google.com/p/twitter-api/issues/detail?id=416 Doug Williams Twitter API Support http://twitter.com/dougw On Fri, Apr 3, 2009 at 6:50 AM, Tim Rosenblatt <trose...@gmail.com> wrote: > > Seconding this. > > On Apr 3, 4:51 am, Todd Sampson <toddsampson2...@gmail.com> wrote: >> If you are going to deprecate this method, can you at least return a >> user not found error as opposed to returning user "twitter.com/show"? >> I have received numerous complaints that users we lookup are being >> assigned to user "show" and their "TonsOfWeed.com" website -- which >> for obvious reasons is not the way to handle a deprecated function. >> >> - Todd >> >> On Apr 2, 9:00 pm, John Sampson <j...@johnasampson.com> wrote: >> >> > Thank you for the clarity and for putting greater detail on the >> > deprecation of user/show (find by email). I completely agree to >> > Twitter wanting to protect its user's privacy. I'd like to think that >> > the value created by whitelisted applications is far greater than the >> > pain being caused by non-whitelisted api users. I hope that a speedy >> > solution can be found for these spammers. >> >> > Much of my concern I'd previously mentioned on ticket #353 >> > -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. >> >> > To be clear, this does break the Twitter integration with our Firefox >> > extension (which I consider the most valuable portion of our ext), >> > surfacing information for user with screen name "show" rather than the >> > person you are connecting with keyed off email. Additionally, >> > workflow need be re-authored in our other apps that have leveraged >> > this method to date. >> >> > Hoping I can be of further assistance in returning this method to the >> > production API. >> >> > John Sampsonhttp://zentact.com >> >> > On Apr 2, 5:59 pm, Doug Williams <d...@twitter.com> wrote: >> >> > > For a few days, the users/show method offered look up based on a >> > > user's email address. So short-lived was its documented availability >> > > that we removed it without much fanfare. This thread [1] has mention >> > > of this deprecation. >> >> > > Recently, there has been quite a bit of discussion on this feature's >> > > reinstatement on and off the list. Issue 353 [2] covers this request. >> >> > > The use of the method was largely as intended; people were discovering >> > > account connections based email addresses. This made integration with >> > > other networks and applications trivial. However, there was a >> > > significant amount of traffic that was using this parameter for evil. >> > > In either case, the adoption was minimal (we did not receive a >> > > complaint that the deprecation completely broke someone's >> > > application). The rationale for deprecation was to protect our users' >> > > privacy. >> >> > > We do realize the large amount of value that this parameter creates >> > > for application developers. However at this time, we are working to >> > > identify a solution for the spammers that caused the deprecation. One >> > > suggestion is to grant trusted applications access to this parameter. >> > > Since our answer to trusting applications is OAuth and it is still in >> > > beta, we will not be able to devote the resources necessary to bring >> > > this parameter back at this time. >> >> > > If you are developing an application that could benefit from an >> > > email-based lookup, please star the issue [2] accordingly. >> >> > > 1.http://groups.google.com/group/twitter-development-talk/browse_thread... >> > > 2.http://code.google.com/p/twitter-api/issues/detail?id=353 >> >> > > Thanks, >> > > Doug Williams >> > > Twitter API Supporthttp://twitter.com/dougw >
