是否存在错误/错误代码标准？

发布于 2024-12-14 12:22:08 字数 1458 浏览 0 评论 0 原文

我目前正在为国际象棋游戏编写 API/一些客户端。

开发人员应通过一个脚本 (xhrframework.php) 访问 API 并通过 GET 提交操作。他们在提交操作时可能会犯一些错误（没有发送 PHPSESSID、没有有效的 PHPSESSID、移动无效、还没有轮到他们，...）。

所以我考虑了如何显示错误的可能性。我想出了一些如何通知程序员他犯了错误的想法：

通过清晰的英语错误消息
- +：很清楚错误的含义
- +：可以添加如何修复此错误的信息
- -：由于我的英语不太好，消息可能会改变
- -：消息的长度差异很大 - 这对于 C 程序员来说可能很重要
，通过英语的 ab 错误消息常量 - 类似 WRONG_PHPSESSID、MISSING_PHPSESSID、INVALID_MOVE、NOT_YOUR_TURN 等
- +：人类可以理解
- 0：几乎可以肯定消息不会改变
- -：消息的长度可能略有不同
-：消息的长度可能会通过错误代码与文档中的一个表，程序员可以在其中找到错误代码的含义
- +：错误代码不变
- +：每个错误码的长度可以相同
- -：这很神秘

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

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

哪些错误应该得到哪些数字？按错误数量对错误进行分组是否有意义，例如，所有以 1 开头的错误都是身份验证错误，所有错误都带有两个游戏逻辑错误？从错误 1 开始并使用每个数字会更好吗？

Google Maps API

如果我调用错误对于 Google Maps JS-API，它会返回带有清晰德语消息的 Java 脚本（我猜是因为我住在德国）。

如果我创建错误调用。

原文

I am currently writing an API / some clients for chess games.

The developers should access the API via one script (xhrframework.php) and submit the actions via GET. It is possible that they make some errors when they submit the actions (No PHPSESSID sent, no valid PHPSESSID, move was not valid, it's not their turn, ...).

So I thought about the posibilities how to display errors. I came up with some ideas how to inform the programmer, that he made an error:

via an error message in clear english
- +: It is clear what the error should mean
- +: Information how to fix this error can be added
- -: The message might change as my english isn't very good
- -: The length of the message differs quite a lot - this might be important for C programmers
via ab error message constant in english - something like WRONG_PHPSESSID, MISSING_PHPSESSID, INVALID_MOVE, NOT_YOUR_TURN, ...
- +: It's understandable for a human
- 0: It's almost sure that the message doesn't change
- -: The length of the message might differ a bit
via an error code with one table in the documentation where the programmer can find the meaning of the error code
- +: The error code would be constant
- +: The lenght of every error code could be the same
- -: It's cryptic

I thoguht the third solution might be a good idea as the xhrframework.php should only be accessed by a programmer who quite possible took already a look at the API documentation.

Now I would like to know if a standard for Web-API-Error messages does exist. How did others (e.g. Google Maps API) solve this? Should I simply output a blank page with the content "ERROR: 004" or without padding "ERROR: 4"?

Which errors should get which numbers? Does ist make sense to group errors by their numbers, e.g. all errors beginning with 1 were authentification errors, all errors with two game logic errors? Would it be better to begin with error 1 and use each number?

Google Maps API

If I make a wrong call to the Google Maps JS-API, it returns Java-Script with a message in clear German (as I live in Germany, I guess).

The Google Static Maps API returns a message as text in clear English if I make a wrong call.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

北座城市 2024-12-21 12:22:08

大多数 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 通常用于安全错误情况。

Most API services follow the HTTP error code system RFC2817 with ranges of error codes for different types of error:

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

In an API context you would mostly use the 4xx values to denote error conditions to do with the validation of requests. 49x are generally used for security error conditions.

回复收藏 0 原文

不必在意 2024-12-21 12:22:08

没有标准，为什么要有标准？使用您的界面的程序员已经必须了解这一点，这可能是自定义的，因此需要编写自定义错误处理代码只是包的一部分。

我建议你制定一个你会坚持使用的合理格式。您可以采用每个世界中最好的方法，并在返回的内容中包含几条信息，也许是这样的：

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

这样，如果发明了旧客户端不理解的新错误类型，他们仍然可以识别出返回以“ERROR”开头，知道出了问题；通过解析错误代码（不要使用整数，这浪费每个人的时间），如果程序员考虑到错误，他们可以采取适当的措施。最后，如果您为选定的错误输入一个友好的字符串，则可以轻松地向用户呈现一些不错的内容或有助于调试。

There's no standard, and why should there be? Programmers using your interface already have to learn that, which is presumably something custom, so needing to write custom error handling code is just part of the package.

I would suggest you make up a sensible format you will stick with. You could go with the best of each world and include several pieces of information in what you return, perhaps along these lines:

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

That way, if a new error type is invented that old clients don't understand, they can still recognise that the return begins with "ERROR" and know that something went wrong; by parsing for the error code (don't use integers, it's a waste of everyone's time), they can take appropriate action if it's error the programmer has taken into account. Finally, if you put in a friendly string for selected errors, it makes it easy to present something nice to the user or be helpful for debugging.

回复收藏 0 原文

~没有更多了~