“API不是从业务抽象出来的”视频课程

把“API设计”拉回地面：先有业务分解，才有接口

很多开发者谈API设计时，习惯从“抽象”入手——把实体、属性、方法抽出来，整理成RESTful风格或用例。但这条路径有个隐患：抽象一旦脱离业务现场，很容易变成先入为主的“自嗨”。你抽出来的对象可能只是开发视角下的数据壳，既没有回应业务方的真实诉求，也没有标记哪个环节才是触发拆分的节点。这门课恰好把API设计的源头拨回一个更本质的位置：API不是被抽象出来的，它是从业务知识里一步步分解出来的。课程标题直接否定了“抽象说”，你如果正在用“面向对象建模”来倒推接口字段，或在接口评审时被问“你这个资源划分依据是什么”却答不上来，这门课值得先看。

分解的时机，比分解动作更重要

课程只有三个小节，但逻辑是闭环的。第一节讲“从业务知识分解而来”，核心是在纠正起点：业务知识不是先画流程图再归纳接口，而是先分清角色、动作、规则，让接口从业务语义里长出来。第二节“分解的时间点：买主来了”是全场最关键的点位——它把“何时开始设计”说得非常具体：不是需求评审后，不是数据库建表后，而是当业务买主真实出现的时刻。这个“买主”既可能是外部客户，也可能是下游调用的团队；一旦买主来了，业务边界才开始具象化，接口才具备被“切”的条件。第三节“分解而得API”则是把这套过程收敛成产出：你看到的每个接口，实际都是业务职责被切分后的结果，不是模型抽象后的副产品。

这套课适合两类人：一类是刚接触后端接口设计、但没人指点过“接口从哪里来”的初级开发者，尤其适合那些能写CRUD、却在独立设计接口时拿不准切入点的学习者；另一类是有两年左右经验、想在接口评审中更有底气的开发。你需要的基础不高——看得懂业务流程图、知道HTTP请求大概多长、见过几次接口迭代就够了，不需要你掌握微服务或DDD。

学完能做什么，以及怎么配合练

学完之后，你应该能在接到一个业务需求时，先列出参与角色，标出“买主”（谁真正提出了需要、谁在哪个环节被触发），然后顺着业务动作走到分解点，最后输出一份有一致性的接口清单。你能向同事解释“为什么要把拆单和支付分成两个接口”——不是出于规范，而是因为它们是两次业务买主触发的不同动作。你也会开始留心现有接口是否把多个业务知识混在一个资源里，从而提出更靠谱的重构建议。

配合练习可以这样：先看第一节，然后立刻找一张你常接触的业务流程图（比如借书流程、订单流程），试着标出流程中所有“买主”出现的节点，再对每个节点写出对应的动作动词。看完第二节后，回头检查你是否把“用户登录”和“获取用户信息”误归为同一类分解。第三节看完以后，试着把你自己负责模块的接口列表和原始业务场景一一对应起来，凡是找不到对应业务知识来源的接口，就是潜在的“无根接口”。如果你现在手头没有合适需求，也可以拿课程里的小例子做复述——重点不是记住结论，是跑通“业务知识→买主出现→分解”这条链路。