Twitter API *真的* RESTful 吗？ [关闭]

Posted 2023-03-08

【中文标题】Twitter API *真的* RESTful 吗？ [关闭]

【英文标题】：Is the Twitter API *really* RESTful? [closed]

【发布时间】：2011-03-25 09:43:02

【问题描述】：

与半数的 Web 开发人员社区一起，我一直在努力真正地理解 REST 风格。更具体地说，我一直在尝试就纯 RESTful 架构在 Web 浏览器和应用程序服务器之间的实用性提出一些意见。

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

除了具有 RESTful URL 结构之外，我正在努力合理化其中大多数实际上是 RESTful 的。例如，考虑一个对 http://twitter.com/favorites 的简单 GET 请求。

在 REST 的纯实现中，我希望对该 URL 的相同请求，无论发起客户端如何，都会返回相同的响应。但是，在这种特殊情况下，我们显然都会看到不同的响应，具体取决于我们当前经过身份验证的用户，这意味着我们的请求在生成响应之前正在连接到服务器上某种形式的客户端状态。

希望这能为我的问题提供足够的背景——这真的可以称为“REST”吗？我的印象是，90% 的 Web 浏览器和应用程序服务器之间的所谓 RESTful 实现都表现出同样的不一致，其中对存储在服务器上的客户端状态的限制被忽略了。

【问题讨论】：

另见***.com/questions/243388/…

【参考方案1】：

Twitter 几乎打破了所有 REST 约束。您的 http://twitter.com/favorites 基于经过身份验证的用户返回不同结果的示例是 Twitter 违反“资源标识”约束的示例。每个有趣的资源都应该有一个唯一的标识符。我的 Twitter 收藏夹和您的 Twitter 收藏夹是两个不同的资源，因此应该有两个不同的 URI。

这实际上与幂等性完全无关。幂等性是指能够多次发出相同的请求并且具有相同的效果。甚至 Twitter 也尊重幂等性。如果我多次获得我的最爱，我仍然会找回我的最爱。 GET多少次不影响结果。

Twitter 打破 REST 约束的方式还有很多。之前在 SO 上已经介绍了其中许多问题。

更新 在仔细阅读 Twitter api 文档之后，实际上有一种替代的 URI 格式可以正确识别收藏夹资源。 Here 他们展示了如何创建如下 URL：

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

要实现 RESTful 仍有很长的路要走，但至少这是朝着正确方向迈出的一步。

【讨论】：

谢谢 - 这很有意义。我编辑了我原来的问题，以消除对幂等性和有状态的混淆，顺便说一句......

Darrel，我不会说基于经过身份验证的用户返回不同的结果违反了资源标识约束：URI 仅标识描述为 当前经过身份验证的用户的最爱 i>，就像http://twitter.com/home 是我的推特页面，https://www.google.com/history/ 是我的历史而不是你的。链接到它并没有那么有用，因为它本质上对每个人都有不同的含义。

@mogsie 我会再挖掘一些。如果我找到更权威的东西来支持你或我的观点，我会告诉你的。

@DarrelMiller twitter api 现在可以被认为是 RESTful 的吗？自从 2 年前提出这个问题以来，可能 twitter 已经演变为更好的 RESTful ......？

@bhargav，也许您可​​以创建自己的 Web 服务来封装和 REST 化其他服务，例如 Twitter。 Twitter 仍然不平静，因为它们为您提供了一大堆 URI 和 URI 模板，而不是定义媒体类型并提供单个入口点 URI。这甚至没有涉及链接和关系......

【参考方案2】：

在这种情况下，幂等是一个棘手的词。即使您正在检索单个推文，如果该推文是可编辑的并且有人对其进行了编辑，您也会得到不同的结果。当检索一个列表时，我当然希望一条推文能检索到最新的列表。

将幂等性视为做某事而不引起副作用的能力可能会更有帮助。所以 GET 在这个意义上是幂等的，但 POST 不是。

From Wikipedia:

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

还有from Wikipedia:

方法 PUT 和 DELETE 被定义为 是幂等的，意味着多个 相同的请求应该有 与单个请求的效果相同。

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

另见：

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

【讨论】：

PUT 是幂等的。但这并不安全。 Get 是幂等且安全的。你对幂等性的定义其实就是对安全的定义。

这是一个很好的观点......也许幂等性对我来说是错误的。我认为无国籍状态确实是问题的核心。乍一看，感觉它显然不是 RESTful（由于状态问题）......但是像这样的服务被广泛认为是RESTful，我想确保我没有忽略一些理性为此...

@Darrell：我稍微澄清了我的答案，将 PUT 替换为 POST，并添加了额外的支持材料。

实际上，像这样的服务被广泛标记为 RESTful，但是，熟悉 REST 约束的人肯定不会承认它们。

我不确定服务器状态是否是 twitter 真正犯下的罪过。我对 API 的体验是，您可以（至少可以）只使用基本身份验证来访问任何端点。在发出请求之前无需登录并启动会话。

【参考方案3】：

查看documentation，“方法”一词的使用可能很好地表明该 API 是否真正 RESTful。有几个资源实际上可能符合此类条件，例如 friends/<user-id> 或 favourites/<user-id>，但大多数资源实际上只是过程，例如 account/update_profile_image。

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

【参考方案4】：

正如REST FAQ 解释的那样，“REST”一词用于涵盖范围广泛的事物，包括以 RESTful 风格构建的有状态应用程序。因为状态主要由用户在 cookie 中传递，而不是存储在服务器上，所以它被认为是 RESTful。 Roy Fielding（REST 的发明者）commented 表示，只要用户传递整个状态，而不是服务器上的状态引用，它就是 RESTful，因为相同的 GET 请求将返回相同的结果。 Twitter 的 REST API 接近做到这一点，但不是 100%。严格来说，这不是“REST”的原始含义，但接口和一般理念非常相似，因此通常被归为同一个保护伞。

【参考方案5】：

从技术上讲，不，它不是 RESTful。一方面它不是stateless（也就是你提到的幂等）。

【参考方案6】：

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