当 REST 应用程序收到对不存在的资源的请求时,它是否应该始终返回 404 Not Found
?
它是否应该为任何 HTTP methods 返回不同的状态? GET
, HEAD
, POST
, PUT
, DELETE
, OPTIONS
或 TRACE
?
Spring 返回一个 404
对于 GET
和 HEAD
, 一个 200 OK
对于 OPTIONS
, 和一个 405 Method Not Supported
对于其他人。错了吗?
例如此 Spring Boot 应用程序显示了对错误键入的 URL 请求的不同响应(greeting 而不是 greeting)。
@RestController
@SpringBootApplication
public class Application {
private static Logger log = LoggerFactory.getLogger(Application.class);
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
RestTemplate restTemplate = new RestTemplate();
String badUrl = "http://localhost:8080/greetings";
for (HttpMethod httpMethod : HttpMethod.values()) {
try {
restTemplate.execute(badUrl, httpMethod, null, null);
} catch (Exception e) {
log.error("Failed to " + httpMethod + " -- " + e.getMessage());
}
}
}
@RequestMapping("/greeting")
public String greeting() {
return "hello";
}
}
记录的输出是:
Failed to GET -- 404 Not Found
Failed to HEAD -- 404 Not Found
Failed to POST -- 405 Method Not Allowed
Failed to PUT -- 405 Method Not Allowed
Failed to PATCH -- I/O error on PATCH request for "http://localhost:8080/greetings": Invalid HTTP method: PATCH; nested exception is java.net.ProtocolException: Invalid HTTP method: PATCH
Failed to DELETE -- 405 Method Not Allowed
OPTIONS request for "http://localhost:8080/greetings" resulted in 200 (OK)
Failed to TRACE -- 405 Method Not Allowed
最佳答案
简短回答:它没有总是返回404
。更长的答案:规范似乎提供了一些关于使用哪些状态代码的选项。规范在 https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5说:
10.4.5 404 未找到
服务器未找到与 Request-URI 匹配的任何内容。没有迹象表明这种情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址,则应该使用 410(Gone)状态代码。当服务器不想透露请求被拒绝的确切原因,或者没有其他响应适用时,通常使用此状态代码。
10.4.6 405 方法不允许
对于由 Request-URI 标识的资源,不允许在 Request-Line 中指定的方法。响应必须包含一个 Allow 头,其中包含所请求资源的有效方法列表。
何时使用这两个代码有一定的解释空间。我的解释是:如果某些资源不存在,但可以想象某些操作仍然可以应用于 URI,那么 405
会更合适。
例如:
GET /reservation/1
405 Method not allowed
Allow: PUT
可能意味着,尽管在该特定资源上不允许 GET
(因为它实际上并不存在),您仍然可以使 PUT
工作,从而创建所述资源在此过程中。
可以说,404
虽然是规范允许的,但用处不大。
关于 OPTIONS
。规范在这里:https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 .根据规范,不暗示与资源本身的交互。它更像是对服务器的具体查询,以确定给定 URI “理论上”支持哪些方法。它支持例如通配符 ("*") 查询,该查询也可能根本不存在。
关于rest - 对于不同的 http 方法,对于无效 URL 的请求返回哪种状态?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35387209/