假设我有一个具有两个调用的API：
/list
/detail
/ list用于获取我拥有的某些对象的标头表示形式的列表（可能是ID和标题），/ detail从列表中获取其中一个对象的完整信息。 / list没有参数，并返回JSON数组。 / detail是一个发布请求，应该给它一个JSON对象作为发布主体参数，并且该JSON对象具有应该遵循的一些模板，该模板将允许服务器确定用户想要哪个对象的详细信息
进一步假设我有一个与API交互并使用API调用生成网站的网站。
我的问题是，是否有人呼叫/ detail而不提供ID，或者使用不存在的ID响应是400还是500？将响应设为400错误代码的原因是，从服务器的角度来看，请求的格式不正确，因此请求是错误的。
但是，如果从人类网站用户的角度来看，从浏览器的角度来看，该请求可能是完全合理的，但是问题是服务器（在第一次调用中）提供了错误的数据，或者服务器提供了错误的数据。构造了错误的JSON对象以发送到服务器的网页（或由于服务器上的错误或服务器所服务的网页中的错误而可能存在的任何其他各种问题），因此最终用户可能没有任何东西该网站可以解决此问题，因此我们也有一个合理的论据，可以将响应设为500内部服务器错误，并解释为问题出在服务器上，但与“问题”无关之所以选择这个特定的调用，是因为原始问题起源于代码库中的其他地方（在构建错误列表的调用中，或者在返回无法与生态系统其余部分正确交互的网页的其他调用中）。
是否有任何适用于这种情况的标准？我发现的所有文档都涉及更明确的案例，例如呼叫者是另一个提供了错误请求的服务器，或者人工用户提交了缺少某些字段的表单，在这种情况下，更容易识别适当的响应代码。
答案 0 :(得分：2)
如果请求的主体缺少某些属性，则它是客户端错误，应在4xx的错误范围内。 400可以解决这个问题，但是422可能会更好。
正如您提到的，此问题很可能是由于另一个服务器端错误引起的。但是，HTTP通常的工作方式是状态代码仅与您实际发出的请求相关，而不是一系列可能导致发出该请求的事件。