Ajax 中的高级请求和响应(转)

清单 1. 在回调函数中处理服务器的响应

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(//n/g, "<br />");
} else
alert("status is " + request.status);
}
}

这显然是就绪状态最常见(也是最简单)的用法。正如您从数字 "4" 中可以看出的一样，还有其他几个就绪状态:

0:请求未初始化(还没有调用 open())。
1:请求已经建立，但是还没有发送(还没有调用 send())。
2:请求已发送，正在处理中(通常现在可以从响应中获取内容头)。
3:请求在处理中;通常响应中已有部分数据可用了，但是服务器还没有完成响应的生成。
4:响应已完成;您可以获取并使用服务器的响应了。

清单 2. 获取 0 就绪状态

function getSalesData() {
// Create a request object
createRequest();
alert("Ready state is: " + request.readyState);

// Setup (initialize) the request
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

在这个简单的例子中，getSalesData() 是 Web 页面调用来启动请求(例如点击一个按钮时)所使用的函数。注意您必须在调用 open()之前 来查看就绪状态。图 1 给出了运行这个应用程序的结果。

图 1. 就绪状态 0

 

显然，这并不能为您带来多少好处;需要确保 尚未 调用 open() 函数的情况很少。在大部分 Ajax 编程的真实情况中，这种就绪状态的唯一用法就是使用相同的 XMLHttpRequest 对象在多个函数之间生成多个请求。在这种(不常见的)情况中，您可能会在生成新请求之前希望确保请求对象是处于未初始化状态(readyState == 0)。这实际上是要确保另外一个函数没有同时使用这个对象。

查看正在处理的请求的就绪状态

除了 0 就绪状态之外，请求对象还需要依次经历典型的请求和响应的其他几种就绪状态，最后才以就绪状态 4 的形式结束。这就是为什么您在大部分回调函数中都可以看到 if (request.readyState == 4) 这行代码;它确保服务器已经完成对请求的处理，现在可以安全地更新 Web 页面或根据从服务器返回来的数据来进行操作了。

要查看这种状态发生的过程非常简单。如果就绪状态为 4，我们不仅要运行回调函数中的代码，而且还要在每次调用回调函数时都输出就绪状态。 清单 3 给出了一个实现这种功能的例子。

清单 3. 查看就绪状态

function updatePage() {
// Output the current ready state
alert("updatePage() called with ready state of " + request.readyState);
}

如果您不确定如何运行这个函数，就需要创建一个函数，然后在 Web 页面中调用这个函数，并让它向服务器端的组件发送一个请求(例如 清单 2 给出的函数，或本系列文章的第 1 部分和第 2 部分中给出的例子)。确保在建立请求时，将回调函数设置为 updatePage();要实现这种设置，可以将请求对象的 onreadystatechange 属性设置为 updatePage()。

这段代码就是 onreadystatechange 意义的一个确切展示 —— 每次请求的就绪状态发生变化时，就调用 updatePage()，然后我们就可以看到一个警告了。图 2 给出了一个调用这个函数的例子，其中就绪状态为 1。

图 2. 就绪状态 1

您可以自己尝试运行这段代码。将其放入 Web 页面中，然后激活事件处理程序(单击按钮，在域之间按 tab 键切换焦点，或者使用设置的任何方法来触发请求)。这个回调函数会运行多次 —— 每次就绪状态都会改变 —— 您可以看到每个就绪状态的警告。这是跟踪请求所经历的各个阶段的最好方法。

浏览器的不一致性

在对这个过程有一个基本的了解之后，请试着从几个不同的浏览器中访问您的页面。您应该会注意到各个浏览器如何处理这些就绪状态并不一致。例如，在 Firefox 1.5 中，您会看到以下就绪状态:

• 1
• 2
• 3
• 4

这并不奇怪，因为每个请求状态都在这里表示出来了。然而，如果您使用 Safari 来访问相同的应用程序，就应该看到 —— 或者看不到 —— 一些有趣的事情。下面是在 Safari 2.0.1 中看到的状态:

• 2
• 3
• 4

Safari 实际上把第一个就绪状态给丢弃了，也并没有什么明显的原因说明为什么要这样做;不过这就是 Safari 的工作方式。这还说明了一个重要的问题:尽管在使用服务器上的数据之前确保请求的状态为 4 是一个好主意，但是依赖于每个过渡期就绪状态编写的代码的确会在不同的浏览器上得到不同的结果。

例如，在使用 Opera 8.5 时，所显示的就绪状态情况就更加糟糕了:

• 3
• 4

最后，Internet Explorer 会显示如下状态:

• 1
• 2
• 3
• 4

如果您碰到请求方面的问题，这就是用来发现问题的 首要之处。最好的方式是在 Internet Explorer 和 Firefox 都进行一下测试 —— 您会看到所有这 4 种状态，并可以检查请求的每个状态所处的情况。

接下来我们再来看一下响应端的情况。

显微镜下的响应数据

一旦我们理解在请求过程中发生的各个就绪状态之后，接下来就可以来看一下 XMLHttpRequest 对象的另外一个方面了 —— responseText 属性。回想一下在上一篇文章中我们介绍过的内容，就可以知道这个属性用来从服务器上获取数据。一旦服务器完成对请求的处理之后，就可以将响应请求数据所需要的任何数据放到请求的 responseText 中了。然后回调函数就可以使用这些数据，如 清单 1 和 清单 4 所示。

清单 4. 使用服务器上返回的响应

function updatePage() {
if (request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("total-sold");
var netProfitEl = document.getElementById("net-profit");
replaceText(totalSoldEl, newTotal);

/* 图 out the new net profit */
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
var profitPerBoard = boardCost - manCost;
var netProfit = profitPerBoard * newTotal;

/* Update the net profit on the sales form */
netProfit = Math.round(netProfit * 100) / 100;
replaceText(netProfitEl, netProfit);
}

清单 1 相当简单;清单 4 稍微有点复杂，但是它们在开始时都要检查就绪状态，并获取 responseText 属性的值。

查看请求的响应文本

与就绪状态类似，responseText 属性的值在整个请求的生命周期中也会发生变化。要查看这种变化，请使用如 清单 5 所示的代码来测试请求的响应文本，以及它们的就绪状态。

清单 5. 测试 responseText 属性

function updatePage() {
// Output the current ready state
alert("updatePage() called with ready state of " + request.readyState +
" and a response text of '" + request.responseText + "'");
}

现在在浏览器中打开 Web 应用程序，并激活您的请求。要更好地看到这段代码的效果，请使用 Firefox 或 Internet Explorer，因为这两个浏览器都可以报告出请求过程中所有可能的就绪状态。例如在就绪状态 2 中，就没有定义 responseText (请参见 图 3);如果 JavaScript 控制台也已经打开了，您就会看到一个错误。

图 3. 就绪状态为 2 的响应文本

不过在就绪状态 3 中，服务器已经在 responseText 属性中放上了一个值，至少在这个例子中是这样(请参见 图 4)。

图 4. 就绪状态为 3 的响应文本

您会看到就绪状态为 3 的响应在每个脚本、每个服务器甚至每个浏览器上都是不一样的。不过，这在调试应用程序中依然是非常有用的。

获取安全数据

所有的文档和规范都强调，只有在就绪状态为 4 时数据才可以安全使用。相信我，当就绪状态为 3 时，您很少能找到无法从 responseText 属性获取数据的情况。然而，在应用程序中将自己的逻辑依赖于就绪状态 3 可不是什么好主意 —— 一旦您编写了依赖于就绪状态 3 的完整数据的的代码，几乎就要自己来负责当时的数据不完整问题了。

比较好的做法是向用户提供一些反馈，说明在处于就绪状态 3 时，很快就会有响应了。尽管使用 alert() 之类的函数显然不是什么好主意 —— 使用 Ajax 然后使用一个警告对话框来阻塞用户显然是错误的 —— 不过您可以在就绪状态发生变化时更新表单或页面中的域。例如，对于就绪状态 1 来说要将进度指示器的宽度设置为 25%，对于就绪状态 2 来说要将进度指示器的宽度设置为 50%，对于就绪状态 3 来说要将进度指示器的宽度设置为 75%，当就绪状态为 4 时将进度指示器的宽度设置为 100%(完成)。

当然，正如您已经看到的一样，这种方法非常聪明，但它是依赖于浏览器的。在 Opera 上，您永远都不会看到前两个就绪状态，而在 Safari 上则没有第一个(1)。由于这个原因，我将这段代码留作练习，而没有在本文中包括进来。

现在应该来看一下状态代码了。

深入了解 HTTP 状态代码

有了就绪状态和您在 Ajax 编程技术中学习到的服务器的响应，您就可以为 Ajax 应用程序添加另外一级复杂性了 —— 这要使用 HTTP 状态代码。这些代码对于 Ajax 来说并没有什么新鲜。从 Web 出现以来，它们就已经存在了。在 Web 浏览器中您可能已经看到过几个状态代码:

• 401:未经授权
• 403:禁止
• 404:没找到

您可以找到更多的状态代码(完整清单请参见 参考资料)。要为 Ajax 应用程序另外添加一层控制和响应(以及更为健壮的错误处理)机制，您需要适当地查看请求和响应中的状态代码。

200:一切正常

在很多 Ajax 应用程序中，您将看到一个回调函数，它负责检查就绪状态，然后继续利用从服务器响应中返回的数据，如 清单 6 所示。

清单 6. 忽略状态代码的回调函数

function updatePage() {
if (request.readyState == 4) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(//n/g, "<br />");
}
}

这对于 Ajax 编程来说证明是一种短视而错误的方法。如果脚本需要认证，而请求却没有提供有效的证书，那么服务器就会返回诸如 403 或 401 之类的错误代码。然而，由于服务器对请求进行了应答，因此就绪状态就被设置为 4(即使应答并不是请求所期望的也是如此)。最终，用户没有获得有效数据，当 JavaScript 试图使用不存在的服务器数据时就可能会出现严重的错误。

它花费了最小的努力来确保服务器不但完成了一个请求，而且还返回了一个 “一切良好” 的状态代码。这个代码是 "200"，它是通过 XMLHttpRequest 对象的 status 属性来报告的。为了确保服务器不但完成了一个请求，而且还报告了一个 OK 状态，请在您的回调函数中添加另外一个检查功能，如 清单 7 所示。

清单 7. 检查有效状态代码

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(//n/g, "<br />");
} else
alert("status is " + request.status);
}
}

通过添加这几行代码，您就可以确认是否存在问题，用户会看到一个有用的错误消息，而不仅仅是看到一个由断章取义的数据所构成的页面，而没有任何解释。

重定向和重新路由

在深入介绍有关错误的内容之前，我们有必要来讨论一下有关一个在使用 Ajax 时 并不需要 关心的问题 —— 重定向。在 HTTP 状态代码中，这是 300 系列的状态代码，包括:

• 301:永久移动
• 302:找到(请求被重新定向到另外一个 URL/URI 上)
• 305:使用代理(请求必须使用一个代理来访问所请求的资源)
• Ajax 程序员可能并不太关心有关重定向的问题，这是由于两方面的原因:

首先，Ajax 应用程序通常都是为一个特定的服务器端脚本、servlet 或应用程序而编写的。对于那些您看不到就消失了的组件来说，Ajax 程序员就不太清楚了。因此有时您会知道资源已经移动了(因为您移动了它，或者通过某种手段移动了它)，接下来要修改请求中的 URL，并且不会再碰到这种结果了。

更为重要的一个原因是:Ajax 应用程序和请求都是封装在沙盒中的。这就意味着提供生成 Ajax 请求的 Web 页面的域必须是对这些请求进行响应的域。因此 ebay.com 所提供的 Web 页面就不能对一个在 amazon.com 上运行的脚本生成一个 Ajax 风格的请求;在 ibm.com 上的 Ajax 应用程序也无法对在 netbeans.org 上运行的 servlets 发出请求。

结果是您的请求无法重定向到其他服务器上，而不会产生安全性错误。在这些情况中，您根本就不会得到状态代码。通常在调试控制台中都会产生一个 JavaScript 错误。因此，在对状态代码进行充分的考虑之后，您就可以完全忽略重定向代码的问题了。

错误

一旦接收到状态代码 200 并且意识到可以很大程度上忽略 300 系列的状态代码之后，所需要担心的唯一一组代码就是 400 系列的代码了，这说明了不同类型的错误。回头再来看一下 清单 7，并注意在对错误进行处理时，只将少数常见的错误消息输出给用户了。尽管这是朝正确方向前进的一步，但是要告诉从事应用程序开发的用户和程序员究竟发生了什么问题，这些消息仍然是没有太大用处的。

首先，我们要添加对找不到的页的支持。实际上这在大部分产品系统中都不应该出现，但是在测试脚本位置发生变化或程序员输入了错误的 URL 时，这种情况并不罕见。如果您可以自然地报告 404 错误，就可以为那些困扰不堪的用户和程序员提供更多帮助。例如，如果服务器上的一个脚本被删除了，我们就可以使用 清单 7 中的代码，这样用户就会看到一个如 图 5 所示的非描述性错误。

图 5. 常见错误处理

用户无法判断问题究竟是认证问题、没找到脚本(此处就是这种情况)、用户错误还是代码中有些地方产生了问题。添加一些简单的代码可以让这个错误更加具体。请参照 清单 8，它负责处理没找到的脚本或认证发生错误的情况，在出现这些错误时都会给出具体的消息。

　　清单 8. 检查有效状态代码

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(//n/g, "<br />");
} else if (request.status == 404) {
alert ("Requested URL is not found.");
} else if (request.status == 403) {
alert("Access denied.");
} else
alert("status is " + request.status);
}
}

虽然这依然相当简单，但是它的确多提供了一些有用的信息。图 6 给出了与 图 5 相同的错误，但是这一次错误处理代码向用户或程序员更好地说明了究竟发生了什么。

图 6. 特殊错误处理

在我们自己的应用程序中，可以考虑在发生认证失败的情况时清除用户名和密码，并向屏幕上添加一条错误消息。我们可以使用类似的方法来更好地处理找不到脚本或其他 400 类型的错误(例如 405 表示不允许使用诸如发送 HEAD 请求之类不可接受的请求方法，而 407 则表示需要进行代理认证)。然而不管采用哪种选择，都需要从对服务器上返回的状态代码开始入手进行处理。

有用的 HEAD 请求

您会发现 HEAD 请求非常有用的一个领域是用来查看内容的长度或内容的类型。这样可以确定是否需要发回大量数据来处理请求，和服务器是否试图返回二进制数据，而不是 HTML、文本或 XML(在 JavaScript 中，这 3 种类型的数据都比二进制数据更容易处理)。

在这些情况中，您只使用了适当的头名，并将其传递给 XMLHttpRequest 对象的 getResponseHeader() 方法。因此要获取响应的长度，只需要调用 request.getResponseHeader("Content-Length");。要获取内容类型，请使用 request.getResponseHeader("Content-Type");。

在很多应用程序中，生成 HEAD 请求并没有增加任何功能，甚至可能会导致请求速度变慢(通过强制生成一个 HEAD 请求来获取有关响应的数据，然后在使用一个 GET 或 POST 请求来真正获取响应)。然而，在出现您不确定有关脚本或服务器端组件的情况时，使用 HEAD 请求可以获取一些基本的数据，而不需要对响应数据真正进行处理，也不需要大量的带宽来发送响应。