假设有移动应用和服务器。
我对速率限制有疑问，并希望有人可以就设计提出一些建议，因为我正在敲打如何绕过速率限制。必须有一些我失踪的东西，因为每小时每小时150个未经验证的速率限制非常低。
想象一下，我想要构建的场景如下（简化为一个简单的例子）。 假设用户已在整个讨论中登录Twitter，以删除有关oAuth的讨论。
Mobile talks to our service to show users twitter friends list. Every time the mobile app is loaded, it will show the entire friends list, and highlighting the new friends that were added within the last 2 days.
就是这样。但问题是我想确保朋友列表在客户端始终是最新的，这意味着我们的服务器必须拥有最新的朋友列表。
我希望我的服务器能够定期自动扫描我的应用的每个用户的Twitter好友列表，看看是否添加了新朋友。
我们最初的设计是让我们的服务器完成这个流程的所有工作：
定期（例如每48小时），服务器检查每个用户的朋友列表的Twitter REST API，并将其与我们的缓存Twitter朋友列表进行比较，以便他们查看谁是新用户并在移动应用中突出显示。
关于这一点的好处是，所有与twitter的交互，以获得朋友列表，比较和peridiocally刷新是在服务器上。移动客户端只需拨打一个电话到我的服务器并获取好友列表。
这个设计的问题在于它适用于单个用户，但由于未经认证的呼叫的速率限制是每小时150，所以一旦151个用户使用我的服务（我有一个固定IP）。
我能看到的唯一解决方案是让客户端为每个用户完成工作，然后将我的服务器缓存的朋友列表发送给我。这将照顾上面的步骤＃2。但是，对于步骤＃4，我必须在客户端构建一些东西来自动刷新Twitter朋友并发送回服务器。
在Twitter好友列表操作中让客户参与其中是非常笨拙的。
起初我以为自己很疯狂，公众未经身份验证的API就像获取好友列表一样，不会受到速率限制。但是，根据他们的文档，它是。
我错过了一些明显的东西，或者解决这个问题的唯一方法是将重要的逻辑放入客户端？
答案 0 :(得分：9)
如果whitelisting gone对于那些没有受到贿赂的人或Twitter业务合作伙伴，我认为您没有其他选择，只能让您的移动应用程序通过手机进行Twitter API调用。
手机拨打Twitter无论如何都不是坏事。几乎世界上每个Twitter客户都这样做。一个好处是用户将通过Twitter进行身份验证，因此您可以使用每小时完整的350个呼叫。但请记住，您应该尽量减少通话，因为用户可能会在手机上安装其他支持Twitter的应用程序，这会影响您的通话分配，反之亦然。
现在解决方案。我实现您的用例的方法是首先通过调用friends/ids方法为您的用户获取完整的朋友列表。
http://api.twitter.com/1/friends/ids.json?screen_name=yourUsersName
上面的调用将返回最近的5,000个朋友ID，按顺序依次为 @yourUsersName 。如果您想获取比前5,000个朋友ID更多的朋友ID，则需要指定光标参数来启动paging。
接下来，我会检查我们刚刚在手机上的列表中获取的最新朋友列表，通过删除任何不再存在的ID来同步它们，同时添加任何新的ID。
如果我们只需要朋友ID，那么我们就需要花费每5,000个朋友ID一次API调用。但是，如果我们还需要获取这些新朋友的用户信息，那么我会调用users/lookup并传递我们在同步朋友ID时发现的所有新用户的列表。您一次最多可以请求100个用户对象。
http://api.twitter.com/1/users/lookup.json?user_id=123123,5235235,456243,4534563
您的用户必须进行身份验证才能发出上述请求，但该呼叫可以获取您希望的任何Twitter用户个人资料 - 而不仅仅是那些经过身份验证的用户的朋友。
所以，举个例子来说，一个用户有2,500个朋友，之前从未使用过您的应用。在这种情况下，她会烧掉一个电话来获取所有的朋友ID，并拨打25个电话给她朋友的信息。使用数据填充应用程序并不算太糟糕。
后续调用应该更加简化，可能只有两个调用被烧毁（一个用于ID，一个用于获取新朋友）。
最后，一旦手机上的数据更新，就可以收集ID和用户数据的增量并推送到您的服务器。
甚至可能您的服务器应用程序根本不需要与Twitter接口，这应该可以减轻您遇到的150个用户限制。
最后的一些说明：
我回答了一个关于有效提取粉丝的方法的类似问题here。
答案 1 :(得分：3)
由于您是代表用户提出请求，因此您应该将这些请求作为这些用户进行身份验证。然后请求将计入每个用户自己的350个请求/小时池。