我正在编写REST-ish API服务，它提供了通过OAuth与其他第三方服务（自身REST API）中的最终用户数据进行交互的能力。一个常见的例子可能是将数据从我的服务发布到第三方服务，如Facebook或Twitter。
例如，假设我与最终用户和Facebook进行OAuth舞蹈，从而产生一些短期访问令牌，我的服务可以使用该令牌与用户的Facebook帐户进行交互。如果该访问令牌过期且用户尝试使用我的服务发布到Facebook，我会向用户返回什么样的错误？
401对我来说似乎并不合适;似乎401将通过MY服务应用于用户的身份验证状态。 403似乎更合适，但也非常通用。答案 0 :(得分：3)
401是要走的路。 RFC2616的两个摘录定义了HTTP协议：
第10.4.2节（约401）：
如果请求已包含授权凭据，则为401 回复表明授权已被拒绝 证书。
这似乎适用于过期的令牌。有身份验证凭据，但它们被拒绝，因此用户代理必须重新进行身份验证。
第10.4.4节（约403）：
服务器理解请求，但拒绝履行请求。 授权无效，请求不应重复。
除非用户凭据，否则无法访问资源时应使用此选项。可能是一个网站/ API，仅适用于美国被亚洲IP或被宣布为有害并被停用的网页（因此内容已找到，但服务器拒绝提供服务）。
在OAuth2上，推荐的工作流程取决于令牌的传递方式。如果通过 Authorization 标头传递，服务器可能返回401.当通过查询字符串参数传递时，最合适的响应是400 Bad Request（遗憾的是，最通用的一个HTTP）。这由OAuth2规范http://tools.ietf.org/html/draft-ietf-oauth-v2-26
的第5.2节定义答案 1 :(得分：1)
通用是没有错的，听起来像403状态是相关的 - 没有什么可以阻止你提供更人性化的版本，详细阐述了为什么。
答案 2 :(得分：0)
如果您在错误回复方面有一定程度的抱负，我认为以下是一份全面的清单。
400错误请求
对于格式错误的请求，例如，如果参数需要0到11之间的int，则已发送。您可以返回此内容，并在响应正文中指定parameter x requires a value between 0 and 9
401未经授权
仅用于授权问题。签名可能是错误的，之前可能已经使用过nonce，发送的时间戳不在可接受的时间窗口内，再次使用响应主体来更准确地指定您对此做出响应的原因。为了澄清，请仅将此用于与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 Not Found
请求的资源不存在。或者URL根本无法成功映射到您服务中的API。在响应正文中指定。
405方法不允许
这表示无法使用GET调用API，但必须使用其他方法。如果还是这样，你必须返回额外的响应头Allow: POST, PUT, etc。