我正在编写一个 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 规范https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26的第 5.2 节定义的
通用并没有错，听起来 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 方法不允许
This is to represent that the API can not be called with for example GET but another method must be used. When this is returned also you MUST return the extra response header Allow: POST, PUT, etc.