简介

 

借助 Twitter API，你可以从平台实时流式传输公开推文，以便可以显示这些推文及其基本指标。

 

在本教程中，你将学习如何：

 

  • 为你的工作设定一个目标

  • 计划和准备处理所需的数据

  • 连接适当的 API 端点并对其进行身份验证

  • 处理错误和连接断开

  • 显示推文及其基本指标

     

 

前提条件

 

 

需要考虑的步骤

 

 

步骤 1： 为你的工作设定一个目标

 

首先，定义你想要完成的目标，并确定实现该目标所需的数据。

 

  • 及时了解感兴趣的话题：例如，你想要了解关于 Twitter API 的最新更新、新闻和事件。

  • 监测当前趋势：你很难监测当前的趋势，并且想提炼出预示世人热议的信号。

 

 

步骤 2：计划和准备处理所需的数据

 

及时了解感兴趣的话题

 

以及时了解感兴趣的话题为例，你需要确定所需的数据类型以及实时获取此数据的方法。 

 

继续以了解 Twitter API 的最新更新为例，你需要确保在发布推文时从 @TwitterDev 和 @TwitterAPI 账号获取这些推文。你也可以只需要包含链接的推文，这样你便可以仔细研究推文附带的任何其他相关背景。

 

要实时获取此类数据，可以使用筛选流端点。筛选流端点需要你定义筛选条件，以便让它知道要发送给你的推文类型。

 

定义筛选条件后，你需要将其应用于筛选流端点。 

筛选条件以规则的形式应用于筛选流端点。借助规则， 

你可以使用一组运算符缩小范围，只搜索你要找的推文。

 

创建筛选条件时，考虑你不希望接收的数据类型并从那里逆向操作通常会很有帮助。你需要确保具有正确的关键词并调整规则，以防止不需要的推文进入到流中。有关如何构建更复杂规则的示例，请参阅我们关于构建规则的文档。

 

根据刚刚定义的筛选条件，你可以创建包含以下运算符的规则。

 

  • from:

  • has:links

 

“from:”运算符匹配来自特定用户的任何推文，“has:links”运算符匹配推文正文中包含链接的推文。这些运算符共同构成以下规则，该规则指示筛选流端点筛选出账号 @Twitterdev 和 @TwitterApi 发出的包含链接的推文。 

 

“from:twitterdev from:twitterapi has:links”

 

要添加此规则，请向筛选流规则端点发出 POST 请求，并将添加的有效负载作为规则和运算符的数组。下面的示例展示了如何使用 cURL 来实现此目的。要进行身份验证，请将 $BEARER_TOKEN（包括美元符号）替换为开发者门户中你的应用的不记名令牌。

 

      curl -X POST 'https://api.twitter.com/2/tweets/search/stream/rules' \
-H "Content-type: application/json" \
-H "Authorization: Bearer $BEARER_TOKEN" -d \
'{
  "add": [
    {"value": "from:twitterdev from:twitterapi has:links"}
  ]
}'

 

你还可以使用我们的某个代码示例向规则端点发出 POST 请求

 

 

检测当前趋势

 

以监测当前趋势为例，你需要考虑所需的数据类型，以及执行分析所需的数据量。例如，你可能需要阅读和分析一组广泛但相对可控的推文。此数据也应该是最新或相对最新的。虽然推文的文本可能对于分析至关重要，但你还需要考虑其他数据元素。在推文本身的文本中，你还需要考虑是否需要话题标签、提及，或者是否要查找某些关键词。

 

除去推文文本，推文还包含几个不同的数据字段，因此你需要确定对趋势监测需求最有帮助的字段。例如，基于你确定的字段，你可以对推文有效负载中提供的关键词、话题标签、提及或推文注释执行一些基本的频率分析。默认情况下，你将只会获取每条推文的 ID 和文本。如果你希望返回关于每条推文的其他数据，则可以向请求 URL 添加其他字段和扩展。

 

在制定数据要求之后，你需要弄清楚如何获取这些数据。要获取数据以用于此分析，采样流端点提供的公开推文的 1% 的随机样本可以满足此需求，因为它提供的数据占公开推文总量的一小部分。此外，数据在产生时会实时发送给你，这将满足数据保持最新的要求。

 

 

步骤 3： 连接适当的端点并对其进行身份验证

 

及时了解感兴趣的话题

 

定义了数据并使用规则设置了筛选条件之后，便可以连接到筛选流流式传输端点以开始获取数据。下面的示例展示了如何使用 cURL 来实现此目的。要进行身份验证，请将 $BEARER_TOKEN 替换为开发者门户中你的应用的不记名令牌。

 

      curl -X GET -H "Authorization: Bearer $BEARER_TOKEN" "https://api.twitter.com/2/tweets/search/stream"

 

你还可以使用我们的某个代码示例向流式传输端点发出 POST 请求

 

 

检测当前趋势

 

要连接到采样流端点，请向该端点发出 GET 请求。下面的示例展示了如何使用 cURL 来实现此目的。要进行身份验证，请将 $BEARER_TOKEN 替换为开发者门户中你的应用的不记名令牌。

 

      curl -X GET -H "Authorization: Bearer $BEARER_TOKEN" "https://api.twitter.com/2/tweets/sample/stream"

 

你也可以使用我们的某个代码示例连接到采样流端点

 

 

 

步骤 4：处理错误和连接断开

 

在连接到筛选流端点或采样流端点的任何时候，都可能会出现自主或非自主的连接断开情况。当你单独终止与流式传输端点的连接时，无论是因为代码主动关闭了连接，还是网络设置终止了连接，都会发生自主的连接断开。当任一流式传输端点主动断开应用与流的连接时，便会发生非自主的连接断开。这些类型的连接断开由以下其中一个原因导致。

 

  • 缓冲区满载：应用读取数据的速度不够快，或者网络瓶颈使数据流变慢。

  • 连接过多：应用与数据流的同时建立的连接过多。发生这种情况时，筛选流端点将等待 1 分钟，如果仍然超出限制，则会断开最近建立的连接。

  • 服务器维护：Twitter 团队对系统服务器部署了更改或更新

 

你应在代码中构建适当的逻辑，以便在发生这些非自主连接断开时自动重新连接。另外，如果你只在有限的时间内需要推文，那么建议考虑在适当的时间在代码中进行构建，以便在所需的时间段过去之后断开与流式传输端点的连接。

 

为了避免因将要接收大量推文所致的缓冲区满载错误，代码在读取流时不应执行任何实际的处理工作。读取流，然后将动态传递到另一个线程或进程以进行异步处理。此处理工作可以包括执行频率分析或任何类型的繁重处理工作。

 

有关如何构建应用程序的重新连接逻辑的示例，请查看以下使用筛选流端点的示例应用。

 

 

 

步骤 5： 显示推文及其基本指标

 

可靠地获取数据之后，你需要考虑想要如何处理这些数据。一个常见选择是在网页或面板上显示其中一些数据，以及描述一段时间内发生的情况的一些基本指标。 

 

你应记住，由于 ID 和文本是推文的基本构成要素，因此应始终填充它们，但其他字段可能并不总是存在。例如，并非所有推文都包含图片附件。你需要根据推文的性质考虑要查找的数据所在的字段、想要显示的字段，以及可能并不总是存在的字段。最后，在显示推文时，你还需要参考并遵守 Twitter 的显示要求。使用嵌入式推文可以帮助满足这些要求。

 

如果你想要保留一段时间内读取的变动的推文总数并将其显示在图表中，那么你应该记住，推文数可能会根据给定时间内发推的用户数而发生波动。建议创建一个可视化效果来显示这些随时间变化的波动。此外，当你获取和显示这些推文时，你可能想要将它们暂时保存到数据存储中并显示最新的推文，或根据一次可以传入的推文数和有限的屏幕空间逐页组织它们。你还可以考虑根据推文的有机性能指标（例如获得最多转推、回复或收藏次数的指标）来显示推文。

 

最后，考虑由于某人转推或回复了某一推文，因此推文可以相互关联。如果这有助于实现你的目标，建议使用一种指示此关系的方式（如果有）来显示推文。

 

 

后续步骤