Http 返回错误请求（400）或内部服务器错误（500）

假设我有一个API，它有两个调用：

/list
/detail

/list用于获取某个对象的标题表示列表，我可能有ID和title，/detail从列表中获取其中一个对象的完整信息。/list没有参数，返回一个JSON数组。/detail是一个post请求，应该给它一个JSON对象作为post body参数，并且该JSON对象应该遵循一些模板，这将允许服务器确定用户想要获取详细信息的对象

进一步假设我有一个与API交互并使用API调用生成网站的网站

我的问题是，如果有人在没有ID的情况下调用/detail，或者使用不存在的ID调用/detail，那么响应应该是400还是500？将响应设置为400错误代码的理由是，从服务器的角度来看，请求的格式不正确，因此请求是错误的

但是，如果我们从人类网站用户的角度来看，从浏览器的角度来看，请求可能是完全合理的，但问题是服务器在第一次调用中提供了不正确的数据，或者服务器提供了一个网页，该网页构建了一个损坏的JSON对象发送到服务器，或者由于服务器上的错误或服务器服务的网页中的错误而可能存在的任何其他各种问题，因此网站的最终用户可能无法修复该问题，因此，我们也有一个合理的理由将响应设置为500个内部服务器错误，解释为问题出在服务器上，但问题可能与此特定调用无关，因为原始问题起源于代码库的其他地方，或者在构建坏列表的调用中，或者在另一个调用中，返回的网页无法与生态系统的其他部分正常交互

---

有什么标准可以适用于这种情况吗？我发现的所有文档都涉及更明确的情况，例如，调用者是另一个提供了损坏请求的服务器，或者一个用户提交的表单缺少一些字段，在这种情况下，相应的响应代码更容易识别。

如果请求的主体缺少某些属性，这是一个客户端错误，应该在4xx错误范围内。400适用于此，但422可能稍好一些

---

正如您所提到的，这个问题可能是由于不同的服务器端错误而产生的副作用。然而，HTTP通常的工作方式是，状态代码只与您实际发出的请求相关，不是因为一系列的事件导致了请求的产生。

我一直认为HTTP状态代码只考虑了请求和响应-你知道有哪种权威性的消息可以引用吗？我没有一个小的调用，但是只要阅读HTTP rfc就可以了。很难不得出这样的结论。您所争论的是1个响应在单独的请求中导致错误的结果实际上违反了HTTP的无状态性质的概念。最后一个GET请求是不相关的，当前的POST请求不应该知道该请求是如何制定的。