这是一个创建于 633 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在的前后端分离项目，诸如前端 VUE 项目大家都好像喜欢统一管理 API
之前和一个码农聊过，他认为完全没必要，又不是不去看页面
所以：
你是直接 http.get(后端 URL) ，还是 import 进来 await getUserList....
所以：
统一管理 API 的好处到底是啥？是不是反倒麻烦了
直接在页面直接写 URL 请求后端不好吗？
 | 1 liuhuansir 2024-01-17 17:45:09 +08:00 有没有可能一个 URL 在多个页面使用呢？ |
 | 2 lx271896700133 2024-01-17 18:00:36 +08:00 我觉得没必要。 |
 | 3 markgor 2024-01-17 18:04:43 +08:00 之前仅仅封装请求函数，不封装接口 URI ； 现在，把接口 URI 封装为方法。 好处： 复用的页面调用方便了，接口涉及修改的时候不用搜索来搜索去了； 坏处： 好像没啥坏处。 实际： 看项目规模和规定 |
| 4 markgor 2024-01-17 18:08:58 +08:00 对了，最重要一点，IDE 可以推导参数，特别是 ts 下 你如果都用 http.get(xxxxx),参数 ide 无法推导，但 IDE 的推导并不直接影响代码的执行，对于小型的项目，意义不大，来来去去几个参数，但对于大型的项目，我觉得这个还是挺好的。 |
 | 5 rabbbit 2024-01-17 18:10:31 +08:00 后端不变就第一种，后端改来改去就第二种，项目规模大第二种。 举个例子，有个接口返回 {id：xxx}，突然有一天变成了 {fooId: xxx}，然后有十几个地方依赖这个接口。 |
 | 6 molvqingtai 2024-01-17 18:21:04 +08:00 假如前端同学 A 在 A 页面已经写过一遍 getUserInfo, 另个一前端 B 在需要在 B 页面也需要调用这个接口，难道还 要翻一遍 API 文档或问后端哪个接口是获取用户信息 |
 | 7 nulIptr 2024-01-17 18:34:19 +08:00 当然可以，sql 写在 controller 里也可以啊 自己项目爱咋搞咋搞，多人合作的项目按照领导说的来，自己负责的话掂量掂量会不会不好意思给人看自己的代码 |
 | 8 rossroma 2024-01-17 19:10:17 +08:00 统一管理好处很多： 1. 可以把 get 或 post 封装起来，这样就不用担心在调用端写错了； 2. 部分接口可能需要自定义 header 或者公共参数，你可以直接写在封装的方法里，避免每次调用的时候单独再传； 3. 如果接口的 url 发生变更，你只需要改一处即可 |
 | 9 IvanLi127 2024-01-17 19:34:12 +08:00 via Android 我觉得多套一层，配套的工作量也不少。类型得定义下吧，文档得写上吧，同一个接口的多种不兼容的出入参得做重载或再写一份吧。 上面做到了才有工程化上的优势，不然只会增加 debug 的复杂程度。 愿意加强工程化的当然能抽象就抽象。不过后端靠谱的话，不建议在这上面花时间，或许在 BFF 上花时间收益还更高。 |
 | 10 itechify PRO 当然统一管理了，不然乱的一批 |
 | 11 llej 2024-01-17 20:01:10 +08:00 不管放一起也好，分开也好，只要能够 f2 重构的时候全部自动改变就行 |
 | 12 pdzinc 2024-01-17 20:04:26 +08:00 但凡项目大一点 必须上 |
 | 13 y3322 2024-01-17 20:07:14 +08:00 简单项目感觉没必要。项目规模有一定规模，还是要有的 |
 | 14 zhy 2024-01-17 20:12:53 +08:00 要不要统一管理，应该看谁来用这些 API ，如果要复用、共享，那当然要统一管理。 另外统一管理是一项长期投资，不用以后还债 |
 | 15 zhuangzhuang1988 2024-01-17 20:29:38 +08:00 要的， 看过写在一起的 然后 vue 文件特别大。 |
 | 16 dumbass 2024-01-17 22:16:26 +08:00 via iPhone 我用工具直接解析 swagger 生成请求和类型，再也不用手写请求函数啦 |
 | 17 devswork 2024-01-17 22:43:11 +08:00 当然要统一管理了： 1. 引入一层封装 API ，可以提高复用性，比如各类 common API ，字典之类、用户信息获取类，免得到处都是 URL 复制粘贴 2. 如果接口会变动，只需要改动这一层就行了，而且可以追溯到都有哪些地方用到了此 API 3. 写拦截器，统一处理状态码，统一处理 header 、token 、以及一些特定的请求头要求 4. 多个 API 组成一个功能时，可以很方便的写一个 function ，然后直接多个 API 调用配合 + 异常处理（撤销 API 、取消之类 API ），对于调用方而言只需要关心结果成功、或者失败 + 原因，封装细节不需要调用时有心智负担 5. 忽略掉了网络请求和 axios 细节，对于调用方 import 进来直接 call 调用 function + 传参，不需要关心他是 POST 、GET ... 请求方法，不需要关心 header 放什么、不需要关心参数传递是放在 QueryParameter 还是 RequestBody 、PathVariable....因为一旦封装一层，就代表 API SDK 了，只需要引入调用就行 |
 | 18 CLMan 2024-01-17 23:13:17 +08:00 WEB API 本来就天然适合封装（模块化）： - WEB 请求存在大量与应用本身无关的细节，这些细节不应该与业务逻辑混合在一起 - 需要多个地方调用相同的 WEB 请求 - 多个 WEB 请求需要复用处理鉴权、错误处理（ HTTP 状态、自定义错误代码）的逻辑 将 API 理解成远程调用的话，就更能理解为啥要封装了。 将访问外部 API 接口进行统一管理是一个很自然的想法，你疑惑为啥要这么做，可能是因为你接触的问题复杂度不够或者你习惯了麻烦。 云服务厂商在提供服务时，在提供 WEB API 的同时，同时提供封装的 SDK 也是差不多的道理。是因为用户存在相关需求，用 SDK 能降低开发成本。 |
 | 19 unt 2024-01-18 09:46:23 +08:00 正式项目“必须”上，没啥好讨论的。 实验性项目就随便了，效率第一。 |
 | 20 limiter 2024-01-18 15:26:30 +08:00 没必要，组件化开发之后各接口交由各组件自己维护调用，只封装统一的业务逻辑，鉴权、失败处理等。要允许部分资源的重复，都放在一块很容易创造上帝类，然后整个项目到处引用，改都不好改 |
 | 21 Dlin 2024-01-18 17:16:01 +08:00 统一管理的目的是进行复用。我不信你愿意这里写一段，然后 copy 到另一个地方，到时候要找用了这个 API 的地方到处翻，要是改一个啥，你还得到处改。 |
 | 22 gerefoxing 2024-01-18 19:03:50 +08:00 要的，向上面说的统一管理好处很多的。强迫症看到有重复的方法和 url 就难受。 |
 | 23 kuber 2024-01-18 20:34:57 +08:00 我觉得 OP 可以了解一下软件架构设计方面的东西。封装无非是为了处理复用和应对变化。如果是做 POC 当然无所谓，怎么快怎么来，生产系统还是有必要的。 有一本很好的书，Robert C. Martin 的“敏捷软件开发”。开篇就讲解了软件架构的原则，跟你的问题相关的有开闭原则和接口隔离原则。 |
 | 24 keepRun 2024-01-18 23:53:14 +08:00 统一管理对于大项目来说是很必要的，这是个好习惯。 如果是小项目，那你怎么来都行，只要能跑就行 |
Select Language