HTTP Post API。请求参数格式正确,但在db中无法识别。返回400或404?

时间:2018-08-02 09:50:25

标签: rest api http

赋予HTTP Post API端点如下:

http://localhost/context-root/{value}

和为实体形成的请求正文:

{
 "key":value
}

URL value对应于在POST调用之前需要在后端数据库中存在的值

并且该值在后端数据库中不存在

并且请求主体的格式正确

并且我们应该在此基础上传达未能将请求主体持久保存到数据库的信息

应该将HTTP响应代码设为400还是404?

1 个答案:

答案 0 :(得分:1)

  

应该将HTTP响应代码设为400还是404?

我可能会自己使用404

以下是POST的标准要求

  

...此规范定义的几乎所有状态代码都可以在对POST的响应中收到(例外是206(部分内容),304(未修改)和416(不满足范围))。 / p>

因此,如果我们接受404是可用于响应POST请求的可接受状态代码,那还有什么意思?

非正式地,404将客户的注意力引向request line的请求目标元素,在这种情况下可能正是您想要的。

HTTP的部分意义在于该协议掩盖了资源的基础实现。从这种外部角度来看,实现是在与数据库对话的http服务器进程中运行的插件还是CGI脚本都无关紧要。

因此,您可以尝试进行以下实验:选择一个沼泽标准HTTP服务器,对其进行配置,以使其将对/ context-root / {value}的任何请求都视为CGI请求,然后查看在必要脚本被接收时收到的响应无法使用。

但是,如果您认为“错误”的事情,我不认为REST警察会追随您。除了语义,两个代码之间的实际区别是404是cacheable by default,而400不是。缓存是not permitted,用于返回使用不安全方法的请求的响应,而400404的{​​{3}}规则是相同的。

结论:使用404,如果有人真的很在乎提交请求,则可以稍后考虑其参数。