错误/错误代码的标准存在吗？

Question

我目前正在编写一个API/一些用于棋类游戏的客户端。

开发人员应通过一个脚本（xhrframework.php）访问API并通过GET提交操作。他们在提交操作时可能会出现一些错误（未发送PHPSESSID，无效的PHPSESSID，移动无效，不是他们的回合等）。

因此，我考虑了如何显示错误的可能性。我想出了一些想法，告诉程序员他们犯了错误：

1. 通过清晰的英语错误消息

优点：清楚错误的意思

优点：可以添加有关如何修复此错误的信息

缺点：消息可能会因为我的英语不太好而改变

缺点：消息的长度差异很大-这对C程序员可能很重要

2. 通过英语错误消息常量-类似于WRONG_PHPSESSID，MISSING_PHPSESSID，INVALID_MOVE，NOT_YOUR_TURN等

优点：人类可以理解

0：几乎肯定消息不会改变

缺点：消息的长度可能会有所不同

3. 通过一个错误代码，并在文档中提供一个表格，程序员可以在其中找到错误代码的含义

优点：错误代码将是恒定的

优点：每个错误代码的长度可以相同

缺点：它是难以理解的

我认为第三种解决方案可能是一个好主意，因为xhrframework.php只能由已经查看过API文档的程序员访问。

现在我想知道是否存在Web-API错误消息的标准。其他人（例如Google Maps API）是如何解决这个问题的？我应该只输出带有内容“ERROR：004”或不带填充“ERROR：4”的空白页面吗？

哪些错误应该获得哪些编号？按其编号分组错误是否有意义，例如以1开头的所有错误都是身份验证错误，以2开头的所有错误都是游戏逻辑错误？以错误1开始并使用每个数字会更好吗？

谷歌地图API

如果我向Google Maps JS-API发出错误调用，它会返回一条具有清晰的德语消息（因为我住在德国，我猜测）的Java-Script。

如果我向Google Static Maps API发出错误调用，它将返回一条作为文本的英文消息。

- Martin Thoma

---

我只知道这个：http://en.wikipedia.org/wiki/HRESULT - Flo

谢谢Flo。由于我不在Windows机器上编程，所以这对我帮助不大，但它给了我一个想法，我可以如何构建自定义错误消息的结构。我之前没有考虑过将严重性添加到我的错误代码中。 - Martin Thoma

或者，对于世界上非微软的一半，我们有[http://en.wikipedia.org/wiki/Errno.h]。 - Nicholas Wilson

Answer 1

大多数API服务都遵循HTTP错误代码系统RFC2817，具有针对不同类型错误的错误代码范围：

1xx: Informational - Request received, continuing process 
2xx: Success - The action was successfully received, understood, and accepted 
3xx: Redirection - Further action must be taken in order to complete the request 
4xx: Client Error - The request contains bad syntax or cannot be fulfilled 
5xx: Server Error - The server failed to fulfil an apparently valid request

在 API 的情境下，你会主要使用 4xx 的值来表示请求验证相关的错误情况。49x 通常用于安全性错误情况。

- Stuart

---

这只是针对请求本身的，对吧？所以请求可能会成功（2xx），但仍然可能存在错误。在这种情况下，我会遵循@Nicholas Wilson的答案。 - David Callanan

您可以使用相同的编号方案来处理错误。因此，您已经接受了请求，但在处理请求时遇到了错误。然后，您会处理一个请求以获取请求的状态，然后返回处理错误。 - Stuart

Answer 2

目前还没有标准，也没有必要制定标准。使用您接口的程序员已经需要学习那些自定义的内容，因此需要编写自定义错误处理代码只是其中的一部分。

我建议您制定一个合理的格式并坚持使用。您可以选择最佳的方式，在返回结果时包含多个信息，例如：

[one of "ERROR" or "WARNING" or "MESSAGE"]
[error code with no spaces, eg "BAD_MOVE"]
[optional human readable string]

那么，如果有新的错误类型被发明出来，旧的客户端无法理解，他们仍然能够识别返回结果以“ERROR”开头并知道出了问题；通过解析错误代码（不要使用整数，这浪费了大家的时间），如果这是程序员考虑到的错误，他们可以采取适当的措施。最后，如果为某些错误提供友好的字符串，它可以轻松地向用户呈现良好的界面或有助于调试。

- Nicholas Wilson