每个开发人员都不愿看到的一种错误报告是：“我测试了一下你的服务，它不起作用。”这个错误报告没有附带任何进一步的说明。是的，对这样的用户，我无法帮他解决问题，但是，我会建议通过仔细观察错误消息，你可以收集到一些有用的信息。

　　比如说，你有一个服务，它接受一个采用HTTP/1.1的GET请求，一个成功的响应消息的第一行应该象这样：

　　这个“状态行”包括三部分：协议版本、状态码、和原因描述。其中协议和状态码是给客户端软件处理用的，但原因描述只是用来给开发人员提供辅助信息的。

　　REST和HTTP响应状态码

　　在SOAP服务中，响应是一个采用XML格式的信息体，它或者是一个成功返回的结果，或者是符合SOAP标准的错误信息；与SOAP服务截然不同的是，RESTful服务的客户端可能会接收到任何类型的内容，因而也就没有标准的错误信息体。RESTful风格需要使用标准的HTTP状态码来表征响应的状态。对于HTTP1.1，状态码可以分为如下5类：

• 　　100-1xx 需要继续处理
• 　　200-2xx 成功
• 　　300-3xx 重定向
• 　　400-4xx 客户请求错误
• 　　500-5xx 服务器错误

　　对我们来说，最重要的是能够区分客户端错误和服务器错误。如果错误的真实原因是客户请求的格式错误，这时候去调试服务器代码无疑是浪费时间。但不幸的是，在某些情况下，你会得到400系列的错误码，但是实际上并不是客户请求的错误而是服务器错误。以下是常见的一些客户端错误码，以及HTTP1.1的标准解释和可能的原因：

• 　　400 错误的请求：有时候请求的格式错误，服务器无法处理。如果服务器无法确定一个更准确的错误码，这个是缺省的错误码，但同时在消息体中会有更多描述信息。比如说，在我所举的  RESTful 例子中，Amazon S3 (简单存储系统) 提供了一个全面的错误响应信息集 ，并通过XML传回。你的客户端是否能看到这些更具体的信息，还依赖于你的浏览器的设置。
• 　　403 请求被禁止：由于某种原因，对服务的访问被禁止，比如说授权验证失败。
• 　　404 请求的资源未找到 ：通常这是由于服务不能将请求的URL映射到相应的资源。或者是这个URL不正确，或者是服务容器不能启动该应用。
• 　　405 方法未允许： 举例来说，客户试图调用“删除”方法，但服务不支持这个方法。

　　如果客户请求是正确的，并且传送到了服务端，那么还有可能会发生以下一些后续的错误. 只此两个可能的状态码并不会对你有太大的帮助，但至少你知道，客户请求已经发送到了服务器端。幸运的话，服务器端应该有一些更详细的日志信息。

• 　　500 服务器内部错误：在响应消息头或消息体中可能会后其他信息，但浏览器的设置不同，这些信息不一定能显示出来。
• 　　503 服务无法获得：这个响应意味着，服务器可能是临时性的负载过重，客户可以稍后重试。

　　注意，服务可能会因为很多不同原因而返回一个500的状态码。RESTful 服务框架，比如 Jersey 提供了很全面的错误报告选项，但在这一领域还没有一个标准方式。在缺省情况下，客户浏览器可能会显示一个让用户不知所云的栈调用过程记录。

　　在《Web服务的错误报告机制：错误消息处理器和SOAP服务》中，我们将继续为您介绍。