我正在努力使我的REST API远离始终响应，如果出现问题，并且在返回的JSON中包含STATUS: 200 OK密钥的error，并尝试使用正确的状态发生问题时的代码。
到目前为止，我已将服务器的大多数部分移至正确的状态代码200, 201, 400, 401, 403, 404, 500, 501, and 503
目前，我正在试图找出拒绝过时访问API调用的最佳方法。目前，我正在发送使用授权令牌编码的客户端版本。
我在使用状态代码426, and 412之间停滞不前。 426状态代码的标题看起来像我想要的用例，但描述让我有点担心。 412看起来如果我将我的版本从授权令牌移开并将其置于其自己的标题内是合适的。
这是我的第一个REST API，它运行良好，我只是想将其转换为以下最佳实践。所以我有点难以置信。
TLDR;
注意：我的客户端不是Web浏览器。这是一个移动设备。
答案 0 :(得分：5)
让我们快速浏览您提出的解决方案：状态代码412现在由RFC 7232, section 4.2授权。如果所述RFC的section 3中描述的一个或多个前提条件阻止给定请求完成，则在条件请求的上下文中使用它。
代码426受RFC 7231, section 6.5.15约束。此代码使客户端知道用于访问资源的 [http]协议版本太旧而无法完成请求。这两个代码都不适用于此。
在this chart的帮助下，我认为这里有两个代码就足够了：
代码400 / Bad Request
400有点模糊（故意如此），表明请求的一般问题。
代码403 / Forbidden
这有点拉伸，因为此代码表示授权问题。但是，它本身并不与身份验证相关联，所以你应该没问题。
就个人而言，我会选择400.您可能还需要查看RFC 7807以获取传输API错误的标准化方法。
答案 1 :(得分：1)
Hei Hobbyist ...如果你想坚持官方RFC发布，那么你应该检查IETF网站（互联网工程任务组）：
不确定哪个文档，但是例如HTTP / 1.1是RFC2616的一部分，但正如我在2014年发现的那样，它被多个RFC（7230-7237）取代。
提到的状态426显示：
＆＃34; 发送426（需要升级）响应的服务器必须发送一个 升级标头字段以按顺序指示可接受的协议 降序偏好。
服务器可以在任何其他响应中发送升级头字段 宣传它实现了升级到列出的支持 协议，按优先级递减的顺序，适用于a 未来的要求。
https://tools.ietf.org/html/rfc7230#section-6.7 - ＆gt;在第57页左右，你可以找到整个描述:-) ＆＃34;
请查看这些文档，以便决定将哪些错误代码发回:-)
我希望这能澄清你的疑问。祝你今天愉快！
答案 2 :(得分：0)
这将是一个4xx状态代码，但我不认为有一个特定于您的用例。因此，400应该这样做。 （您可以在正文中发送错误详细信息，例如，请参阅https://greenbytes.de/tech/webdav/rfc7807.html）