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