Twitter API是否真正符合RESTful标准？

Question

随着一半的Web开发者社区一样，我一直在努力理解和真正掌握REST风格。更具体地说，我一直在尝试形成一些关于Web浏览器和应用程序服务器之间纯RESTful架构实际上有多实用的观点。

作为我的学习努力的一部分，我一直在查看一些在线REST示例，特别是在Twitter中。在他们的API文档中，他们讨论了各种“REST API方法”。

我很难理解大多数这些方法实际上如何符合RESTful标准，除了具有RESTful URL结构之外。例如，考虑对http://twitter.com/favorites的简单GET请求。

在REST的纯实现中，我期望该URL的相同请求无论由哪个客户端发起，都会返回相同的响应。然而，在这种情况下，我们显然会根据当前经过身份验证的用户看到不同的响应，这意味着在生成响应之前，我们的请求与服务器上的某种客户端状态进行了连接。

希望这提供了足够的背景来回答我的问题 - 那真的可以称为“REST”吗？我认为，在Web浏览器和应用程序服务器之间所谓的90％RESTful实现中，忽略了存储在服务器上的客户端状态的限制，存在着同样的不一致性。

- jmar777

---

请参见https://dev59.com/53VC5IYBdhLWcg3wnCSA。 - Robert Harvey

Answer 1

Twitter 违反了几乎所有 REST 的限制。你提到的http://twitter.com/favorites根据认证用户返回不同结果，就是 Twitter 违反了“资源标识”约束的一个例子。每个有意义的资源应该有一个唯一的标识符。我的 Twitter 收藏和你的 Twitter 收藏是两个不同的资源，因此应该有两个不同的 URI。

这实际上与幂等性无关。幂等性是指能够多次发送相同请求而产生相同的效果。即使 Twitter 也尊重幂等性。如果我多次 GET 我的收藏夹，我仍然会得到我的收藏夹。我发送 GET 请求的次数不会影响结果。

Twitter 还有许多其他违反 REST 约束的方式。这些问题在 SO 上已经被讨论过许多次。

更新 在更深入地浏览 Twitter api 文档后，实际上有另一种正确标识收藏资源的 URI 格式。这里展示了如何创建这样的 URL：

http://api.twitter.com/1/favorites/bob.json

虽然它仍然远未达到 RESTful 的标准，但至少这是朝着正确方向迈出的一步。

- Darrel Miller

---

达瑞尔，我不会说基于验证用户返回不同结果违反资源标识约束：“URI仅仅标识一个资源，描述为当前验证用户的收藏”，就像http://twitter.com/home是我的Twitter页面，https://www.google.com/history/是“我的”历史记录而不是你的。它并没有提供太多链接的实用性，因为这本质上对每个人都有不同的含义。 - mogsie

@DarrelMiller 现在可以认为 Twitter API 是符合 RESTful 的标准了吗？自从两年前有人提出这个问题以来，Twitter 可能已经发展成为更好的 RESTful 了吧？ - bhargav

@bhargav 不，甚至都不接近。 - Darrel Miller

@DarrelMiller，你能推荐一些正在使用REST API的开源项目吗？ - bhargav

@bhargav，也许你可以创建自己的 Web 服务，将其他服务（如 Twitter）封装并 REST 化。Twitter 仍然不是 RESTful 的，因为它们提供了一堆 URI 和 URI 模板，而不是定义媒体类型并提供单个入口点 URI。这还没有涉及到链接和关系... - tuespetre

Answer 2

在这个上下文中，幂等性是一个棘手的词。即使您正在检索单个推文，如果该推文可编辑并且有人编辑了它，您也会得到不同的结果。当检索列表时，我肯定希望推文检索最新列表。

更有用的是将幂等性视为能够执行某些操作而不会引起副作用的能力。因此，在这个意义上，GET是幂等的，但POST不是。

从维基百科中：

在计算机科学中，术语幂等性用于描述可以安全地多次调用的方法或子例程调用，因为调用过程一次或多次具有相同的结果；即，在任何数量的方法调用之后，所有变量的值与第一次调用之后的值相同。没有副作用的任何方法或子例程也是幂等的。

另外来自维基百科： 方法PUT和DELETE被定义为幂等的，这意味着多个相同的请求应该与单个请求具有相同的效果。

相比之下，POST方法不一定是幂等的，因为多次发送相同的POST请求可能会进一步影响状态或引起其他副作用（例如金融交易[例如客户错误地两次收取相同的产品费用]）。

另请参阅：

《如何向我的妻子解释REST》 http://tomayko.com/writings/rest-to-my-wife

- Robert Harvey

---

PUT是幂等的。但它不安全。GET是幂等和安全的。你对幂等性的定义实际上是安全的定义。 - Darrel Miller

这是一个很好的观点...也许强调幂等性不是我该关注的重点。我认为无状态性才是问题的核心。乍一看，由于状态问题，它似乎显然不符合RESTful标准...但像这样的服务被广泛认可为符合RESTful标准，我想确认我没有忽略任何理性的解释... - jmar777

@Robert，你的回答如何回应这个问题？Twitter API 的哪一部分违反了HTTP规范中方法应该是安全和幂等的定义？ - Darrel Miller

@jmar777 没有会话。请求是自描述的。唯一的错误是服务器需要使用身份验证信息来识别用户，以便返回正确的收藏夹。有趣的是，Twitter API 也支持适当的 URI 格式。例如：http://api.twitter.com/1/favorites/bob.rss 使用此格式，资源通过 URL 唯一标识。 - Darrel Miller

@jmar777 用户身份验证信息在认证头中。至少以前是这样的。不确定OAuth如何工作。 - Darrel Miller

Answer 3

查看文档，单词“方法”的使用可能是确定API是否真正符合RESTful的好指标。有一些资源可能确实符合此类要求，例如friends/<user-id>或favourites/<user-id>，但大多数资源实际上只是过程，例如account/update_profile_image。

在我看来，在REST中，URI应该只指定一个事物，而不是你将用它做什么。如果URI中有一个动词（如更新），那么你很可能做错了。

- Tim

Answer 4

根据REST FAQ的解释，术语“REST”用于涵盖各种东西，包括以RESTful方式结构化的有状态应用程序。因为状态大多由用户通过cookie传递而不是存储在服务器上，所以被认为是RESTful。发明REST的Roy Fielding评论说，只要整个状态都由用户传递，而不是对服务器上状态的引用，它就是RESTful的，因为相同的GET请求将返回相同的结果。Twitter的REST API接近这样做，但并非完全如此。它不严格符合“REST”的原始含义，但接口和一般哲学相似，通常被归入同一范畴。

- Chuck

Answer 5

从技术上讲，它不是RESTful的。首先，它不是无状态的（也就是你提到的幂等性）。

- Zaz

Answer 6

阅读Twitter API后，我了解到RESTful API将在几周内过时。相反，您应该使用OAuth身份验证方法。

- vlad b.