在本文中，我们打算展示一下如何使用简单的技术加上以文档为中心的方式 带来有价值的业务服务，而无须使用专有的中间件，也不必引入Web服务栈的复 杂性。我们的灵感来自于REST的架构风格，以及把XML移到HTTP协议之上的能力 。
Web服务的方式
介绍我们这个方式的最好办法就是将它和一个简单的Web服务例子相对比。假 设有一个简单的天气服务，暴露出一个名为“WeatherQuery”的Web方法，这个 方法返回一个对象，包含温度和气压值。在通常情况下，人们拿现成代码，使用 工具来暴露方法，并生成WSDL。
如果你相信这个骗局，那么要做的无非就是找到一个WSDL在Java下的等价工 具，然后生成存根（Stub）代码。
不巧的是，事情并没有那么简单，WSDL是一个概括性的标准，而且实际上范 围到可以让人自由诠释。在我们的例子里，我们发现.NET强制使用基于文档的方 法，而Java工具则采用了相反的RPC方法。此外，我们还发现以下方面存在问题 ：命名空间混淆，Schema的包含，以及工具将WSDL切分成若干独立部分。简而言 之，这项技术已经开始把注意力放在我们试图解决的实际问题之外了。
除了这些问题，我们还发现Web服务的工具之间存在不一致性。例如，对于自 动发布的WSDL文档，不同版本的Internet Information Server和Web Services Enhancements之间，还有它们的Java等价产品，彼此之间只能部分兼容。
有些东西今天七拼八凑起来可以工作，但到了明天，如果服务的后续版本需 要更复杂的Web方法时就得抛锚。这些东西真是令我们倍感厌烦。
更RESTful的风格
上面的方法里存在两个关键性假设：首先，仅暴露一个已有方法调用就足以 给我们带来一个有意义的服务；其次，使用工具能使通过Web服务访问到这个服 务的工作变成小菜一碟。
我们可以把请求看做一个包含请求的类型还有相应参数的文档，而不是考虑 请求的参数和返回的类型。把这个文档当成对试图建模的业务过程中契约的一部 分的描述。如果我们以相同的WeatherQuery方法为例，用常见的XML来描述它， 那么就可以得到类似下面的东西——