这篇就不以引述的方式回覆了，因为算是对 後续其他人不论在推文中或是回文中的内容 回覆，另外也是针对我自己在前一篇文章中 没有提到的部分进行说明。 (1) 叙述问题与回答问题 我不知道这里有多少人上过 jserv的课，如 果有的话，他会频频强调不要「举烛」。从 推文和回文中可以看到，其实不论是发文者 还是回答者，似乎并没有很正视这个问题… … 回到最一开始的问题： 「API 没资料要回传 200 还是 404？」 ‧什麽样的 API 呢？ ‧什麽样的场景下设计的呢？ ‧什麽样的状况叫做没资料？ ‧有没有基於什麽规范或风格？ ‧调用的人是谁？ ‧你怎麽想的呢？ 如果没有叙述清楚，要人怎麽回答呢？我想 分享一下两段文字： https://i.imgur.com/JWMQJjn.png [来源] http://hhp.li/4aq287 https://i.imgur.com/KPxidqA.png [来源] http://hhp.li/43pp7h 你真的想要得到的答案是这样的吗？ 「公司前辈这样做就这样做啦！」 「为了方便，问就是 404 一把梭！」 这样可以得到什麽成长吗？你认为去有规模 的公司面试问到这样的问题时，用这样的回 答可以拿到 Strong Hire？老实说，这样的 提问方式和不明就理的回答方式，只会让社 群的风气变得越来越糟。 (2) 不是只有 REST 一种设计风格 虽然在前一篇文章中以及推文中，我主要都 以 REST 风格的叙述为主，但那个前提是我 认为那样的问题叙述下，原 po 的问题是在 下述两种不同情境下，采用 REST 风格而有 所误解： --- [GET] /users [GET] /users/<USERNAME> 上述没有资料的情形会有两种： ‧在 users 中没有任何 user →状态 200 并返回 [] 於 body ‧名称为 <USERNAME> 的 user 不存在 →状态 404 视情况返回 body --- 但这并不代表实际开发就只有 REST 这一种 以资源为导向的风格，还有 RPC这种以方法 为导向的风格，比如早期可以见到 SOAP 的 身影，近期为了更好地适应某些场景以及发 挥 HTTP2 的优势，还可以选择 GraphQL 或 是 gRPC 。如果是区块链的开发者，应该更 常透过 JSON-RPC 协议读取数据。 比如以登入、搜寻等业务，就不是很好将这 两个操作抽象为资源，并以 REST 实作。当 然要实作也并无不可，比如常见地将登入行 为改以 session 资源的创建、查询与删除… 这很要求开发者的抽象能力，并且对於复杂 业务来说局限性很大；或者当我只需要文章 的标题与发表时间，以 REST 实作就会拿取 冗赘的资料。 当然，他们都各有优缺，也需要开发人员去 做取舍的。我建议拿上述关键字去搜一下差 异，包含 payload和调用方法等；想再了解 更多可以参考各个团队的技术文章，我会整 里几篇放在最後的参考资料中。 (3) 考量资源限制与团队协作 後面的回覆中，有板友提及了倾向於使用特 定状态码是为了方便前端介接；也有板友提 及企业内部设备会拦截特定状态码。这些的 确都是实务上的限制与考量，为了让开发顺 畅必须要沟通与协调的，有时候为了时程和 和外部限制（比如客户其实没这麽聪明又要 求很多），当然是以能跑为第一前提…… 不过这点其实我想稍微纠正一下，但必须先 说这不是所有团队都适用，就是「不能只有 自己爽」这件事情，有时候还请三思一下是 谁在自己爽。 --- 前提状况如下： ‧以 REST 风格设计 ‧接口 [GET] /users/<USERNAME> ‧<USERNAME> 不存在时返回 200 而非 404 好的，前端可以快速知道今天是後端的接口 坏掉还是正常；但是出问题时，後端要怎麽 判断是不是参数错误呢？ DevOps/SRE 负责 监控状态，然後一片都 200看起来很正常， 但是使用者说资料都空的，怎麽排查？ 透过正确的 HTTP Status Code 可以很快地 让後端和 DevOps/SRE 定位原因，如果都是 200 的话，需要每一个状态都打开查看内容 才能判断，这真的是个好方式吗？ 在後端看来，他依照 REST 风格和 HTTP 规 范设计，是他为了自己爽吗？ --- 即使进到 exception也能够根据状态码再去 处理，而状态码 404 也能够携带 body而不 是就没有了内容；至於前端的请求函数库， 以 axios 来说可以自定义 validateStatus 调整 reject 的范围吧？ 今天前端会呼叫 API有八成的状况是采取了 AJAX 方式，获取资料於页面上渲染，如果 能够接受图片、影片也是以 URI的方式镶嵌 在你的 HTML 中，实际上被渲染出来也是由 浏览器对 URI发送请求获取资源，取得後再 渲染在页面上，图片网址错误无法访问时， 对 Nginx/Apache 来说也是返回 404 呀！ 如果是 JSON 返回一项资源，比如文章内容 或使用者资讯时，这时候网址错误时返回同 样的 404为什麽就这麽难以接受呢？ > 我从 /users/posts 拿到了 pid = 256 > 但是 /posts/256 却 404 > 权限不够或是真的没有这篇文章 > 回去检查为什麽 /users/posts 吐出 256 （抱歉上述是以网页应用程式为叙述，我知 道对於移动端开发来说，Android 跟 Swift 下的一些 HTTP 请求框架也有问题，但我不 熟，就再请熟悉的板友帮忙补充了…） 另外 REST 风格真的不善於处理混合多种资 源的状况，交给 GraphQL 处理会爽很多… (4) 前端页面？API？ 以 GitHub 来说，访问以下页面： https://github.com/love99067333/ https://github.com/search?q=3123sadq 上述两个网址都是交由伺服器端渲染返回， 并非由 AJAX 呼叫他们自家的 REST API 获 取资料再渲染於页面中。以前一篇所说明的 REST 风格设计来说，此时的「页面」就是 「资源」，分别请求的是「使用者页面」和 「搜寻 3123sadq 的结果页面」。 他也符合 RFC 723x 中对於状态码的陈述， 所以对於有资源且存在的使用者页面返回状 态码 200；而对搜寻结果页面也是 200；而 对於使用者不存在或不愿显示的私密仓库， 就会是 404 了。 --- 如果是 GitHub 对於 search 的 REST 实作 ，可以参考这里： https://docs.github.com/en/rest/search BASE_URL 是 https://api.github.com/ 你会发现： [GET] /search → 404 （没有 search 这个资源） [GET] /search/code → 422 （有 search/code 这种资源，但可能参数不足） [GET] /search/code?q=repo:octocat/Spoon-Knife+css → 200 （有 search/code 这种资源，而且参数正确） [GET] /search/cars → 404 （没有 /search/cars 这种资源） --- 这时候不应该以资料夹路径的角度去看待这 个资源，上述 REST 实作时，他不是以档案 系统的方式来呈现资源的；也不是以页面型 态呈现资源的。 老实说，他们家的 REST API 对我来说堪称 楷模，因为把很多资源的抽象都做得非常优 秀……但在下面这篇文章中，也坦言存在缺 点并增添了 GraphQL API： http://hhp.li/4anhqf (5) 参考资料 ‧API Design Guide (Google Cloud APIs) http://hhp.li/4afqel 同时考虑了 REST API 和 RPC API 设计 对於常用的 Standard Methods 多采用了 REST 风格，而 Custom Methods 多采用 　RPC 风格。 ‧Best Practices for Designing a Pragmatic RESTful API http://hhp.li/4a5n57 应该是多数 REST 使用者都曾经看过的最 佳实践文章 ‧访问远程服务（凤凰架构） http://hhp.li/4a43xw 中国一本开源的架构着作，作者是 Java 知名书籍作者，这一章节很详细地介绍了 REST 和其优缺点 ‧一把梭：REST API 全用 POST http://hhp.li/4685dk ‧A preview of the new Dropbox API v2 http://hhp.li/4a8xqy 简化 HTTP 使用多采 POST 请求，并简化 错误代码的使用，采 RPC-Style 设计 (6) 後记 还是要再说一次，在新创团队和开发资源有 限的小公司中，上面提到的东西都不一定适 用…… 不可能期待一间只有三人的新创还要搞上各 种测试跟各种优化还要部署 CI/CD 吧？ 但 没办法去到这些公司体验文化的话，从书上 和这些大厂的技术文章来吸收跟思考，是可 以做的（当然，他们内部也可能有例外跟分 歧） 说真的这个问题可以展开来说的东西太多了 ，包括浏览器在输入一个网址後会经历哪些 过程和行为，还有网页前後端的开发…今天 你是不是走前後端分离架构；如果纯粹由伺 服器渲染，还要再分中间有没有微服务或中 间件处理，或者後端直接访问资料库塞资料 给模板返回就好；是否一定要在 HTTP 协议 实现你的 API？甚至是前面有人提到的状态 码进异常，如果前端後端都不想要修改，有 没有什麽处理的方式？ 前阵子那串「对技术没热情是不是不适合这 行？」应该许多人都还记忆犹新，藉着这串 再问问文章一开始的问题： ‧如果是 Junior 的开发者，那样的发问方 　式，真的能得到解答？ ‧你不追问不细问，有多少人愿意主动发现 你没问出的问题？ ‧没人回答你，你就不找答案了吗？有人回 答你，你就直接接受了吗？ ‧如果是 Senior 的开发者，对於提问时要 不要去挖掘後面的问题？要挖到什麽程度 ？ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.82.214.46 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1656172096.A.5AE.html