: 推 rollr: 回404的可以 fired 了 06/22 19:54
: → moom50302: 回404来乱的吗？ 06/22 20:45
嗯，我想两位的建议可以寄信向 GitHub 和
Atlassian 这两间公司说明一下，或许可以
帮他们团队缩减人力。
当查询资源不存在时返回 HTTP Code 404：
https://i.imgur.com/67gl9w8.png
https://i.imgur.com/Mysgpr4.png
[REF] https://docs.github.com/en/rest
[REF] https://docs.atlassian.com/ConfluenceServer/rest/7.18.1/#-getNodeById

推~ 很清楚, RESTful 是这样

推

推

推！认同此篇概念

推 不过最后的 403 404 好像反了

推

楼上，404 403 的例子应该没有讲反？先验权限回403，缺乏权限的连资源是否存在都不该让 hacker 直到很合理*楼楼上*知道 （自动选字QQ推这篇对 REST 描述得满清楚

推

我刚刚没有注意 GitHub 原文那段，原来 GitHub in someplaces 没权限时回404，我个人本来以为应该优先回 403比较合理 （无论背后资源是否存在，都回 403 并不会让 unauthorized user 知道资源到底在不在），推测也许考量观点是：看到 403，hacker 会觉得背后资源有可能存在，而继续找其他方法突破 auth；但看到 404 很大机率是资源真的不存在，effort 取舍下会放弃 hack 这个资源，避免hack 半天一场空

推

谢谢原po的列举解说，以 Github 的 case 来说确实卡到了公开仓库 和私有仓库 是同样的 path pattern，无法在判断仓库是否存在前就先以 403 阻挡

说得很清楚，推

GitHub不要说REST了，就连网页接口照样丢404 XD

推

推这篇，写得很清楚

原文搞错了。重点不在查询资源存在不存在。而是你认为Client的Request行为，是正常还是预期外的error。4xx开头是 error 。2xx开头是 Info。请参考RFC2616。

推

赞赞

推

推

nice nice

原文那2位版友是在指API回空资料应该要用200而非404吧?就是对应到原po的"空无一人，并不是没有清单"这项

/users/<USERNAME> 已经指定user却找不到是种错误回404/users/<USERNAME>/followers 没有是一种正常情况回200

这个是万年议题了...怎么没有人把204一起拉来参战？ 国外都是200, 204, 404大乱斗的

可是明明就有啊.204

原文在问的不是你这个找不到user的状况吧 比较像是有这个user但他没有repo

原 po 只有说没资料吧？ /users/<USERNAME> 当 USERNAME不在数据库中，也是没资料...

可能要厘清最原po的"没资料"，是指null，还是{}或[] ?

所以应该引导他去思考这件事情，而不是直接就说 404 或 200的直接方案，这个从那篇的推文跟我这篇回文，我有将情境和前提叙述出来的

404和403的部分其实两个都可以，只要统一即可让存在但没权限和不存在两个状态无法分辨即可RFC 403的理由不一定要跟权限有关，而404也可以是故意隐藏当然如果网站有公开的部分，统一成404比较合理

下面写得不错但是上面酸他们没必要 他们只用一行字要怎怎么表达404不该用在[]而且我看原标题也会觉得再问array为空 单一资源没有的话不太可能会想用200

这么说吧，我看标题也会这么认为，而且也同意这样的状况是200 并回传空值，但是看到文章内容，会提到 404 通常是与 REST 风格的这种资源不存在混淆（不论是发文者或是他看到这样实作的那个人）。推文的可以选择回文，也可以选择推多行文字。直接用一行字不负责任地表达又说可以 fire 人，还真不知道是我比较酸还是他们比较酸？

推

推

推

原文拿Restful惯例(非国际标准)，来战国际标准。搞错优先权啦。

推

倒是讲到个点了，之前就想回标准是方便大家对齐用的，不是权威铁律，如果自己用标准感觉不方便可以不用符合，如果大家都照标准走都觉得不方便也可以修看到修文讲到回一下 (飘走)

像是 Meta 家的就没有很依照这篇提的 REST 风格（即使他们宣称是 REST API）

推 详细

我觉得其实拿 RFC 2616 的叙述来佐证 API 设计很奇怪，他当下主要目的就是设计给 hypermedia 资源的存取，只是后来有些人决定也沿用这个来当 API 的协定当然现在就渐渐变成常见的做法。就是因为后来才借用当然就需要一个 adapter虽然不一定要是 rest 但不考虑中间这层直接去引用 http 的叙述我是觉得一定会因为文件资源跟资讯的目的不同而对不上

RESTful的精神就是回归hypermedia，而不是用cgi的角度在看不管背后是个File system还是Web framework，URI呈现出来的就是资源、就跟一个网址对应一个网页都一样反过来说不把URI当资源而是API端点的话，根本不用分path像一般RPC把要做什么也都放在参数不是更单纯不会有404?

我的意思就是怎么样都应该拿后期的 RFC 而不是 2616也不是说一定要拿 RFC 但不能直接套用 2616 （回应科技博正是因为是不是从浏览器出发的这个差异所以看旧的 RFC 的时候要意识到当初他的设计不能用现代的方式自行解读

这篇才是正解，回200与204都是积非成是

我觉得MT是最被看破手脚的 大概可以想成他其他话题很呛可能也是用类似的一知半解就不知道在呛什么……

推