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

当REST应用程序收到对不存在的资源的请求时，它是否应该始终返回一个请求

它是否应该为任何

GET

、

HEAD

、

POST

、

PUT

、

DELETE

、

选项

或

跟踪返回不同的状态

Spring为
GET
和
HEAD
返回
404
，为
选项
返回
200 OK
，为其他选项返回不支持的
405方法
。这不对吗

e、 这个Spring引导应用程序显示了对输入错误的URL（问候语而不是问候语）的请求的不同响应

记录的输出为：

未能获取--404未找到

未能找到标头--404未找到

未能发布--405方法不允许

未能放置--405方法不允许

未能修补--对“”的修补程序请求出现I/O错误：无效的HTTP方法：修补程序；嵌套异常为java.net.ProtocolException:无效的HTTP方法：修补程序

未能删除--405方法不允许

“”的选项请求导致200（正常）

未能跟踪--405方法不允许

简短回答：它不必总是返回
404
。更详细的回答：规范似乎提供了一些关于使用哪些状态代码的选项。位于的规范说明：


10.4.5 404未找到

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

10.4.6不允许使用405方法

请求行中指定的方法不允许用于由请求URI标识的资源。响应必须包含一个Allow标头，其中包含请求资源的有效方法列表


当使用这两种代码时，有一些解释的空间。我的解释是：如果某些资源不存在，但可以想象某些操作仍然可以应用于URI，那么
405
将更合适

例如：

GET /reservation/1

405 Method not allowed
Allow: PUT

这可能意味着，尽管在该特定资源上不允许使用
GET
（因为它实际上不存在），但您仍然可以使
PUT
工作，从而在过程中创建所述资源

可以说，
404
，虽然规范允许，但其可用性较低

关于
选项
。规范在这里：。根据规范，is并不意味着与资源本身的交互。更确切地说，这是对服务器的查询，以确定在给定URI上“理论上”支持哪些方法。例如，它支持一个通配符（“*”）查询，而这个查询也可能根本不存在。
是的，我明白你所说的GET（等）vs PUT的意思。例如，So/questionId/answerId可能不存在，因此我们无法获取，但只要So/questionId存在，我们就可以将-So 405放在适当的位置。如果这个问题不存在，那么既不能得到也不能给出答案——所以404是合适的。是的，没错。但是，再一次，在我阅读上面的错误代码时，有一些解释的空间，这在特定情况下是有意义的还是没有意义的。我不认为大多数服务器或客户端已经准备好做出这样的区分。在大多数情况下，这甚至可能没有什么不同。
GET /reservation/1

405 Method not allowed
Allow: PUT