其实这都只是参考设计
怎样处理都行
前端能接的起来就好
我个人则是倾向200或204
原因没有什么
在一些前端套件
非2xx是会进exception
正确的URL但是没有资源
会变成理论上不该exception
但是4xx让它进入exception
简单来说在前端的显示上
没有资源与真正的404是有所区别的
如果同为404造成前端在处理上
要再区分404的差异
怎样选择都是一种trade off
我个人的选择会是不造成前端麻烦的方式

前端泪推

比较麻烦的是有些路由器会劫持 4xx 状态，然后返回一个自己的页面…然后有些人可能误解 404 不能返回页面...https://i.imgur.com/4APL4jy.pngGitHub 这样的风险就是有可能被路由器或是浏览器劫持，可是作法是合乎规范的，反而 CODE 传 200 却给 404 页面是积习难改了...

推这篇

200+1不能只自己爽

有时候明明是标准，但也只能跟一堆不标准乱搞的client妥协web上充满这种事情啦不过追根究底来说这也可能是API设计或呼叫API的人想法还不

推

够适应RESTful，这种资源路径不是查询，极端一点来说client应该本来就知道资源存在才去存取(由别的API取得id、POST或PUT成功后、HATEOAS...)，而不是去试不知道有没有的资源

是，如同 ssccg 大说的，以 REST 风格设计时，理应不会有“正确的 URL 却没有资源”这件事，因为 URL 就对应资源使用者想要访问不存在的路径，就是想要拿不存在的资源，此时的 404 既合乎 HTTP Code 的规范也合乎 REST 风格在开发资源和时程充足的状况下，发生这种事是要回头检视为什么会访问不存在的路径或者说资源

我觉得原po只是想问查无资料的情境吧？

身为前端，在UX没有明确设计对于"没有资源"或"路径不存在"要呈现的差异，我倾向以发生问题的时候可以迅速让技术团队知道是什么原因的设计方式，所以终究还是看团队约定

Api未必只有前端会call...Microservice 的情况api大多是其他后端app在call后端call的时候4xx抛出例外是合理的。包含url正确但是没有资源（GetById时）

混合多种资源的 API 通常不会采 RESTful 设计

推这篇

有些企业内部的设备会拦截 200 以外的 response