: 推 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 API 设计风格的角度去看待，实现 上还有其他的方式可以采用。 REST = Representational State Transfer ‧网路上的资源，透过 URI 与之对应 ‧资源可以有不同的表现形式，透过请求时 携带的 Content-Type/Accept 指定 ‧透过 HTTP 协议方法转化资源状态 在 RESTful 架构中，每一个 URI 对应一种 资源，所以设计上会避免路径出现动词（动 词用以转化资源状态，以 HTTP 协议的方法 来对应），而以名词呈现；加上资料库中存 放资料通常为资料的集合，因此多采用复数 形式（多个用户／多篇文章／多个仓库…） --- 以 GitHub REST API (v3) 的设计来回应推 文中提到的几个问题，举例来说： [GET] /users 获取使用者清单 [GET] /users/<USERNAME> 获取指定使用者资讯 ‧如果 USERNAME 不存在，返回 404 [GET] /users/<USERNAME>/followers 获取指定使用者的追踪者 ‧如果 USERNAME 下没有追踪者 返回 200 与空阵列 --- 差异在於以 REST 设计时，倘若今天你要拿 到 USERNAME 去进行请求，会假定你已经知 道要拿这个使用者下面的资料了，如果是使 用者不存在，代表是 Client 的问题，企图 存取没有的资源，当然是 404。 而访问指定 USERNAME 下面的追踪者时，是 要获取资源清单，所以这时的空阵列就是他 的清单，只是空无一人，并不是没有清单， 自然是 200 表示请求成功。 至於有人问说返回 404 怎麽跟 API 不存在 作区别，其实从上述的范例看的出来，今天 的 <USERNAME> 相当於是查询用的参数，访 问这个资源的确不存在，查询资源的 API的 确不存在，两件事情都成立呀！ 因为此时 REST 设计要告诉你的就是「路径 不存在，路径又对应资源，资源不存在」 --- 另外提一下推文有的一些谬误： ‧HTTP Status Code 中的 4xx 代表客户端 错误，而 5xx 才是伺服器错误，所以系 统错误更不该返回 404… ‧在 REST 中用 GET 拿资料，而 204 其实 代表的是「请求成功，但没有 BODY」， 这个比较常用在 DELETE 操作… --- 顺带提一下，规范跟设计上是需要做取舍的 ，比如 GitHub 其中有一段关於授权认证的 叙述： 「Requests that require authentication will return 404 Not Found, instead of 403 Forbidden, in some places. This is to prevent the accidental leakage of private repositories to unauthorized users.」 当没有授权的使用者去获取仓库清单时，即 使是没有权限，也必须先考虑到隐私性所以 返回 404 而不是 403 避免私有仓库被没有 权限的人知道： > 没有权限，但访问 A 仓库拿到 403 > 可以猜出有个私有仓库 A > 但使用者其实不想让人知道他有这个仓库 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.82.214.46 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1655905888.A.728.html 抱歉，这里的确是我刚刚数字写反了…我修 改了一下并把你想要说的补充上去 无论「资源是否存在都回 403」 这件事情卡到的是有公开仓库： 存在的公开仓库有权限 200 存在的公开仓库没权限 200 存在的私有仓库有权限 200 存在的私有仓库没权限 403 -> 被猜出 不存在的公开仓库 404 -> 合理 不存在的公开仓库 403 -> 不合理 好了啦，你要扯国际规范我拿给你呀： https://www.rfc-editor.org/rfc/rfc7231#section-6.3.1 https://www.rfc-editor.org/rfc/rfc7231#section-6.3.5 The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. 符合上述我说的 GitHub 设计时的两种状况 ： 1. 资源不存在 2. 存在但不想被泄漏 拜托你要酸要嘘之前，更新一下自己的认知 和当前规范有没有差异好吗？自己动手翻一 下你说的 RFC2616 也写了： https://i.imgur.com/ngpNzDp.png Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235 拿明朝的剑斩清朝的官？但其实不论是你说 的 RFC2616 还是 RFC7231/RFC9110 都也没 说错，与微软还有 GitHub 设计的状况都不 谋而合。是你误解了规范的说法，并忽略我 前面说的「在 REST 设计风格角度」下去看 待事情。 --- 你说的「重点不在查询资源存在不存在。而 是你认为 Client 的请求行为，是正常还是 预期外的错误」 是你没搞清楚吧？对於今天 Client 请求一 个不存在的 /users/<USERNAME>来说，当这 个 <USERNAME> 不存在时，就是你所说的预 期外的错误。 因为在 REST 设计的视角上，这是访问一个 不存在的资源，返回 404一点悬念都没有， 他正是你说的预期外的错误，在这个设计风 格下面，要以「资源」和「操作」来考量。 （拜托再往上翻一下国际规范，就我有上 色那一部分） --- 在应用场景下，他预期的是你先透过： /users 获取 <USERNAME> /users/<USERNAME>/followers 获取 <USERNAME> /posts/<POST_ID>/authors 获取 <USERNAME> ... 先拿到 <USERNAME> 才去打 /users/<USERNAME> --- 这是 REST 设计风格的不友善之处，因为拆 分路径和设计返回的内容，切分粒度太细跟 切分粒度太粗，要嘛是我一下就拿到一大包 资料，有很多不必要的资讯，要嘛是我要层 层打好几个请求才能拿到需要的资讯： ‧前者塞太多东西，费流 ‧後者跨多个请求，占线 可以改用 GraphQL 设计 API。 也可以单纯用 RPC 方式处理。 你是不是搞错什麽了？你所说的国际标准考 虑到 REST 的使用，在 2014 年增修了内容 ，然後你一直说他增添的内容不符合国际标 准，大叔你是在哈罗？ https://i.imgur.com/r3WxHVV.png 不要只是嘘文啊，拿你的国际标准写篇文反 驳一下呀。我先跟你说在 RFC 7231 的第二 章就引用 [REST] 添加了资源（resource） 和表现层（Representations）的叙述。 拿出点证据来嘛！当大家没看过文件？「说 话科学点，是身为工程师最基本的吧？」我 记得这好像是你说的？ 上面并不是拿 RFC 2616 来佐证设计，而是 拿修正後的 RFC 723X 来说明 REST 风格的 合理性。 在 RFC 2616 还可以看到 URL 和 URN 的描 述，在 RFC 723X 就几乎回归到更为抽象的 URI 上了，更加强调「资源」的抽象概念。 你所谓中间那层的 adapater 其实就是文件 中对於 representation 的描述，而这也是 REST 风格的一部分： 「一个 URI 对应一种资源」 不论今天这个资源是一张图片、一段文字、 一个页面，都对应成一个 URI来表示。你要 提供资料库中的使用者资讯、文章资讯，当 然也是可以，转化成一个资源并对应，而在 目前多会以方便解析的结构化 JSON/XML 格 式表示这个资源。 另外必须补充一下，现代的客户端并不是只 有网页浏览器，如果都以浏览器的角度去看 的话，就很容易会因为你说的这个差异混淆 … ※ 编辑: Hsins (111.82.214.46 台湾), 06/24/2022 09:22:36