注册期间现有电子邮件的 422 或 409 状态代码

cur*_*der 10 api rest http

我正在构建 RESTful API,我遇到了一种情况。在用户注册时,如果电子邮件之间已经存在,那么422409它的HTTP响应代码有道理?

我有过类似的浏览一个和接受的答案是,从2012年其答案是否仍持有好?例子会有很大帮助。

cas*_*lin 12

您可能无法找到一个非常明确的答案对这个问题,一旦双方409422将适用于这种情况(我会去的409,虽然)。

对于其中任何一个,您必须确保将描述问题的有效负载发送回客户端。

6.5.8. 409 冲突

409(冲突)状态代码表示请求无法完成,由于与目标资源的当前状态的冲突。此代码用于用户可能能够解决冲突并重新提交请求的情况。服务器应该生成一个负载,其中包含足够的信息让用户识别冲突的来源。[...]

11.2. 422 无法处理的实体

422(处理的实体)状态代码表示的服务器理解的内容类型的请求实体的(因此一个 415(不支持的媒体类型)状态代码是不适当的),并且请求实体的语法是正确的(因而400(错误请求)状态代码不合适)但无法处理包含的说明。例如,如果 XML 请求正文包含格式正确(即语法正确)但语义错误的 XML 指令,则可能会出现这种错误情况。

  • 当您使用“ETag”时,“409”代表“PUT”/“POST”。它并不是为了指示业务错误而设计的。 (2认同)
  • “409”对于“PUT”来说是一个“冲突”,就像两个请求同时更新同一个实体,一个成功,另一个“409”,因为 ETag 已更新。某些框架/库/服务器可能会自动发出 409,因此我更喜欢“422” - 可以保证除了我的代码之外没有人发出它,因此监控工具报告不会误报(因为“409”是与一些预定义的 HTTP/RFC 语义共享)。 (2认同)

小智 5

我认为409在这个描述的例子中是最合适的,因为请求与已经存在的注册冲突。

例如,如果服务无法接受基于 .de 域的电子邮件地址;422似乎更可取。此示例也不符合 a 的条件,400因为 .de 域将是有效语法。