我正在编写一个 REST-ish API 服务，它提供了通过 OAuth 与其他 3rd 方服务（它们本身是 REST API）中的最终用户数据进行交互的能力。一个常见的例子可能是将数据从我的服务发布到第三方服务，例如 Facebook 或 Twitter。
假设，例如，我与最终用户和 Facebook 一起执行 OAuth 舞蹈，从而产生一些短期访问令牌，我的服务可以使用该令牌与用户的 Facebook 帐户进行交互。如果该访问令牌过期并且用户尝试使用我的服务发布到 Facebook，我会向用户返回什么样的错误？
401 对我来说似乎不太合适；似乎 401 将适用于 MY 服务的用户身份验证状态。 403 似乎更合适，但也很通用。
【问题讨论】：
401 是要走的路。定义 HTTP 协议的 RFC2616 的两段摘录：
第 10.4.2 节（约 401）：
如果请求已包含授权凭据，则 401 响应表明授权已被拒绝 凭据。
这似乎适用于过期的令牌。有身份验证凭据，但它们被拒绝，因此用户代理必须重新进行身份验证。
第 10.4.4 节（约 403）：
服务器理解请求，但拒绝执行。 授权将无济于事，并且不应重复请求。
当尽管有用户凭据仍无法访问资源时，应使用此选项。可能是一个网站/API，仅适用于美国被亚洲 IP 或已被宣布有害并已停用的网页（因此找到了内容，但服务器拒绝提供它）。
在 OAuth2 上，推荐的工作流程取决于令牌的传递方式。如果通过 Authorization 标头传递，服务器可能会返回 401。当通过查询字符串参数传递时，最合适的响应是 400 Bad Request（不幸的是，这是最通用的 HTTP 请求）。这是由 OAuth2 规范的第 5.2 节定义的 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26
【讨论】：
通用并没有错，听起来 403 状态是相关的 - 没有什么能阻止您提供更易于阅读的版本，更详细地说明原因。
【讨论】：
如果您对错误响应有一定的野心，我认为以下是一份全面的清单。
400 错误请求
对于格式错误的请求，例如，如果一个参数需要一个介于 0-9 和 11 之间的 int 已被发送。你可以返回这个，并在响应正文中指定parameter x requires a value between 0 and 9
401 未经授权
仅用于授权问题。签名可能是错误的，之前可能已经使用过随机数，发送的时间戳不在可接受的时间窗口内，再次使用响应正文来更准确地指定您对此进行响应的原因。为了澄清起见，仅将其用于与 OAuth 相关的错误。
403 禁止
明确表示完全不可能（现在或永远）不可能进行格式良好且经过授权的操作。例如，如果某个资源已被另一个用户锁定以进行编辑：使用响应正文说出类似于Another person is editing this right now, you'll have to wait mmkay? 的内容。
403 Forbidden 也可能与尝试获取资源有关。例如，假设用户可以访问资源 /resource/101212/properties.json 但不能访问 /resource/999/properties.json，那么您可以在响应正文中简单地声明：Forbidden due to access rights。
404 未找到
请求的资源不存在。或者 URL 根本没有成功映射到您服务中的 API。在响应正文中指定。
405 方法不允许
这是表示不能使用例如GET调用API，但必须使用其他方法。当它被返回时，你必须返回额外的响应头 Allow: POST, PUT, etc。
【讨论】：