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

RESTful Web服务的出现是为了解决SOAP协议在使用HTTP时存在的一些问题。SOAP是一种建立在HTTP之上的协议，它绕过了许多HTTP的约定，以SOAP的方式建立了新的约定。然而，HTTP本身已经足够用于通过HTTP进行信息的检索、搜索、编写和删除等操作，而这也正是RESTful Web服务所做的。RESTful Web服务是基于HTTP构建的，而不是在HTTP之上构建的，这意味着与之集成的软件（如Web浏览器）不需要理解SOAP，只需要理解HTTP就可以了。而HTTP作为目前最广泛理解和集成的协议，这一点无疑是非常重要的。

SOAP协议早在1998年就被定义出来了。那时候有多少HTTP的“约定”已经成为约定了呢？根据w3.org/Protocols/HTTP/1.0/spec.html的数据显示，HTTP从1990年开始就已经被使用了。但是这又怎样呢？我们都知道SOAP选择使用HTTP是因为80端口在防火墙上最有可能被打开。微软不会再犯DCOM的错误了。

“REST是基于HTTP而不是在HTTP之上构建的”这个观点很有道理。这整个讨论对我来说真的很有帮助，让我理解了为什么要选择REST而不是SOAP，反之亦然。

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

RESTful Web服务的出现是为了解决在分布式应用程序中，客户端和服务器组件之间的耦合问题。如果服务器将被许多不受控制的不同客户端使用，或者如果您希望能够定期更新服务器而不需要更新客户端软件，那么这种耦合的减少就非常重要。

但是，要实现这种低耦合水平并不容易。需要遵循REST的所有约束才能成功。保持纯粹无状态的连接是困难的。选择合适的媒体类型并将数据压缩到格式中是棘手的。创建自己的媒体类型甚至更难。

将丰富的服务器行为适应统一的HTTP接口可能会令人困惑，并且有时与相对简单的RPC方法相比显得教条主义。

尽管存在困难，但好处是由于对HTTP协议的一致使用，客户端开发人员应该能够轻松理解服务。由于超媒体的使用，服务应该容易发现，并且客户端应该对服务器的更改非常具有韧性。

超媒体的好处以及避免会话状态使负载均衡变得简单且可行。严格遵守HTTP规则使得调试器和缓存代理等工具的可用性变得非常方便。

REST已经成为一种流行趋势，因为尝试进行SOA类型项目的人们发现使用SOAP堆栈无法实现之前承诺的好处。人们不断回到Web作为简单集成方法的例子。不幸的是，我认为人们低估了创建Web所需的计划和远见，并且他们过于简化了实现Web上那种偶然复用所需的工作。

如果您使用过Web浏览器，那么您就已经看到了REST的实际应用。Web浏览器就是一个REST客户端。

为什么当网站上的HTML发生更改时，您不需要更新浏览器？为什么我可以添加全新的页面集到一个网站上，而“客户端”仍然可以访问这些新页面而不需要更新？为什么我不需要为Web浏览器提供“服务描述语言”，告诉它当它访问http://example.org/images/cat时返回类型将是JPEG图像，当您访问http://example.org/description/cat时返回类型将是text/html？为什么我可以使用Web浏览器访问在浏览器发布之前不存在的网站？客户端如何知道这些网站的存在？

这些问题可能听起来很愚蠢，但如果您知道答案，那么您就可以开始了解REST的含义。

StackOverflow是REST的另一个很好的例子。当我浏览问题时，我可以将该页面添加到书签中，或将URL发送给朋友，他可以看到相同的信息。他不需要浏览整个网站来找到那个问题。

StackOverflow使用各种OpenID服务进行身份验证，使用gravatar.com提供头像图像，使用google-analytics和Quantserve提供分析信息。这种多公司集成是SOAP世界所梦寐以求的。最好的例子之一是，用于驱动StackOverflow UI的jQuery库是从Google的内容交付网络中获取的。SO可以指示客户端（即您的Web浏览器）从第三方网站下载代码以提高性能，这证明了Web客户端和服务器之间的低耦合性。

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

现在一些网站/应用程序违反了REST的规则，因此浏览器无法按预期工作。

臭名昭著的“后退按钮问题”是由使用服务器端的会话状态引起的。当使用服务器端的会话状态时，负载均衡可能变得麻烦。Flash应用程序通常会阻止URL明确标识表示。糟糕的符合媒体类型标准也会破坏Web浏览器的工作。我们总是听说IE6需要被淘汰。问题在于没有正确遵循标准，或者出于某种原因被忽视。登录会话的使用是许多安全漏洞的根源。

REST无处不在。它是使Web运行良好的一部分。如果您想构建能够像Web一样扩展的分布式应用程序，具有像Web一样的变化韧性，并且能够像Web一样促进重用，那么请遵循构建Web浏览器时遵循的相同规则。

SOAP如何增加耦合性而REST如何减少耦合性？您是否指的是SOAP客户端实际上需要理解SOAP，而REST客户端只需要理解媒体类型？

在使用SOAP的方式中，客户端需要“编译”每个服务器端终点、每个参数数据类型和每个返回类型的知识。在SOAP世界中，没有指导要尝试使用标准化类型在客户端和服务器之间传递数据。这意味着每个客户端开发人员要使用的新服务都有其自己独特的类型、终点和交互协议。这就是耦合。

REST试图将交互协议标准化为HTTP动词的语义，将数据格式标准化为IANA注册的类型，并且所有终点都应该是动态可发现的。这意味着客户端/服务器耦合仅局限于媒体类型的定义。正如Rich所说，“您的服务将耦合的范围限制在一个事物上 - 媒体类型”。

在WSDL术语中，让我定义一下我所说的耦合意味着什么。想象一下，您可以在服务契约中添加、删除和重命名方法，而无需重新编译客户端。考虑到客户端可以被指导使用这些新方法而无需重新编译。消息契约由HTTP固定，但通过消息契约中的元数据是可扩展的，服务器可以向客户端动态交付适当版本的数据契约。

对于定义员工的媒体类型，可以使用IANA媒体类型注册表的vnd子树。另一种方法是使用类似FOAF（en.wikipedia.org/wiki/FOAF_(software)）的东西。这取决于“可达性”对您来说有多重要。返回application/xml并让客户端挖掘并提取“/Employee/”是要避免的耦合。

如果您不需要松散耦合，那么REST只是徒劳无功的工作。这就是为什么我认为在Web服务器到应用程序服务器集成中使用REST没有意义。如果您控制两者，并且它们部署在同一个房间，那意义何在？在WCF世界中事情有所改善，我认为DataContractSerializer相对于XmlSerializer的主要优势是它是一个选择加入模型，而不是选择退出。这使得数据契约比以前更加灵活。在ASMX世界中，如果您对服务契约进行更改，它将使客户端代理类无效。

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

RESTful Web服务是一种轻量级、可读性强、易于构建的Web服务架构。它不需要额外的XML标记，返回结果易于阅读，无需使用工具包即可构建。

然而，并非每个Web服务都适合使用REST。对于需要保密的数据，不应该将其作为参数发送到URI中。大量数据，例如详细的采购订单，也可能会在URI中变得笨重甚至超出限制。在这些情况下，SOAP是一个可靠的解决方案。但是，在必要时首先尝试REST，只有在必要时才转向SOAP，这有助于保持应用程序开发的简单性和可访问性。

有人认为REST的一个缺点是缺乏像SOAP服务的标准化“描述”语言。每个REST服务可能或可能没有文档化，并且文档质量因服务而异。然而，如果REST被正确实现，就不需要像WSDL这样的“描述语言”。媒体类型需要进行文档化，但不应该存在将终端点与媒体类型耦合的文档。

有些人喜欢将内容反序列化为编程语言中的对象。在这种情况下，拥有一个机器可读的定义来描述服务可以发送和接收的内容是非常有用的，这样您的工具可以创建相应的类和序列化代码。

尽管如此，REST并不依赖于像WSDL这样的描述语言。WSDL将终端点与数据类型绑定在一起，如果这样做，将会丧失超媒体的优势。如果您当前还没有意识到超媒体的好处，那么我的观点可能无法令您信服。然而，这也是为什么Roy一直在反对人们选择并忽略REST的其他部分的愿望。没有超媒体，使用描述语言就是合理的。但是，没有超媒体，就不是REST。

总之，RESTful Web服务是一种轻量级、易于构建且易于阅读的Web服务架构。虽然它可能不适用于所有Web服务，但在大多数情况下，REST是一个简单而可靠的解决方案。