先对如下两个名词做一些解释：
WADL：Web Application Description Language
WSDL 2.0：Web Services Description Language

以下翻译取自该文最关键的部分，即两者之间的不同点：

尽管 WADL 和 WSDL 2.0 HTTP binding 在某种程度上非常类似，但它们还是有一些不同点。

Resources vs. Interfaces

WADL 是以资源为中心的描述语言。WADL 文档是由一组资源描述组成。与之相反，WSDL 是以接口为中心的描述语言。.
WSDL 2.0 描述是由一组接口定义构成，这些接口定义则是由操作定义构成。
在 WADL 里，甚至即使是一个复杂的商业应用也被描述为对资源的基本操作。

仅支持 HTTP  vs. 独立于传输协议

WADL 只支持对使用 HTTP 协议的 web 应用进行描述。
因为限定于 HTTP，WADL 要比 WSDL 2.0 更简单，后者设计目标是具有能够使用任何协议来描述服务接口的能力。

消息交换模型(模式)

一些人认为 HTTP 所隐含的唯一消息交换模式只是 request-response (in-out)。尽管事实上 HTTP 天生是 request-response，但它也能用于 one-way 和 solicit-response 消息交换模式。注意，HTTP GET verb 本质上就是 solicit-response，在这个意义上 GET 请求消息只包含资源标识符，用于接收资源表述。HTTP PUT 和 DELETE 事实上就是 one-way 操作，该操作的响应包含的是一个简单的状态消息(200 OK, 404 Not Found, etc.).   WSDL 2.0 定义了很多消息交换模式，例如 one-way (in-only) 和通知 (out-only)，还有 request-response。尽管 WSDL 2.0 规范没有指定这样的绑定，但一些传输协议，如 SMTP 和 Message Queuing，本身就支持 one-way 和 notification。期待这些绑定规范将 WSDL 定义的消息交换模式映射到这些协议上。WSDL 2.0 规范的 HTTP 绑定扩展章节详细描述了如何利用 HTTP (状态码为 202 Accepted) 响应消息实现一个 one-way 消息交换模式。同时，基于 HTTP 的通知消息交换模式或许会使用类 comet 技术来实现。  不像 WSDL 2.0 那样谋求传输中立，WADL 只用于描述 HTTP-based web applications。因此，它的消息交换模式 (尽管 WADL 不会定义或使用这样的术语) 会更容易得到 HTTP 的支持。

无状态 vs. 有状态

尽管 REST 架构风格要求是无状态的，仍有人对术语“无状态”(stateless)是什么意思感到迷惑。

REST 环境中的资源，它的内部和它本身并不是无状态的。REST 的无状态与 URI 标识的资源之间的交互使用的协议有关。这意味着所有对满足一个请求所必需的信息都要在请求消息中携带。

资源本身(经常) 天生就是有状态的。一个银行账户余额资源显然是有状态的。我们可以给这个资源指定一个 URI。对该资源 URI 执行 HTTP GET 会随着时间的推移返回不同值，反映出因账户余额增加和减少导致的该资源的状态变化。
然而，如果 GET 是真正无状态的 (e.g. 不滥用 cookie)，那么任何用户对该资源 URI 进行任何 HTTP get 操作，都总是返回该资源且只是该资源的一个表述。协议交互的无状态使得 REST 架构风格的缓存特性可用。缓存代理可以介于客户端和服务器之间，缓存 HTTP GET 的响应，随后将这个资源的缓存版本作为响应返回给其它 HTTP GET，只要初始服务器已经在初始响应消息里指定了恰当的 cache pragmas，指明何时缓存应当失效，等等。
从 RESTful 角度来看，HTTP 协议有一方面容易被滥用，因而违反了 REST 架构风格中的无状态约束：HTTP cookies. Roy Fielding，REST 论文作者，曾称 HTTP cookies 应该废弃，他说过如果让他再次设计，他不会把它们引入到 HTTP 协议中。尽管 cookies 可以按 RESTful 方式使用，但它们经常被滥用(从 REST 观点) 作关联会话状态(没有这种会话状态交互变得无意义)的一个途径。
举个例子，如果一个 cookie 被用来与某些会话状态相关联，如用户的邮编(随后会用于定义对天气服务的搜索)，当使用不同邮编的其他人使用 HTTP GET 访问该资源 URI，URI 必然不会标识相同的资源 (用户邮编区域的当前天气)。在这种情形下，RESTful 对 cookie 的用法可能是用于追踪用户的交互，而使用 cookie 将请求与一些预先建立的会话状态进行关联显然是非 RESTful 的。
尽管 WADL 规范不要求 web 应用 (或与 WADL 所描述的资源的交互) 无状态，规范也没有提供任何 HTTP 的状态特性，例如 cookies。与之相反，WSDL 2.0 HTTP binding 特别提供了对 HTTP cookies 的用法和描述(See, WSDL 2.0 Part 2 Section 6.10).

认证

典型情况下, HTTP 认证会被自动处理，因为 HTTP 协议提供了当服务器在客户端没有为请求提供所要求 credentials 时而返回的标准的状态响应。客户端可以利用这些状态响应(e.g. 401 Unauthorized)触发对 credentials 的收集。
WSDL 2.0 支持 HTTP 认证，而 WADL 不支持。

URL 编码数据

许多 web 应用程序利用 URL 编码数据 (media type: “application/xwww-form-urlencoded”) 作为对资源基于参数化标准构建 URI 的途径，例如从一个 web form 中收集到的信息。
当前，尽管有许多用于定义一个 URI 模板语言的提案，但其中存在一些用于描述 URL 编码数据的不标准语言。

URI template

WADL 和 WSDL 2.0 HTTP binding 使用 URI 模板形式指定查询字符串参数。WADL 引用一个名叫 “URI template” 的草案（该草案作者同时也是 WADL 作者）。与之相反，WSDL 2.0 在 WSDL 2.0 HTTP binding 扩展规范中独自定义了一个 URI 模板。

Percent encoding in URL encoded data

WADL 没有提及 URL 编码数据的字符编码。WSDL 2.0 HTTP binding 明确说明怎样处理非 ASCII 字符。

用于描述消息内容的模式语言

WADL 和 WSDL 都提供了一种途径，通过这种途径，可以使用 schema 语言来描述要交换消息的内容。

WADL 更提供了包含 W3C XML Schema 和 RelaxNG [18] schema 文档的能力。

WSDL 2.0 只说明在描述中如何包含 W3C XML Schema 文档。

结论

每种规范都有其优缺点。WADL 简单，适用范围有限。WADL 局限于描述 HTTP 应用，不解决诸如安全等特性。与之相对，WSDL HTTP Binding 特性丰富，但复杂性随之增加，且仍缺乏对真正的以资源为中心的模型支持。

Related Posts:

• 2009/07/19 -- SMTP Transport Binding for SOAP
• 2009/07/07 -- Which style of WSDL should I use? (reship)
• 2009/04/20 -- 软件及服务的松耦合
• 2008/07/29 -- What’s New in WSDL 2.0
• 2008/07/25 -- SOAP 规范中的 encodingStyle 和 WSDL 中的 binding style 究竟是什么意思

1. 模块可分解性（Modular Decomposability）——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解，那么该方法就满足模块可分解性。
2. 模块可组合性（Modular Composability）——如果一种方法，由它生产出的软件元素，未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统，那么该方法就满足模块可组合性。
3. 模块可理解性（Modular Understandability）——如果一种方法，由它生产出的软件，人类读者无需了解其他模块（或最多只需研究少许其他模块）便可理解每一个模块，那么该方法就有利于模块可理解性。
4. 模块连续性（Modular Continuity）——如果一种方法，在由它得到的软件架构中，功能规格上的微小改动只会引起一个（或少量）模块的变化，那么该方法就满足模块连续性。
5. 模块保护性（Modular Protection）——如果一种方法，在由它得到的架构中，一个模块在运行时出现异常条件不会影响到该模块之外（或最多只蔓延到少数周边模块），那么该方法就满足模块保护性。

服务的模块性:

1. 可分解性（Decomposability）——如果一种方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解，那么该方法就满足可分解性。
2. 可组合性（Composability）——如果一种方法，由它生产出的软件元素，未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统，那么该方法就满足可组合性。
3. 可理解性（Understandability）——如果一种方法，由它生产出的软件，人类读者无需了解其他模块（或最多只需研究少许其他模块）便可理解每一个模块，那么该方法就有利于可理解性。
4. 连续性（Continuity）——如果一种方法，在由它得到的软件架构中，功能规格上的微小改动只会引起一个（或少量）模块的变化，那么该方法就满足连续性。
5. 保护性（Protection）——如果一种方法，在由它得到的架构中，一个模块在运行时出现异常条件不会影响到该模块之外（或最多只蔓延到少数周边模块），那么该方法就满足保护性。
6. 自查性（Introspection）——如果一个方法，由它得到的架构提供了“允许在运行时查询并检查模块结构及模块间通信结构”的机制，那么该方法就满足自查性。
7. 远程性（Remoteability）——如果一个方法，由它得到的架构提供了“允许托管于不同物理环境下的不同模块与之进行模块通信”的机制，那么该方法就满足远程性。
8. 异步性（Asynchronicity）——如果一个方法，由它得到的架构不假定模块调用将被立即响应，那么该方法就满足异步性。换言之，它假定网络或被调用模块有延迟。
9. 面向文档（Document Orientedness）——如果一个方法，在由它得到的架构中，内部模块间的通信消息均是明确定义且互相知道的、而且各次调用之间不存在隐式的状态共享，那么该方法就是面向文档的。
10. 标准化的协议信封（Standardized Protocol Envelope）——如果一个方法，由它得到的架构要求所有模块通信都共用一种通用信封消息格式，那么该方法就满足标准协议信封。
11. 分散式管理（Decentralized Administration）——如果一个方法，由它得到的架构不需要对所有模块进行集中管理，那么该方法就符合分散式管理。

原文:

1. SOA定义的松耦合
2. Loose Coupling in SOA Defined

Related Posts:

• 2010/02/01 -- Differences between WADL and WSDL 2.0 HTTP binding
• 2009/10/21 -- Tutorial of SOAP with Attachments API for Java
• 2009/10/15 -- Structures of SOAP with Attachments
• 2009/09/25 -- 一个简单的 POJO factory 实现
• 2009/07/19 -- SMTP Transport Binding for SOAP