是否有从JSON web服务返回错误状态的传统方法？

Question

我有一个。net.ashx处理程序，它接收jQuery AJAX post,格式化向第三方服务发送的web服务请求，并使用结果。成功后，它将使用相关信息实例化匿名对象，并格式化JSON响应字符串。

如果出现web服务错误，我将执行以下操作：

context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
context.Response.StatusDescription = wsResult.ErrorCode;

这使得jQuery AJAX错误回调可以轻松地访问状态代码和描述；然而，我实现这一点的方式是相当武断的。

在对以下问题进行了一些阅读之后，我找不到一个结论性的答案：是否有一个公认的、通用的约定（甚至是规范）来将错误状态返回给基于JSON的AJAX调用，它允许任何使用者知道会发生什么，或者这是否像任何其他函数调用的返回类型一样任意？

那么，这是一种完全可以接受的向AJAX调用方返回错误状态的方式吗？还是有一种“适当”的方式来格式化JSON错误响应呢？

Answer 1

正如其他人所说，没有普遍的惯例。其余的“社区”仍在寻找类似这些问题上的一些共识--共识可能永远不会找到。仅举几个例子：

状态代码

默认情况下，ServiceStack.NET是一个广泛使用的C# <罢工> REST库 web服务框架，返回带有状态代码的对象（或空响应），例如：

200确定

在验证错误的情况下（例如ArgumentException)，它可以执行以下操作：

400错误请求

有些人更喜欢422 Unprocessable Entity来表示验证错误，这是HTTP协议的WebDAV扩展，但在技术上仍然完全可以接受。

其他人认为您应该简单地使用HTTP协议中未使用的错误状态代码之一，例如461。Twitter已经通过420增强您的冷静来通知客户机他们现在的速率受到限制--即使已经有 （表面上） 可接受（和推荐）状态代码429太多请求用于此目的。

等。这都是哲学的问题。

至于500 Internal Server error，情况也是一样--有些人认为它完全适用于所有类型的错误响应，另一些人认为5xx错误只应在异常时返回（在真正意义上--即异常错误）。如果错误确实是异常的，那么您基本上不想冒险传递任何实际的异常信息，这可能会泄露太多关于您服务器的信息。

引导我们在JSON结果中返回什么（如果有的话）？同样的事...

回应

200 OK可能足够响应例如删除资源的请求，如果没有发生错误的话。同样，404 Not found足以告诉客户端，由于未找到要删除的实体，无法执行请求的删除。在其他情况下，您可能需要更多。

有些人认为您应该在响应头中包含尽可能多的所需信息，通常只有头的空响应。例如，在创建时，返回201created并将创建的实体的ID（作为资源URI）放在content-location中。不需要响应内容。

我个人认为，如果您正在制作一个公共API，返回适当的头和内容是一个好主意，即使内容有些冗余。即：

HTTP/1.1 404 Not found
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The user Mr. Gone wasn't found.'
}

（我实际上并没有包含success属性，但我可能希望包含，这取决于我在设计API时的心态）。

在调试模式下运行时，我还包括内部服务调用的字符串表示形式-例如'request':'getUser{id:5}'、时间戳和堆栈跟踪。不过，这都是为了方便。只需根据404 Not found就可以用正确的用户友好的错误消息编写客户端代码。但是，其他一些错误（例如验证）可能需要更多的上下文。例如：

HTTP/1.1 422 Validation Error
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The request had validation errors.',
   'Errors':
   {
       'UserName': 'The user name must be provided.',
       'Email': 'The email address is already in use.'
   }
}

简而言之，不，没有任何普遍的惯例--至少现在还没有。很多人（比我投入更多的心思）都在做这件事。但也许永远不会有。你的方法完全可以接受。

（是的，这很冗长--主要是因为我已经四处寻找同一种“普遍约定”有一段时间了）。

关于状态代码的更多信息，这是一篇很好的文章（太长了，不能在这里引用）