精通Grails: RESTful Grails

精通Grails: RESTful Grails2011-07-29 IBM Scott Davis本月，我将向您呈现如何让您的 Grails 应用程序成为原始数据 — 具体指 XML — 的源，从而让其他的 Web 应用程序也能够使用它。我通常把这种情况表述为：为您的 Grails 应用程序建立 Web 服务，但最近这个说法被赋予了新的含义。很多人把 Web 服务与 SOAP 及成熟的面向服务架构（service- oriented architecture，SOA）联系到一起。如果选择这种方法的话，Grails 拥有两个插件可以用来将 SOAP 接口公开给应用程序。但我将向您呈现的内容并非处理某一个诸如 SOAP 这样的具体实现，而是如何使用一个基于具象状态传输（Representational State Transfer，REST）的接口来返回普通旧式 XML （Plain Old XML，POX）。

说到 RESTful Web 服务，理解缘由与理解方法同样重要。Roy Fielding 的博士论文— REST 这个缩略词的发源处 — 概括了实现 Web 服务的两大方法：一个是面向服务，另一个是面向资源。在向您呈现实现自己的 RESTful 面向资源架构（resource-oriented architecture，ROA）的代码前，我将先澄清这两个设计原理之间的差异，并论述普遍使用的 REST 的两种最有争议的定义。学习了本文第一部分的所有内容之后，稍后您就可以学习到很多的 Grails 代码。

REST 简介

当开发人员说要提供 RESTful Web 服务时，他们通常是指想要提供一个简单的、无争议的方法来从他们的应用程序中获取 XML。RESTful Web 服务通常提供一个可以响应 HTTP GET 请求而返回 XML 的 URL （稍后我将给出 REST 的更正式的定义，它对这个定义进行了改良，虽然改动不大，但仍然很重要）。

Yahoo！提供了大量的 RESTful Web 服务，它们响应简单的 HTTP GET 请求，而返回 POX。例如，在 Web 浏览器的位置字段键入 http://api.search.yahoo.com/WebSearchService/V1/webSearch？ appid=YahooDemo&query=beatles。您将获得使用 XML 的 Web 搜索结果，它和在 Yahoo！主页的搜索框里键入 beatles 而获得的使用 HTML 的搜寻结果是一样的。

如果假设 Yahoo！支持 SOAP 接口的话（实际上并不支持），那么发出一个 SOAP 请求将会返回相同的数据，但对于开发人员来说，发出请求可能更费劲一些。在查询字符串里，请求方将需要呈交的不是简单的一组名称/值对，而是一份定义明确的、带有一个 SOAP 报头和正文部分的 XML 文档 — 而且要用一个 HTTP POST 而非 GET 来提交请求。所有这些额外的工作完成后，响应会以一个正式 XML 文档的形式返回，它与请求一样，也有一个 SOAP 报头和正文部分，但要获得查询结果，需要去掉这些内容。Web 服务常常作为复杂 SOAP 的一种简单替代品而被采用。

有几种趋势可以表明 Web 服务的 RESTful 方法越来越普及了。Amazon.com 既提供了 RESTful 服务又提供了基于 SOAP 的服务。现实的使用模式表明十个用户中几乎有九个都偏爱 RESTful 接口。另外还有一个值得注意的情况，Google 于 2006 年 12 月正式宣布反对基于 SOAP 的 Web 服务。它的所有数据服务（归类为 Google Data API）都包含了一个更加具有 REST 风格的方法。

面向服务的 Web 服务

如果把 REST 和 SOAP 之间的差异归结为 GET 和 POST 之间的优劣，那就很容易区分了。所使用的 HTTP 方法是很重要的，但重要的原因与您最初预想的不同。要充分了解 REST 和 SOAP 之间的差异，您需要先掌握这两个策略的更深层语义。SOAP 包含了一个 Web 服务的面向对象的方法 — 其中包含的方法（或动词）是您与服务相交互的主要方式。REST 采取面向资源的方法，方法中的对象（或名词）是最重要的部分。

在一个 SOA 中，一个服务调用看起来就像是一个远程过程调用（remote procedure call，RPC）。设想，如果您有一个带有 getForecast（String zipcode）方法的 Java Weather 类的话，就可以轻易地将这个方法公开为一个 Web 服务了。实际上，Yahoo！就有这样一个 Web 服务。在浏览器中输入 http://weather.yahooapis.com/forecastrss？p=94089，这样就会用你自己的 ZIP 代码来替代 p 参数了。Yahoo！服务还支持第二参数 — u —，该参数既接受华氏温度（Fahrenheit）符号 f，又接受摄氏温度（Celsius）符号 c。不难想象，在假想的类上重载方法签名就可以接受第二参数：getForecast （"94089", "f"）。

回过来再看一下我刚才做的 Yahoo！搜索查询，同样，不难想象出，可以将它重写为一个方法调用。 http://api.search.yahoo.com/WebSearchService /V1/webSearch？appid=YahooDemo&query=beatles 轻松转换成了 WebSearchService.webSearch（"YahooDemo", "beatles"）。

所以如果 Yahoo！调用实际上为 RPC 调用的话，那这跟我先前所称的 Yahoo！服务是 RESTful 的岂不是互相矛盾的么？很不幸，就是矛盾的。但犯这种错误的不只我一个。Yahoo！也称这些服务是 RESTful 的，但它也坦言：从最严格的意义上讲这些服务并不符合 RESTful 服务的定义。在 Yahoo！ Web Services FAQ 中寻找 “什么是 REST？”，答案是：“REST 代表 Representational State Transfer。大多数的 Yahoo！ Web Services 都使用 ‘类 REST’ 的 RPC 样式的操作，而非 HTTP GET 或 POST…… ”

这个问题在 REST 社区内一直引发着争论。问题是没有准确的定义可以简单明了地描述这种 “较之 POST 更偏好 HTTP GET 的、较之 XML 请求更偏好简单的 URL 请求的、基于 RPC 的 Web 服务” 。有些人称之为 HTTP/POX 或者 REST/RPC 服务。其他人则对应 High REST Web 服务 — 一种与 Fielding 的面向资源架构的定义更接近的服务 — 而称之为 Low REST Web 服务。

我将类似 Yahoo！的服务称为 GETful 服务。这并不表示我看轻它 — 正相反，我认为 Yahoo！在整理不太正式的（low-ceremony）Web 服务的集合方面做的相当好。这个词恰到好处地概括出了 Yahoo！的 RPC 样式的服务的益处 — 通过发出一个简单的 HTTP GET 请求来获得 XML 结果 —，而且没有滥用 Fielding 所作的原始定义。