web-services - 为什么我们需要 RESTful Web 服务？

Question

我将学习 RESTful Web 服务(最好说我必须这样做，因为它是 CS 硕士学位类(class)的一部分)。

我在 Wikipedia 上阅读了一些信息，我还在 Sun Developer Network 上阅读了一篇关于 REST 的文章，我发现这不是一项简单的技术，有用于构建 RESTful 应用程序的特殊框架，并且经常将其与 SOAP Web 服务进行比较，程序员应该了解何时使用 SOAP 以及何时 REST 可能是不错的方法。

我记得几年前 SOAP 非常流行(时尚？)，并且每个好的简历中都必须出现“SOAP”项目。但在实践中，它很少使用，并且用于实现非常简单的目的。

在我看来，REST 是另一个“时尚的最后一句话”(或者我可能完全错了，因为我从未在实践中见过 REST)。

你能给我举一些例子，说明应该使用 REST，为什么我们不能在没有 REST 的情况下做同样的事情(或者为什么我们应该花更多的时间在没有 REST 的情况下做同样的事情)？

UPD :不幸的是，我在第一条评论中看不到任何可以让我大吃一惊的具体论点。让我觉得 REST 是很棒的技术!

我想看到这样的答案:

I was developing another complex HelloWorld application and we need to transfer lots of / tiny data and I proposed REST solution to my workmate:

– Oh, damn! Jonny, we should certainly use REST for implementing this app!
– Yes, Billy, we can use REST, but we would better use SOAP. Trust me 'cause I know something about developing HelloWorld applications.
– But SOAP is old-fashioned technology from the last century and we can use better one.
– Billy, are you ready to spent 3 days for experimenting with REST? We can do this with SOAP in 2 hours..
– Yes, I'm sure that we'll spent even more time to achieve the same security/performance/ /scalability/whatever else with SOAP. I'm sure that HelloWorld applications should be developed only with REST from now.

Answer 1

如果您对 非常重要，则应使用 REST。最小化耦合在分布式应用程序中的客户端和服务器组件之间。

如果您的服务器将被 使用，可能就是这种情况。许多不同的客户 您无法控制。如果您希望能够，也可能是这种情况。定期更新服务器 无需更新客户端软件。

我可以向您保证，实现这种低耦合水平是 不容易做 .遵循 REST 的所有约束以取得成功至关重要。维护纯粹的无状态连接是困难的。选择正确的媒体类型并将数据压缩到格式中是很棘手的。创建自己的媒体类型可能更难。

与相对简单的 RPC 方法相比，将丰富的服务器行为适应统一的 HTTP 接口(interface)可能会令人困惑，有时显得迂腐。

尽管存在困难，但好处是您拥有一项服务，由于一致使用 HTTP 协议(protocol)，因此客户端开发人员应该能够轻松理解该服务。服务应该是由于超媒体而易于发现 和客户应该非常适应服务器上的变化 .

超媒体的好处和避免 session 状态使负载平衡变得简单和服务分区可行 .对 HTTP 规则的严格遵守使得调试器和缓存代理等工具的可用性变得非常棒。

更新

It seems to me that REST is another 'last word of fashion' (or I can be totally wrong because I haven't ever seen REST in practice).

我认为 REST 已经变得流行，因为尝试进行 SOA 类型项目的人们发现使用 SOAP 堆栈他们没有意识到所 promise 的好处。人们不断将网络作为简单集成方法的一个例子。不幸的是，我认为人们低估了创建 Web 的计划和远见，他们过度简化了需要做的事情，以允许在 Web 上发生的那种偶然的重用。

您说您在实践中从未见过 REST，但如果您曾经使用过 Web 浏览器，那这不可能是真的。 Web 浏览器是 REST 客户端。

为什么不需要做浏览器
当有人更改某些 html 时更新
在网站上？

为什么我可以添加一套完整的新
页面到网站和“客户端”
仍然可以访问那些新页面
没有更新？

为什么我不需要提供
“服务描述语言”到
网络浏览器告诉它什么时候去
至 http://example.org/images/cat那
返回类型将是 jpeg 图像
当你去
http://example.org/description/cat
返回类型将是 text/html？

为什么我可以使用网络浏览器访问
不存在的网站
浏览器发布了？怎么可能
客户知道这些网站吗？

这些问题听起来可能很愚蠢，但是如果您知道答案，那么您就可以开始了解 REST 的全部内容了。
查看 StackOverflow 以了解 REST 的更多好处。当我在看问题时，我可以将该页面加入书签或 将网址发送给 friend 他可以看到相同的信息。他无需浏览网站即可找到该问题。

StackOverflow 使用各种 OpenId 服务进行身份验证，gravatar.com 用于头像图像，google-analytics 和 Quantserve 用于分析信息。这种多公司整合是 的类型。 SOAP 世界唯一的梦想 .最好的例子之一是用于驱动 StackOverflow UI 的 jQuery 库是从 Google 的内容交付网络检索的。 SO 可以指示客户端(即您的 Web 浏览器)从第三方站点下载代码以提高性能这一事实证明了 Web 客户端和服务器之间的低耦合。

这些是工作中的 REST 架构的示例。

现在有些网站/应用做打破 REST 规则 然后浏览器无法按预期工作。

臭名昭著的返回按钮问题
是由使用服务器端引起的
session 状态。

负载平衡可能会成为一种痛苦
你有服务器端 session 状态。

Flash 应用程序通常会阻止
URL 来自专门标识一个
表示。

另一个破坏网络的问题
浏览器不符合
媒体类型标准。我们听到所有
关于 IE6 需要怎样的时间
被杀。问题是
没有正确遵守标准，
或因任何原因被忽略。

登录 session 的使用是
许多安全漏洞的来源。

REST 无处不在。它是网络的一部分，使其运行良好。如果您想构建可以像 Web 一样扩展的分布式应用程序，像 Web 一样适应变化并像 Web 那样促进重用，那么请遵循他们在构建 Web 浏览器时所做的相同规则。