实时 Twitter 回复？
我为许多地理位置创建了 Twitter 机器人。我希望允许用户使用命令@-回复 Twitter 机器人，然后让机器人回复结果。我希望机器人尽快（实时）回复用户。
显然，Twitter 曾经有一个 XMPP/Jabber 界面，可以提供这种类型的实时回复，但它已被关闭。
据我所知，我的选择是使用以下之一：
REST API
这将涉及每 X 分钟对每个机器人进行轮询。这样做的问题是它不是实时的，并且必须对每个 Twitter 帐户进行轮询。
搜索 API
搜索 API 允许指定“-to搜索中的参数和对所有机器人的回复可以在搜索中聚合，例如“-to bot1 OR -to bot2...”。不过，如果您有数百个机器人，那么搜索字符串会变得很长，并且可能超过 GET 请求的最大长度。
流 API
流 API 看起来非常有前途，因为它提供了实时结果。该 API 允许您指定 follow 和 track 参数。 follow 没有用，因为机器人不知道谁将向其发送命令。 track 允许您指定要跟踪的关键字。这可以通过创建一个连接到 Streaming API 并跟踪对机器人名称的所有引用的守护进程来实现。再次，由于有很多机器人来跟踪查询的长度和复杂性可能是一个问题。另一个想法是跟踪特殊的主题标签，例如 #botcommand，然后用户可以使用此语法 @bot1 Weather #botcommand 发送命令。然后，通过使用 Streaming API 跟踪对 #botcommand 的所有引用，将为您提供所有命令的实时流。然后可以进行进一步的解析以确定将命令发送到哪个机器人。这篇博文提供了有关 Streaming API
第三方服务
是否有任何第三方公司可以访问 Twitter firehouse 并提供实时数据？
我还没有调查过这些，但这里有一些我发现的：
- Gnip
- Tweet.IM
- excla.im< /a>
- TwitterSpy - 似乎使用轮询，而不是实时
- tweethook
我倾向于使用 Streaming API。有没有更好的方法来为许多（数百个）Twitter 帐户提供接近实时的@回复？
更新： Twitter 刚刚宣布，未来他们将拥有基于 Streaming API 扩展的 User Streams。 用户流预览
I have created Twitter bots for many geographic locations. I want to allow users to @-reply to the Twitter bot with commands and then have the bot respond with the results. I would like to have the bot reply to the user as quickly as possible (realtime).
Apparently, Twitter used to have an XMPP/Jabber interface that would provide this type of realtime feed of replies but it was shut down.
As I see it my options are to use one of the following:
REST API
This would involve polling every X minutes for each bot. The problem with this is that it is not realtime and each Twitter account would have to be polled.
Search API
The search API does allow specifying a "-to" parameter in the search and replies to all bots could be aggregated in a search such as "-to bot1 OR -to bot2...". Though if you have hundreds of bots then the search string would get very long and probably exceed the maximum length of a GET request.
Streaming API
The streaming API looks very promising as it provides realtime results. The API allows you to specify a follow and track parameters. follow is not useful as the bot does not know who will be sending it commands. track allows you to specify keywords to track. This could possibly work by creating a daemon process that connects to the Streaming API and tracks all references to the bot's names. Once again since there are lots of bots to track the length and complexity of the query may be an issue. Another idea would be to track a special hashtag such as #botcommand and then a user could send a command using this syntax @bot1 weather #botcommand. Then by using the Streaming API to track all references to #botcommand would give you a realtime stream of all the commands. Further parsing could then be done to determine which bot to send the command to. This blog post has more details on the Streaming API
Third-party service
Are there any third-party companies that have access to the Twitter firehouse and offer realtime data?
I haven't investigated these, but here are a few that I have found:
- Gnip
- Tweet.IM
- excla.im
- TwitterSpy - seems to use polling, not realtime
- tweethook
I'm leaning towards using the Streaming API. Is there a better way to get near realtime @-replies for many (hundreds) of Twitter accounts?
UPDATE: Twitter just announced that in the future they will have User Streams which expands upon the Streaming API. User Streams Preview
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
跟踪或关注都适用于您描述的情况。请参阅http://apiwiki.twitter.com/Streaming-API-Documentation#track 有关轨道实际功能的详细信息。下面的文档位于同一页面上。
流 API 存在某种速率限制，但它们与您消耗的总推文流的大小有关。如果没有相当大的用户群，编写这样的机器人就不会达到这些限制。当您获得该用户群时，您可以申请提升访问级别以增加速率限制。
Either track or follow will work for the cases you describe. See http://apiwiki.twitter.com/Streaming-API-Documentation#track for details on what track actually does. The doc on follow is on the same page.
There are rate limits of sorts on the streaming API, but they have to do with how big a slice of the total tweet stream you're consuming. For writing a bot like this you won't hit these limits without a pretty big user base. And when you get that user base you can apply for elevated access levels that increase the rate limets.
有 twitter firehose 但您可能最好使用 Streaming API。消防水带向谷歌开放（尝试用谷歌搜索你的推特名称），正如链接所说，他们很快就会向所有人开放。
您还需要获取您的 IP 白名单。
如果您还没有，您可以查看 Twitter 开发人员的 GoogleGroup。
There's the twitter firehose but you're probably best off using the Streaming API. The firehose is open to Google (try googling your twitter name) and as the link says they're opening it up to all soon enough.
You'll want to get your IP whitelist too.
If your not already, you want to check out the GoogleGroup for twitter devs.
流 api 的跟踪谓词实际上很有用，因为如果您跟踪机器人的用户 ID，您将获得机器人发出的所有消息以及提及您的机器人 @usernames（包括 @replies）的所有其他消息。它确实会跟踪 Twitter 上公开的与您关注的用户 ID 相关的所有内容，请尝试一下。
The track predicate for the streaming api would actually be useful because if you follow your bot's user IDs, you'll get all the messages made by your bots and all the other messages that mention your bots @usernames (including @replies). It really does track everything public on twitter relating to the user IDs you follow with it, give it a shot.
REST API：
最全面的结果，误报最少。如果机器人正在关注受保护的帐户，则将包括受保护的状态。如果您每 30 秒轮询一次，那么它非常接近实时，并且如果您将 api.twitter.com/1 与 OAuth 一起使用，您将远低于速率限制（350/小时）。
Streaming API：
您将希望避免使用搜索 API。它越来越倾向于流行的结果而不是完整的结果。
Streaming API
速度最快，但也可能会错过某些状态并包含误报。例如，不包括受保护状态。跟踪 screen_name 将返回其中包含该 screen_name 的状态，但还将包含仅将 screen_name 作为字符串而不包含 @ 的推文，因此请务必在您这边进行过滤。
REST API:
The most comprehensive results with the least amount of false positives. Will include protected statuses if the bot is following the protected account. If you poll every thirty seconds it is pretty close to realtime and you will be well under your rate limit (350/hour) if you are using api.twitter.com/1 with OAuth.
Streaming API:
You will want to avoid the Search API. It is trending more and more towards popular results and not complete results.
Streaming API
The fastest but also likely to miss some statuses as well as include false positives. Protected statuses for example are not included. Track for a screen_name will return statuses with that screen_name in it but will also include tweets that just have the screen_name as a string without the @ so be sure to filter on your side.