简介：
Twitter 无疑是 World Wide Web 上新近出现的最为成功的一个社交网站的例子。Twitter 提供了一个 API 以便 Web 开发人员能够使其用户访问到 Twitter 站点所能提供的各种特性。在本文中，了解使用 Twitter REST API 的基本知识。
Twitter 是一个简单的基于 Web 的方式，用最多 140 个字符告知某些人您目前正在做的事情。
这是最为简短的定义。
较长的定义则稍微复杂一些，加入了更多价值考虑。Twitter 是如今业界公认的最为成功的一种社交媒介、在线社交网络，即 Web 2.0。使用 Twitter，您可以聚集大量跟随者。然后，您就可以不时地告诉他们您目前从事的事情。您在 Twitter GUI 内键入一个简短的故事（即业界所称的 tweet）并单击按钮，该 tweet 随后就会被传输给所有您的跟随者，他们可以相应地选择阅读、了解、回复或忽略
莎士比亚曾告诉我们说 “言以简洁为贵”。这一哲学得到了 Twitter 权威人士很好的贯彻，比如 tweet 就被限制为最长 140 个字母。实际上，这一限制与莎士比亚完全无关：它应该与 Twitter 刚开发出来时移动设备的局限性有关。但该限制很受欢迎，因为它有效防止了 tweet 内不必要的垃圾信息和措辞混乱。
虽然 tweet 的长度被严格限制，但这些 tweet 的实际内容并未受限制。Twitter 的初衷是为了告诉您的追随者您现在所做的事情。每天有数百万的 tweet 发布，毋庸置疑，其主题并不可能总是一成不变的。人们会发布意见、头条、对其 blog 的链接、对他人 blog 的链接等等。所以 Twitter 的新用户应该准备好收到与 tweeter 的当前所从事的事情毫不相关的 tweet。
与大多数（如果不是全部）的 Web 2.0 一样，Twitter 还具有一个额外的好处：它是免费的。没错，您无需任何成本就可以加入，无需任何成本就可以追随别人，无需任何成本就可以有任意数量的追随者，无需任何成本就可以 tweet。它完全听凭您随意使用。
现在，您应该对 Twitter 及其功能有了一个很宽泛的认识。如果您尚未访问过 Twitter 站点，在进行本文其余部分 的阅读之前，不妨先浏览一下该站点。这样一来，就更容易理解 REST API。
Twitter REST API
了解了基础知识之后，就可以开始研究 Web 应用程序开发人员所感兴趣的东西了。Twitter 不仅仅是社交媒介领域一种很有用的工具，它还能够为开发人员提供一整套的服务来启用 Twitter 功能的自动化。这些服务之一（并且也有可能是最为流行的一种服务）就是 REST API。
REST 是 Representational State Transfer 的缩略语。对 REST 定义的详细和完整解读超出了本文的范畴；不过，在 IBM? developerWorks?（参见 参考资料）的其他地方可以找到相关信息。对于这里所要涵盖的主题，只需知道 REST 的作用是让开发人员通过一个简单的 HTTP 调用就可以访问信息和资源，这就足够了。
举个例子，假设 FishinHole.com 运营了一个向其客户销售钓鱼用具的 Web 站点。访问该站点的用户可以看到各种鱼饵、渔线和鱼竿等。顾客用老的方式操作：通过单击链接。以这种方式，FishinHole.com 可以将其服务提供给客户。
但是 FishinHole.com 还通过用 REST 公开其渔具的产品目录的方式将其服务提供给了其他的 Web 应用程序。所以，与胡乱单击不同，Web 应用程序通过一个简单的 HTTP 调用就可获得有关鱼饵、渔线和鱼竿等的信息。比如，http://www.fishinhole.com/catalog/rest/lures?format=xml 可以以 XML 格式返回该公司所提供的所有鱼饵的列表。又比如，http://www.fishinhole.com/catalog/rest/item?id=343221 可以以默认格式返回条目 #343221 的相关信息。
不妨以这种方式来思考 REST：通过将一个 URL 指向一个特定的位置即可获得特定于域的数据。对于本文的目的而言，这就是全部了。也可以将它想象为一种简化了的 Web 服务，但是如果您找错了人，在其面前对此高谈阔论，则很可能会陷入到辩论当中。
注意：我应该指出的是 FishinHole.com 并不实际存在。所以，如果把这些 URL 粘贴到浏览器中，很有可能会遇到错误。我之所以提供这些例子，只是为了向您展示一个典型的 REST 调用的格式。
您想不想看到一个完全可以工作的 REST API 的例子？一个您可以将其中的 URL 粘贴到浏览器中并返回一些有益信息的例子？那么就请继续阅读本文吧。
立即开始：一个简单的例子
您刚刚阅读完 Joel Comm 的杰作 Twitter Power，并决定今天就开始用 Twitter 通过一个积极主动的在线营销活动获得财政上的独立性。
但是您同时还是一个很棒的软件开发人员。这意味着您更愿意让软件为您完成大部分工作，而不用自己亲历亲为。您不仅要注册一个新的 Twitter 帐号，而且还要开始学习 API 以便可以自动化 Twitter 功能的某些方面。
您第一件想做的事情就是使用此 API 来检索 Joel Comm 的时间表（参见 清单 1）。这很有意义，因为他写过一本让您如此备受启发的书籍。
清单 1. 检索 Joel Comm 的时间表
http://twitter.com/statuses/user_timeline.xml?id=joelcomm
就这么简单。打开另一个浏览器，将该 URL 粘贴到地址栏，然后等待结果。
显然，对该 REST 调用进行更深入的探讨是很必要的。首先，http://twitter.com 前缀应该是自说明的。twitter.com 部分是域名，表明了将要访问位于该名字所映射到的 IP 地址的一个资源。它前面的 http 表明将要使用超文本传输协议。这也是 REST 的常见情况。
接下来，是 /statuses。这表明 Twitter 是如何在一个特定类别指定 REST 函数的。可以将它想象为文件系统内的一个目录。在本例中，被调用的 REST 函数被分类在 statuses 下。在 Twitter 术语中，一个用户状态 基本上也就是一个 tweet，因为它表明的恰是用户现在正在做的事情。
再下来是 user_timeline。这是所调用函数的实际名称。将此函数直观地命名为 user_timeline，因为实际上，检索的是一个用户时间表 或用户最近输入的一系列 tweet。
请不要忘掉此函数名后的 .xml 扩展名：这非常重要。它是检索时间表所采取的格式。这里，使用的是 XML。其他的可用格式为 Java? Simple Object Notation (JSON)、Atom 和 RSS。
使用标准 GET 注释，参数紧随函数，并由问号（?）分隔。在本例中，只有一个参数 ―id― 而且它指定了您想要查看其时间表的那个用户的 Twitter 名。这里，指定了 joelcomm，因为您想查看的就是他的时间表。
评估输出
查看了上述调用的输出后，您发现您更愿意收到 Atom 格式的结果。所幸的是，这不成问题，只需对 清单 1 中的代码做一个很小的更改（清单 2）即可。
清单 2. 以 Atom 格式检索 Joel Comm 的时间表
http://twitter.com/statuses/user_timeline.atom?id=joelcomm
上述 REST 调用所产生的结果类似于 清单 3。如果您将该代码粘贴到您的 URL，您的浏览器可能会要求您下载结果，因为您的浏览器并未被配置成能够显示以 .atom 扩展名结尾的文件。
很显然，Joel 的时间表在本文发表之际（和您阅读本文之际）与在我撰写本文的时侯不一样。所以，得到的结果也会大相径庭。
清单 3. Atom 格式的 Joel Comm 时间表（节选）
<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
<title>Twitter / joelcomm</title>
<id>tag:twitter.com,2007:Status</id>
<link type="text/html" rel="alternate" href="http://twitter.com/joelcomm"/>
<updated>2009-03-22T10:21:31+00:00</updated>
<subtitle>Twitter updates from Joel Comm / joelcomm.</subtitle>
<entry>
<title>joelcomm: thinking...</title>
<content type="html">joelcomm: thinking...</content>
<id>tag:twitter.com,2007:http://twitter.com/joelcomm/statuses/1369295498</id>
<published>2009-03-22T05:15:01+00:00</published>
<updated>2009-03-22T05:15:01+00:00</updated>
<link type="text/html" rel="alternate"
href="http://twitter.com/joelcomm/statuses/1369295498"/>
<link type="image/jpeg" rel="image"
href="http://s3.amazonaws.com/joel1_normal.jpg"/>
<author>
<name>Joel Comm</name>
<uri>http://www.JoelComm.com</uri>
</author>
</entry>
</feed>如果您熟悉 XML，就会发现 清单 3 的大部分都很直观。如果您熟悉 Atom，更会发现它丝毫不陌生。如果您既熟悉 Atom 又 熟悉 Twitter，您完全可以跳过这一章节。
以下是对 清单 3 内的代码的分项描述：
请注意根元素是 feed。根据 Atom 规范，这很标准。Twitter 使用的名称空间是 http://www.w3.org/2005/Atom，被指定为根目录内的一个属性。
title 元素代表的是您正在查看哪个用户的时间表。它还为 Twitter 网站做了一点广告宣传。
link 元素也很重要：它指定了若以老的方式查看（在浏览器手动查看）Joel Comm 的时间表应该使用的那个 URL。
entry stanza 代表的是一个 tweet。虽然出于简单的目的，我只列出了一个，但实际上，在输出中可以看到 20 个这样的 tweet。
请注意 title 和 content 的实际内容是一样的。这是因为 tweet 没有标题，所以标题也就是实际 tweet 本身。还记得么，Atom 的设计初衷就是为了用于文章型文档，这类文档通常具有一个大标题，然后就是主体部分。由于 tweet 并不如此，所以两个元素包含了一模一样的内容。
在 Atom 格式，内容之前是 Twitter 名，然后是一个冒号（:）。这里，joelcomm: 在实际的 tweet 之前。
这里的实际 tweet 是一个美妙无比的语句 thinking...。这是我在写作本文之时 Joel 最新的 tweet。挑剔的人可能会据此判断这说明 Joel 有的时候没有 思考或者 Joel 缺乏有关其最新 tweet 的资料，因此才会不得已随便输入了些东西。不过，我并未把别人的这类猜测放在心上。
id 元素是 Atom 必需的，并且是这个特定的 tweet 的一个全局惟一的标识符（GUID）。Twitter 在世界范围内的所有 tweet 均具有惟一 ID 以便它们能被惟一引用。
published 和 updated（出版和更新）的日期和时间也是相同的。这没错，因为 Joel 仅仅输入了其 tweet，从未更新过。
第一个 link 元素提供了对这个 tweet 的一个链接。继续并将 http://twitter.com/joelcomm/statuses/1369295498 粘贴到浏览器窗口内，此时，应该会看到 Joel 正在 “thinking...”。
第二个 link 元素提供了对 Joel 的相片的一个链接。
author stanza 提供了有关这个 Twitter 用户的信息。这里，您会看到 Joel 的全名以及 Web 站点 URL。
对这个 API 进行了这么多的思考之后，您意识到这些信息非常棒并且您可以很容易地编写代码来解析 Atom 输出。当然，您也可以解析来自其他用户的时间表，而不仅仅限于 Joel Comm 的。所解析的信息可被收集用作这个在线营销活动的相关数据。惟一的限制是您的想象：可能无极限
其他参数
除了 id 之外，user_timeline 还具有其他几个参数。在上例中，还可以指定 screen_name，而非 id。若恰巧知道用户的数字 Twitter ID，还可以在 user_id 参数内指定它。
此外，使用 since_id 参数，可以指定 ID 大于在此参数内指定的数值的那些 tweet（参见 清单 4）。之前，Joel 著名的 “thinking...” tweet 的 ID 为 1369295498。所以，如下的 URL 会返回晚于 这个 tweet 的那些 tweet。
清单 4. 检索 Joel Comm “thinking...” 之后的时间表
http://twitter.com/statuses/user_timeline.xml?id=joelcomm&since_id=1369295498
参数 max_id 基本上是 since_id 的反转。它返回的是 ID 小于 此参数值所指定的 ID 的那些 tweet。
与 ID 相反，参数 since 允许您对时间表过滤器应用一个实际日期。page 参数允许您对结果进行分页。默认的 user_timeline 调用会返回最近的 20 个 tweet。若这些 tweet 的编号为 1-20，那么 清单 5 内的代码会返回 tweet 41-60。
清单 5. 检索 Joel Comm 的第三组 tweet（20 个）
http://twitter.com/statuses/user_timeline.xml?id=joelcomm&page=3
其他函数
到目前为止，您已经充分领略了 user_timeline 函数。除此之外，Twitter API 还提供了其他一些可通过 REST 访问的函数。
public_timeline 函数（清单 6）让您能够看到整个 Twitterverse 内的最新 tweet ― 至少是为那些向公众提供其 tweet 的用户。
清单 6. 最新的 tweet
http://twitter.com/statuses/public_timeline.xml
friends_timeline 函数（清单 7）让您能够看到您跟随的那些人的 tweet。就如同您登录到 Twitter 并径直访问您的 Twitter 主页。
清单 7. 您跟随的那些人的最新 tweet
http://twitter.com/statuses/friends_timeline.xml
若将 清单 7 中的 URL 复制并粘贴到浏览器中，系统会提示您提供您的 Twitter 用户名和密码。您在 Twitter 内的主页是一个安全环境，因它包含了对直接消息的链接。所以，这是 Twitter 部分上的一个安全措施。（我将在本文稍后的部分详细讨论安全性。）
update 函数允许使用 REST API 进行实际的 tweet。在本例中，这个函数调用必须通过 POST 请求（而非 GET 请求）完成。随 POST 请求提交的参数 status 包含这个实际 tweet 的文本。
replies 函数会将这 20 个最新的 @replies 返回给通过身份验证的用户。基本上，@replies 是被特别指定给特定用户的 tweet。比如，如果您 tweet @joelcomm are you done thinking yet?，那么该消息就会显示为一系列特别定向给 Joel Comm 的消息之一。他通过单击其 Twitter 主页上的一个链接就可以看到这些消息。但是，@replies 对跟随发出回复的用户的所有用户也是可见的。
对所有 REST API 函数进行全面详细的解释超出了本文的范围。但是，在 API 文档内有对它们清晰的文档记录。
API 使用上的限制
使用 Twitter REST API 并非随意到可以做任何您想做的事。Twitter 对其 API 的使用做了一定的限制以防止带宽杀手破坏特性集的有用性。
对于初学者而言，只允许最多每小时 100 个请求。虽然，这一限制只应用于 GET（而非 POST）请求，但经验证明它还是一个很不错的规则。如果超出了此限制，REST 调用所产生的文档将会告诉您这一点。所以，不管出于何种原因而必须 调用 Twitter REST API 超过每小时 100 次时，可以从 Twitter 请求 whitelisting。
另一个限制是不管使用 page 还是 count 参数，最多返回 3200 个状态。
此外，Twitter 只请求但并不强制要求其他限制。比如，Twitter 建议使用 page 属性，不建议使用 count 属性。又比如，它还建议对结果进行本地缓存，而不建议重复请求相同的状态
身份验证
正如我之前提到的，某些函数要求身份验证。如想使用 Twitter REST API 并利用这些函数，就必须在请求中包含身份凭证。否则，就会获得状态码 401 的回复。
在本文写作之时，Twitter 只支持 HTTP 基本的身份验证，这意味着此请求头必须以加密的格式包含您的用户名和密码。这之后，您就可以对此 Twitter API 函数进行全面的访问，就好像是从浏览器登录到 Twitter 一样。
目前，Twitter 正致力于寻找一种方式来启用 OAuth 身份验证以获得安全请求。
结束语
Twitter 是进入 Web 2.0 世界的一个很好的切入点。使用 Twitter，您可以借助微型 blog，构建一个由与您志同道合的人组成的完整在线网络。
使用 Twitter REST API，您能够自动化以前用 Twitter 手动实现的所有功能。您可以以编程的方式访问一个特定用户的时间表。您可以直接或间接地回复给该用户。您可以针对您自己感兴趣的信息查找用户的 tweet。您可以基于特定的标准过滤 tweet 并在您自己的 blog 上显示这些 tweet。
存在无限可能性。
from:http://www.ibm.com/developerworks/cn/xml/x-twitterREST/