REST服务中资源不存在时的响应状态码选择问询

场景1：过滤后无匹配请求的列表接口返回策略 #

返回200状态码+空列表[]是完全合理的，无需返回404。

• 从HTTP语义来看，/requests?location=London&priority=1标识的是“符合指定过滤条件的请求集合”这个资源，该资源本身是存在的——就像一个空文件夹依然是合法存在的资源一样，只是当前没有包含任何元素。
• RFC 3986中提到的完整URL作为资源标识，这里的标识指向的是过滤后的集合，而非“非空的过滤集合”。只要接口路径本身是合法的（即/requests是存在的接口），就不该用404，404仅适用于请求的资源标识本身不存在的情况（比如拼写错误的路径/request）。

场景2：单个请求不存在时返回404的合理性 #

完全合理。
/requests/{id}的资源标识指向的就是ID匹配的单个请求资源，当该ID对应的请求不存在时，意味着客户端请求的资源确实未找到，符合HTTP 404“Not Found”的语义定义，这是RESTful API中的标准做法。

场景3：请求存在但未生成问询的返回策略 #

建议返回404，而非204。

• HTTP 204“No Content”的语义是请求的资源存在，但没有可返回的内容（比如一个已创建但未填充数据的资源），但这里的/requests/{id}/inquiry对应的问询资源在请求达到特定状态前是根本不存在的，并非“存在但无内容”。
• 如果需要让客户端区分“请求ID不存在”和“请求存在但无问询”两种情况，可以在404的响应体中添加自定义说明（比如{"error": "inquiry_not_generated", "message": "请求已存在但尚未生成问询"}），但状态码依然用404更符合HTTP语义。

区分无效URL与资源不存在的404 #

HTTP标准中404的语义就是“请求的资源未找到”，并不区分是路径无效还是资源本身不存在。如果需要让客户端自动区分这两种场景，除了在响应体中携带明确的错误类型标识（比如新增error_type字段，取值为invalid_path或resource_not_found），没有更通用的标准方式：

• 子状态码（比如404.1、404.2）虽然存在，但大部分HTTP客户端和框架并不会解析或依赖这些子状态，兼容性很差。
• 用400“Bad Request”标识无效URL并不合适，400针对的是请求格式错误（比如参数格式不对），而非资源路径不存在。

内容的提问来源于stack exchange，提问作者Luis Abreu