超出速率限制 - 自定义 Twitter 应用

发布于 2024-09-13 08:41:50 字数 370 浏览 6 评论 0原文

我正在使用 java Twitter 应用程序(使用 Twitter4J api)。我已经创建了该应用程序,可以查看当前用户的时间线、用户的个人资料等。

但是,在使用该应用程序时,它似乎很快就超过了 Twitter 客户端上设置的每小时 150 个请求的速率限制(我知道开发人员可以将其增加到给定帐户上为 350,但这对于其他用户来说无法解决)。

当然,这不会影响所有客户,关于如何解决这个问题有什么想法吗?

有谁知道什么算请求?例如,当我查看用户的个人资料时,我加载用户对象 (twitter4j),然后获取屏幕名、用户名、用户描述、用户状态等以放入 JSON 对象中 - 这是否是获取对象的单个调用或者是否会包含所有 user.get... 调用?

提前致谢

I am working with a java Twitter app (using Twitter4J api). I have created the app and can view the current users timeline, user's profiles, etc..

However, when using the app it seems to quite quickly exceed the 150 requests an hour rate limit set on Twitter clients (i know developers can increase this to 350 on given accounts, but that would not resolve for other users).

Surely this is not affecting all clients, any ideas as to how to get around this?

Does anyone know what counts as a request? For example, when i view a user's profile, i load the User object (twitter4j) and then get the screenname, username, user description, user status, etc to put into a JSON object - would this be a single call to get the object or would it several to include all the user.get... calls?

Thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

柳絮泡泡 2024-09-20 08:41:50

在与 Twitter 打交道时,您确实需要跟踪当前的请求计数。

然而,twitter 似乎并没有删除 304 Not Modified 的计数(至少我上次处理它时没有),因此请确保没有任何东西破坏您对 HTTP 缓存的正常使用以及您的实际请求每小时上涨。

请注意,twitter 在 apache 上的 mod_gzip 中遇到了一个错误,其中电子标签在更改时格式错误,以反映内容编码与非 gzip 压缩实体的内容编码不同(这是正确的做法,有只是实现中的一个错误)。因此,接受来自 Twitter 的 gzip 内容意味着它永远不会发送 304,这会增加您的请求计数,并且在许多情况下会破坏使用 gzip 带来的效率提升。

因此,如果您接受 gzip(您的网络库默认情况下可能会这样做,请查看使用 Fiddler 之类的工具可以看到什么,我是一个只有一点 Java 知识的 .NET 人员,在 twitter 的级别上回答处理 HTTP,所以我不知道 Java Web 库的详细信息),尝试将其关闭,看看它是否会改善情况。

You really do need to keep track what your current request count is when dealing with Twitter.

However, twitter does not seem to drop the count for 304 Not Modified (at least it didn't the last time I dealt with it), so make sure there isn't something breaking your normal use of HTTP caching, and your practical request per hour goes up.

Note that twitter suffers from a bug in mod_gzip on apache where the e-tag is mal-formed in changing it to reflect that the content-encoding is different to that of the non-gzipped entity (this is the Right Thing to do, there's just a bug in the implementation). Because of this, accepting gzipped content from twitter means it'll never send a 304, which increases your request count, and in many cases undermines the efficiency gains of using gzip.

Hence, if you are accepting gzip (your web-library may do so by default, see what you can see with a tool like Fiddler, I'm a .NET guy with only a little Java knowledge, answering at the level of how twitter deals with HTTP so I don't know the details of Java web libraries), try turning that off, and see if it improve things.

此岸叶落 2024-09-20 08:41:50

几乎所有类型的 Twitter 服务器读取(即任何调用 HTTP GET 的操作)都算作请求。获取用户时间线、转发、私信、获取用户数据均算作 1 个请求。几乎唯一从服务器读取而不考虑 API 限制的 Twitter API 调用是检查速率限制状态。

Almost every type of read from Twitter's servers (i.e. anything that calls HTTP GET) counts as a request. Getting user timelines, retweets, direct messages, getting user data all count as 1 request each. Pretty much the only Twitter API call that reads from the server without counting against your API limit is checking to see the rate limit status.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文