AJAX 应用程序体系结构(第2部分)(2)

服务的风格

在 AJAX 中，服务表示驻留在应用程序域并向客户端脚本代码公开功能的一段代码。AJAX 中使用的服务需要进行某种设计，以便实现对实际应用程序后端和中间层的保护，避免其与最终用户直接交互。此类服务是 WS-* Web 服务吗？它可以是面向服务的体系结构 (SOA) 服务吗？

最适合 AJAX 应用程序的服务主要涉及向 Web 客户端公开数据和资源。它可以通过 HTTP 获得，并要求客户端使用 URL（也可以是 HTTP 头）访问数据和命令操作。客户端与服务进行交互使用的是 HTTP 动词，如 GET、POST、PUT 和 DELETE。换句话说，URL 代表一个资源，而 HTTP 动词描述了您想对资源采取的操作。在这些交互中交换的数据以简单格式表示，如 JSON 和纯 XML，也可以整合格式表示，如 RSS 和 ATOM。

具有这些特征的服务是 Representational State Transfer (REST) 服务。有关 REST 定义的详细信息，请阅读描述 REST 前景的原作（在 ics.uci.edu/~fielding/pubs/dissertation/top.htm 中提供）。

最后，AJAX 应用程序所使用的服务并不倾向于使用 SOAP 进行通信，而且不一定是 SOA 意义上的自治服务。相反，它们与承载自身的平台和域相绑定。基于这一点，它们几乎不能称为 WS-* Web 服务或 SOA 服务。

此外，这些服务是不使用公共文档资料或发现架构的范例，这一点与 WS-* Web 服务的 Web 服务描述语言 (WSDL) 这类事物不同。这会减少依附于服务的依赖关系的数量，并使服务代码更加迅速地演变。总而言之，为 AJAX 服务推荐的模式不像 Web 和 SOA 服务背后的模式那样雄心勃勃，但对于将要使用它的环境来说，它依然十分有效。

注意，在本专栏的其余部分，我将使用“AJAX 服务”的说法表示通过脚本服务方法实现 AJAX 应用程序后端的服务。

AJAX 服务返回什么？

既然公开 AJAX 服务的唯一方式是通过 HTTP，那么就几乎可以使用任何文本格式来包装请求和响应的主体。JavaScript Object Notation (JSON) 是最常用的格式，但也可使用其他格式，如纯 XML 和原始文本。

JSON 是基于文本的格式，用于跨应用程序的各层移动对象的状态。JSON 字符串通过常见的 eval 函数便可方便地赋给 JavaScript 对象。JSON 格式描述了对象，如下所示：
{"ID":"ALFKI", "Company":"Alfred Futterkiste"}

该字符串表示一个对象有两个属性，即 ID 和 Company，以及它们各自的文本序列化值。如果对某个属性赋予非基本类型的值（比如自定义对象），那么该值将递归地序列化为 JSON，如下所示：

"ID":"ALFKI", 
"Company":"Alfreds Futterkiste",
"Location":
"{"City":"Berlin", "Country":"Germany"}",
}

JSON 与 XML 之比较

多年以来，XML 已被推崇为 Web 通用语言。我们知道，现在 AJAX 正在改变着 Web，就数据表示而言，JSON 更受欢迎，而 XML 正在被推向角落。

JSON 稍微简单些，更适合与 JavaScript 语言配合使用。您可能会争辩哪一个更容易为人们所理解，不过，Web 浏览器处理 JSON 肯定比处理 XML 更容易。使用 JSON 时，您不需要 XML 分析器之类的任何东西。为分析文本所需的一切都已经完全构建在 JavaScript 语言中了。因为 JSON 不像 XML 那样雄心勃勃，它也不那么冗长繁杂。这并不是说 JSON 就很完美；JSON 需要大量的逗号和引号，这使它的格式显得十分怪异。

凭借 JSON，您还能以相对较低的成本在体系结构方面嬴得关键优势。您按照对象无处不在的思路进行推理。在服务器上可定义一些实体，并用您最喜爱的托管语言将它们实现为类。当某个服务方法需要返回任何类的一个实例时，该对象的状态被序列化为 JSON 并通过线路传送。客户端接收并处理 JSON 字符串，并将其内容载入一个数组或一种与服务器类有相同接口的镜像 JavaScript 对象。类的接口是从 JSON 流推断出来的。这样，服务和客户端页面的代码便使用一个实体的同一逻辑定义。

单纯从技术角度来说，AJAX 服务并不严格要求 JSON 实现为数据表示格式。使用 XML 也可实现同样的结果，但随后就需要可从 JavaScript 使用的 XML 分析器。在 JavaScript 中分析某些简单的 XML 可能不成问题，但使用一个完备的分析器就是另外一种情形了。性能和功能相关的问题将可能导致存在大量表面上相似而实际上共同点很少的组件。随之而来的问题就是 JavaScript XML 分析器是否支持命名空间、架构、空格、注释、处理指导等。
依我看，出于兼容性的考虑，最终的产物将是 XML 的一个子集，仅限于节点和属性。那样的话，这就只是在尖括号的 XML 和花括号的 JSON 之间作出选择的问题了。

安全性考虑

AJAX 提供动态性更强、交互性更强的浏览体验。不过，这增加了跨站点脚本 (XSS) 和跨站点请求伪造 (CSRF) 等常见类型攻击的可能性。这些类型的攻击是由攻击者向 Web 页面注入脚本代码而引发的，一般是通过 URL 实施，从而使攻击者能够控制 Web 浏览器，执行某些操作，如窃取用户名和密码，或者在用户不知情的情况下执行 HTTP 请求。

例如，攻击者可以使用动态创建的"SCRIPT"标记将恶意脚本注入客户端，从而允许将数据导入到攻击者的网站。在实施 CSRF 攻击时，攻击者可以将一段脚本注入客户端，通过使用客户端上保存的身份验证信息（比如 cookie），在另一个网站上执行未经授权的服务方法。

JSON 是一种包装数据并将其传送给客户端的有效方式。不过，由于 JSON 被认为是 JavaScript 语言的一个安全子集（它不包括赋值和调用操作），因此许多 AJAX 应用程序只是简单地将 JSON 字符串直接传递给 JavaScript 的 eval 函数来创建 JavaScript 对象。因此，非正常的 JSON 字符串为攻击者提供了在客户端执行未授权脚本的新手段。

这些攻击类型中的大多数都依赖于利用 HTTP 请求上的 GET 动词。庆幸的是，ASP.NET AJAX 服务在默认情况下对远程服务禁用了 GET 动词。另外，您可以要求在请求中设置一种特殊的内容类型：其他任何情况下，ASP.NET AJAX 服务将拒绝该调用。通过设计，任何从 "SCRIPT"标记发出的对 ASP.NET AJAX 服务的直接调用都具有错误的内容类型，因而不会成功。