rest - Twitter API *真的*是 RESTful 吗？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

4年前关闭。




Improve this question




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

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

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

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

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

Answer 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 还有很长的路要走，但至少这是朝着正确方向迈出的一步。