作者 Stefan Tilkov译者 徐涵  发布于 2008年5月22日 下午8时13分

在了解过REST之后，你肯定很想知道这个概念在你的实际应用当中究竟能派上多大用场。而且，假如你已经熟悉另一套完全不同的架构手法的话，那么你担心“[URL=http://www.infoq.com/cn/articles/rest-introduction]REST[/URL]或REST式HTTP（RESTful HTTP），是否真的能在实践中派上用场，还是在介绍性的、‘Hello, World’级场景以外就不灵光了”是很正常的。我将在本文解答人们——尤其是那些深谙基于SOAP/WSDL的Web服务架构手法的人——开始研究REST时容易产生的关于REST的十点疑惑。

1. REST也许适用于CRUD，但并不适用于“真实的”业务逻辑
这是那些对REST的好处持怀疑态度的人最常见的反应。毕竟，要是你只能create/read/update/delete，那你如何表达更复杂的应用语义呢？我已经在本系列[URL=http://www.infoq.com/cn/articles/rest-introduction]介绍性的文章[/URL]中探讨过这些被大家所关心的问题了，不过这方面绝对值得进一步讨论。

首先，HTTP动词（verbs）——GET、PUT、POST和DELETE——跟数据库的CRUD操作并不是一一对应的。例如，POST和 PUT都可用于创建新资源，它们的区别在于：PUT请求是由客户端决定（被创建或更新的）资源的URI；而POST请求是向一个“集合（collection）”或 “工厂（factory）”资源发出的，是由服务器来指派URI的。不过无论怎样，我们回到那个问题：如何应付更复杂的业务逻辑呢？

任何返回一个结果 c 的计算 calc(a, b)，都可被转换为一个标识其结果的URI——例如 x = calc(2,3) 可被转换为http://example.com/calculation?a=2&b=3。初看，这仿佛是完全错误的REST式HTTP的用法——我们应当用URIs来标识资源（resources）而不是操作（operations），不是吗？没错，其实你就是这么做的：http://example.com/sum?augend=2&addend=3 标识的是一个资源，即2加3的结果。在这一特定的（显然是精心设计的）示例中，用GET来获取计算结果可能是个好主意——毕竟它是可缓存的（cacheable），你可以引用它，而且该计算多半是安全的（safe）且代价很小的。

当然，在许多（即便称不上大多数）情况下，用GET来执行计算也许是会犯错的。别忘了，GET应当是一个“安全的（safe）”操作，也就是说，假如客户端只是通过发出GET请求来跟随一个链接，那么它不承担任何义务（比如因使用你的服务而向你付费）或责任。所以，在许多其他情况下，“通过POST 请求向服务器提供输入数据、以便服务器新建一个资源”是更合适的做法。服务器在响应该POST请求时，可以给出结果的URI （而且有可能发起一个重定向把你转向过去）。这个结果接下来便可被重用、被加入书签、在获取时被缓存等等。你基本上可以将这一模型推广应用到任何产生结果的操作——这涵盖几乎你所能想到的所有操作。

2. 没有正式的契约与描述语言
从RPC到CORBA，从DCOM到Web服务，我们已习惯于拥有一个“列出操作、名称及输入输出参数类型”的接口描述（interface description）了。没有接口描述语言的话，REST怎么用呢？

就这一被十分频繁问到的问题，有三点答复。

首先，假如你决定用XML（这是很普遍的做法）来配合REST式HTTP的话，那么各种现有的XML模式语言（schema languages）（如DTD、XML Schema、[URL=http://relaxng.org/]RELAX NG[/URL]、[URL=http://www.schematron.com/]Schematron[/URL]等）仍旧可供你使用。可以说，一个用WSDL描述的东西，常常有95%的内容并不是跟WSDL相关、而是跟你定义的XML Schema复杂类型（complex types）相关的。WSDL所增加的，大部分是有关操作（operations）及其名称的——对于REST的统一接口（uniform interface）来说，描述这些是颇为无趣的，因为GET、PUT、POST和DELETE就是你所能使用的全部操作了。关于XML Schema的使用，这意味着，即便你依赖于一个REST式接口，你仍旧可使用你所偏爱的数据绑定工具（假如刚好你有的话）来为你偏爱的语言生成数据绑定代码。（回答还没结束，见下。）

第二，问问你自己需要描述做什么。最常见（尽管并非唯一）的用例（use case）是：描述被用来给接口生成桩（stubs）和骨架（skeletons）代码。它通常不是文档（documentation），因为WSDL格式的描述并不是告诉你操作的语义——它只是告诉你操作的名称。你得通过一些人类可读的文档来了解如何调用它。典型的REST做法是，你应提供HTML格式的文档，其中可能包含指向你的资源的直接链接（direct links）。如果你采取提供多个表示（multiple representations）的做法的话，那么你可以真正拥有自文档化的（self-documenting）资源——你只要在浏览器中对一个资源做 HTTP GET请求，就可以得到一个HTML文档，其中不但包含数据，还包含你可以对它执行的操作（HTTP动词）的列表以及它接受和返回的内容类型（content types）。

最后，假如你坚持为你的REST式服务（RESTful service）使用描述语言，那么你可以使用WADL（Web Application Description Language，Web应用描述语言），或适当地使用[URL=http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/]WSDL 2.0[/URL]（其制定者声称它也可以描述REST式服务）。不过，WADL和WSDL 2在描述超媒体（hypermedia）方面均无帮助——而且考虑到这是REST的核心方面之一，我不太确信它们是否充分有用。

3. 谁真会把他们应用中如此多的实现细节暴露出来？
另一个普遍关心的问题是，资源太低层（low-level），暴露了那些不应暴露出来的实现细节。说到底，这不就把“按有意义的方式来运用资源”的担子加到客户端（消费者）的身上了吗？

简单的回答是：不。一个资源的GET、PUT或其他方法的实现，可以跟一个“服务”或RPC操作的实现复杂程度相当。应用REST设计原则，并不是说你必须把下层数据模型（underlying data model）中的各项暴露出来——它只意味着，你采用以数据为中心的（data-centric）方式、而不是以操作为中心的（operation- centric）方式把业务逻辑暴露出来。

一个相关的关切是，不支持对资源的直接访问将增加安全性。这是由“通过隐匿得到安全（security by obscurity）”这条陈旧的谬论得出的结论。人们可以这样反驳：其实恰恰相反，如果你隐瞒你通过特定于应用的协议访问哪些资源，你将无法利用基础设施（infrastructure）来保护它们。通过为有意义的资源指派单独的URI，你可以利用Apache的安全规则（以及重写逻辑、日志和统计等）对不同资源采取不同处理。把这些明确化了，你的安全性将得到提升，而不是降低。

全文请看InfoQ中文站： http://www.infoq.com/cn/articles/tilkov-rest-doubts