无效数据的REST响应代码

Ami*_*tel 263 rest http jax-rs

在以下情况下,应将哪些响应代码传递给客户端?

  1. 用户注册时传递的数据无效,如错误的电子邮件格式
  2. 用户名/电子邮件已存在

我选择了403.我也发现以下我认为可以使用.

维基百科:

412前提条件失败:服务器不满足请求者对请求提出的前提条件之一

如果我应该使用除403以外的代码,建议代码.

Dar*_*ler 285

在这两种情况下,400是最佳选择.如果您想进一步澄清错误,可以更改原因短语或包含正文以解释错误.

412 - 使用最后修改日期和ETag时,前提条件失败用于条件请求.

403 - 当服务器希望阻止访问资源时使用Forbidden.

唯一可能的选择是422 - 不可处理的实体.

  • 虽然它经常在这种情况下使用,但403并不限于访问控制,因为rfc2616-10.4.4说:"服务器理解了请求,但拒绝履行它.[...]如果服务器希望制作公开为什么要求没有得到履行,它应该描述该实体拒绝的原因." 原因可能是数据无效.但是,422更适用于此. (9认同)
  • 让我们不要陷入文本批评.例如,参见http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294,它试图澄清403是否始终是授权. (7认同)
  • @fumanchu好看的.指向仅7个小时的变更请求的链接:-) (2认同)

Mik*_*eck 91

我建议使用422.它不是主要的HTTP规范的一部分,但它是由公共标准(WebDAV)定义的,它应该被浏览器视为与任何其他4xx状态代码相同.

来自RFC 4918:

422(不可处理实体)状态代码表示服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态代码是不合适的),并且请求实体的语法是正确的(因此400(错误请求) )状态代码不合适)但无法处理包含的指令.例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.

  • 请注意,引用的文本表明,当请求实体在语法上格式良好但语义错误时,422适用.如果请求实体是乱码,则400是适当的响应. (20认同)

Mat*_*y K 80

如果无法正确解析请求(包括请求实体/正文),则相应的响应为400 Bad Request [ 1 ].

RFC 4918声明,当请求实体在语法上格式良好但语义错误时,422 Unprocessable Entity适用.因此,如果请求实体出现乱码(如错误的电子邮件格式),请使用400; 但如果它没有意义(比如@example.com),请使用422.

如果问题是,如问题中所述,用户名/电子邮件已经存在,您可以使用409 Conflict [ 2 ]来描述冲突,并提示如何修复它(在这种情况下,"选择一个不同的用户名/电子邮件").但是在编写的规范中,403 Forbidden [ 3 ]也可以在这种情况下使用,尽管有关HTTP授权的参数.

412前提条件客户机提供的前提条件请求标头(例如)评估为false 时,使用Failed [ 4 ] .也就是说,客户端请求了一些东西并提供了先决条件,完全清楚这些先决条件可能会失败.412永远不应该突然出现在客户端上,并且不应该与请求实体本身相关.If-Match


dou*_*536 40

返回418 I'm a teapot明显制作或恶意且"不可能发生"的请求是很有趣的,例如CSRF检查失败或缺少请求属性.

2.3.2 418我是一个茶壶

任何尝试用茶壶冲泡咖啡都会导致错误代码"418我是茶壶".由此产生的实体可能很短而粗壮.

为了保持相当严重,我将有趣的错误代码的使用限制为不直接暴露给用户的RESTful端点.

  • 实现它,以便你的API返回"418我是一个茶壶`"来自你老板的所有请求:) (10认同)
  • @vikarjramun我已经建立了一个虚拟REST并在线下制作了一个pruductive.(预发布)现在我们的学生正在尝试创建有效的数据请求,但这都是茶壶.我是"老板" - 但它也在努力. (2认同)
  • 该RFC是愚蠢的。只要您通过滤茶器将咖啡倒入杯中,就可以在茶壶中煮咖啡。就像使用散叶茶一样。您也可以毫无问题地在咖啡厅喝茶。 (2认同)
  • @gburton 不过,这确实需要人类的干预。通过网络,您肯定需要一个具有咖啡功能的设备来制作咖啡。当然,咖啡壶和茶壶不应该响应 418。 (2认同)
  • 如果 HTTP 状态代码的其余部分是有序且干净的规范,那么此状态代码会很有趣。但事实并非如此,这是一团糟,正如这个问题和许多错误答案所证明的那样。所以幽默是很棒的,但当你在开玩笑而真正的工作却一团糟的时候就不是这样了。HTTP 状态代码 80% 集中在内部。它们是关于 HTTP 的。实际上,我们需要应用程序级别的状态代码。事实上,世界正在使用从 WebDAV 借用的“422 Unprocessable Entity”作为验证错误的基本内容,这一事实很能说明问题。HTTP 人们只是忘记了......忙着拿茶壶开玩笑...... (2认同)