Question

API 可以像数据响应请求一样简单，但是很难找到只有这个功能的 API 了。大多数的 API 还有其他有用的特性。这些特性包括多种不同的 API 请求方法（REST 或流式请求）、数据时间戳、频率限制、数据分级，以及 API 访问对象（key 和 token）。让我们通过 Twitter API 的上下文看一下这些特性。

13.1.1　REST API与流式API

Twitter API 有两种形式：REST API 和流式 API。大多数的 API 是 REST 形式的，但是一些实时服务通常会提供流式 API。REST 的全称为 Representational State Transfer（表述性状态转移），被设计用来构建稳定的 API 架构。可以使用 requests 库（见第 11 章）来获取 REST API 的数据。通过 requests 库，你可以发出 GET 和 POST Web 请求——这是 REST API 用来返回对应数据所使用的方法。在 Twitter 这个实例中，REST API 允许你查询推文，发布推文，做 Twitter 允许通过网站做的绝大多数事情。

　通过 REST API，你经常可以（但并不总是可以）在浏览器中通过请求 API 链接预览查询。如果在浏览器中加载了 URL，结果看起来像是文本块，你可以在浏览器中安装一个格式化预览插件。例如，Chrome 有 JSON 文件的预览插件，通过一种更好阅读的方式预览 JSON 内容。

流式 API 作为一种实时服务运行，监听对相关数据的请求。碰到流式 API 时，你会想要使用一个构建好的库帮助管理数据的拉取。想详细了解多 Twitter 流式 API 是如何工作的，可以查看 Twitter 网站上的概述（https://dev.twitter.com/streaming/overview）。

13.1.2　频率限制

API 通常都有频率限制，限制用户在一段时间内能够请求的数据数量。频率限制由 API 提供者出于多种不同的原因使用。除了频率控制，你可能还会碰到对数据访问有限制的 API，特别是数据与商业利益相关时。出于基础设施和客户服务的考虑，API 提供者会想要控制请求的数量，这样服务器和架构可以控制数据传输数量。如果允许每个人在 100% 的时间使用 100% 的数据，这可能会导致 API 服务的崩溃。

如果遇到需要支付额外费用来取得特殊访问权限的 API，你需要确定是否有能力支付，以及数据对研究有多大的价值。如果碰到有频率限制的 API，你需要确定是否数据的一个子集就足够了。如果 API 有频率限制，可能会花费相当长的时间来收集一个有代表性的样例，所以一定要评估你想要投入在这之上的努力程度。

API 通常会对所有的用户有频率控制，因为这样更易于管理。Twitter 的 API 曾经也使用这种方式；然而，随着流式 API 的出现，用法发生了改变。Twitter 的流式 API 提供了数据的常量流，而 REST API 限制了每 15 分钟你可以发出请求的数量。为了帮助开发者理解频率限制，Twitter 发布了一张图表（https://dev.twitter.com/rest/public/rate-limits）。

在练习中，我们会使用名叫获取搜索 / 推文（GET search/tweets）的 API。这个接口返回包含特定搜索语素的推文。如果你查看文档（https://dev.twitter.com/rest/reference/get/search/tweets），会发现 API 返回 JSON 格式的数据，频率限制在每 15 分钟 180 次或 450 次，取决于你是以用户还是应用的身份请求 API。

　保存来自 API 资源的数据文件时，你可以保存很多文件，或者将数据写入一个文件。正如在第 6 章学到的，你也可以保存推文数据到数据库。无论你用什么方式来保存数据，确保定期保存数据，不丢失任何已经请求的数据。

在第 3 章，我们处理了一个 JSON 文件。如果在每 15 分钟之间最大化 API 使用频率，可以收集 180 个 JSON 文件。如果你碰到了频率限制问题，需要优化对 Twitter 或者其他 API 的请求，请阅读 Twitter 的“API 频率限制”（https://dev.twitter.com/rest/public/rate-limiting）这篇文章中的“避免碰到频率限制的一些建议”这一节。

13.1.3　分级数据卷

迄今为止，我们已经讨论了通过其 API 可免费获取的 Twitter 数据。但是或许你想要知道怎样能够得到所有的数据？在 Twitter 这个实例中，你可能听说过三种数据访问级别： firehose、gardenhose 和 Spritzer。Spritzer 是免费的 API。表 13-1 描述了这些级别之间的不同。

表13-1：Twitter feed类型

feed 类型	覆盖	可用性	花费
firehose	所有推文	通过合作伙伴可用——DataSift（http://datasift.com/）或 Gnip（https://gnip.com/）	$$$
gardenhose	10% 的推文	新的访问不再可用	不可用
Spritzer	1% 或不到 1% 的推文	通过公共 API 可用	免费

看到这些选项你可能会想：“我需要 Firehose，因为我想要所有的数据！”但是在你尝试取得访问权限之前，需要知道下面这些事情。

· firehose 是一个很大的数据。当处理海量数据时，你需要规模化数据处理。仅仅开始查询 firehose 提供的数据集，也会需要很多的工程师和服务器。

· firehose 需要付费——一年几十万美元。这不包括你需要消耗的基础设施的花费（即服务器空间和数据库耗费）。使用 firehose 通常不是一个人可以独自做的事情——通常，由一个大型的公司或者机构支撑这些花销。

· 大部分你真正需要的，可以从 Spritzer 得到。

我们会使用 Spritzer，这是 Twitter 的免费公开 API，通过它可以在频率限制下取得推文。为了访问这个 API，我们会使用 API key 和 token。

13.1.4　API key和token

API key 和 token 是用来鉴别应用和用户的方式。Twitter API key 和 token 可能会让你迷惑。这里有四个你需要了解的概念。

· API key

标识应用。

· API secret

类似于应用的密码。

· token

标识用户。

· token secret

类似于用户的密码。

这几部分的组合给予我们访问 Twitter API 数据的权限。然而并不是所有的 API 都拥有这两层标识和密钥。Twitter 是一个很好的“最佳案例”（即更加安全的）示例。在一些情况下，API 会没有 key 或者只有一个 key。

创建一个Twitter API key和访问token

继续童工雇用的研究，收集 Twitter 上关于童工雇用的讨论。创建一个 Twitter API 的 key 很简单，但是需要以下几步。

(1) 如果你没有 Twitter 账户，先注册（https://twitter.com/signup）。

(2) 登录 apps.twitter.com。

(3) 点击“创建新应用”（Create New App）按钮。

(4) 给你的应用一个名称和描述。例如，名称设置为“童工讨论”，描述设置为“拉取 Twitter 上关于童工的讨论”。

(5) 给你的应用添加一个网站——这个网站托管着应用。指引这样写道：“如果你还没有一个 URL，可以先在此放置一个占位符，但是记得之后修改它。”我们并没有这样一个网站，所以把 Twitter 的 URL 放在这一栏中。确保你的 URL 中包含了 https，例如：https://twitter.com。

(6) 同意开发者协议，点击“创建 Twitter 应用”（Create Twitter Application）。

在创建了应用之后，你会被带到应用管理页。如果你找不到这个页面，可以通过回到应用起始页（https://apps.twitter.com/）找到它。

现在，你需要创建一个 token。

(1) 点击“Keys 和访问 Tokens”（Keys and Access Tokens）键。（这里你可以重置 key，同样可以创建一个访问 token。）

(2) 滚动到页面底部，点击“创建我的访问 token”（Create my access token）按钮。一旦你完成了这些，这个页面会通过在顶部更新来刷新。如果再一次滚动到页面底部，你会看到访问 token。

现在你应该有了一个消费者（API）key 和一个 token。下面是我们的 key 和 token。

· 消费者 key：5Hqg6JTZ0cC89hUThySd5yZcL

· 消费者 secret：Ncp1oi5tUPbZF19Vdp8Jp8pNHBBfPdXGFtXqoKd6Cqn87xRj0c

· 访问 token：3272304896-ZTGUZZ6QsYKtZqXAVMLaJzR8qjrPW22iiu9ko4w

· 访问 token secret：nsNY13aPGWdm2QcgOl0qwqs5bwLBZ1iUVS2OE34QsuR4C

不要跟任何人分享你的 key 或 token ！如果你和朋友分享了 key，他们可以在电子层面上代表你。如果他们滥用这个系统，你可能会失去访问权限，并为他们的行为负责。

为什么发布自己的应用？其中一个原因是我们可以生成更多个。在生成新的 key 和 token 的过程中，已经禁用了本书包含的 key 和 token——如果意外地暴露了 key 或者 token，这也是你应该做的事情。如果你需要创建一个新的 key，去“Keys 和访问 Tokens”（Keys and Access Tokens）栏目，点击“重新生成”（Regenerate）按钮。这会为你重新生成一个新的 API key 和 token。

现在有了一个 key，让我们访问 API ！