对于不同的http方法，请求返回哪个状态的无效URL？

Question

当REST应用程序收到对不存在的资源的请求时，它是否应始终返回404 Not Found？

是否应该为HTTP methods GET，HEAD，POST，PUT，DELETE，{{ 1}}或OPTIONS？

Spring为TRACE和404返回GET，为HEAD返回200 OK，为其他人返回OPTIONS。这是错的吗？

e.g。此Spring Boot应用程序显示对错误键入的URL（问候语而非问候语）的请求的不同响应。

405 Method Not Supported

记录的输出是：

  

未能获得 - 404未找到

     

未能找到 - 404未找到

     

POST失败 - 405方法不允许

     

PUT失败 - 405方法不允许

     

PATCH失败 - PATCH请求“http://localhost:8080/greetings”上的I / O错误：无效的HTTP方法：PATCH;嵌套异常是java.net.ProtocolException：无效的HTTP方法：PATCH

     

无法删除 - 405方法不允许

     

OPTIONS请求“http://localhost:8080/greetings”导致200（OK）

     

TRACE失败 - 405方法不允许

Answer 1

简短回答： 总是返回404。更长的答案：规范似乎提供了一些关于使用哪些状态代码的选项。 https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5的规范说：

10.4.5 404 Not Found

服务器未找到与Request-URI匹配的任何内容。没有说明该病症是暂时的还是永久性的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址，则应该使用410（Gone）状态代码。当服务器不希望明确拒绝请求的原因，或者没有其他响应适用时，通常会使用此状态代码。

10.4.6 405不允许的方法

请求行中指定的方法不允许由Request-URI标识的资源。响应必须包含一个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。根据规范，不暗示与资源本身的交互。它更具体地是对服务器的查询，以确定理论上将是什么方法＆＃34;在给定的URI上受支持。它支持例如通配符（＆＃34; *＆＃34;）查询，它也可能根本不存在。