后端的活儿是怎么变少的
如果说前端决定画面上什么在哪里，那后端决定的是在里面显示什么。两者归根到底都是在服务器上接收请求并返回值。
这个分工从前并非如此，因为后端工具连画面也一起画。给数据定形的部分、画画面的部分、连接二者的部分都放在一个框架里，这种构成叫 MVC 模式。在 Python 里，Django 长期占着这个位置。
后来正如上一篇所说，画面绘制移交给了 Next.js。于是后端三个部分里画画面的那块脱落了，剩下的只有一个问题：该给什么值。
只做这件事的轻量工具接下了这个位置，那就是 FastAPI。氛围编程里这个名字频繁出现，正是因为如今这个位置在这里。每种语言都有好几个这样的工具，Java 的 Spring、PHP 的 Laravel 占的是同一个位置。
API 与 JSON
API 是程序之间彼此对接的窗口。就像人与电脑相遇的地方叫用户界面，程序与程序相遇的地方也这么叫。
前端和后端最终就是隔着这个窗口对话。前端把要画的框架准备好，向后端索要填进去的值，后端把答案返回来。
答案的格式是 JSON：花括号打开，名字与值成对，用逗号相连。有固定格式，接收方才能机械地解析。
后端和前端的结构是一样的。别人做好的库用 pip 取来，与自己的代码合并。跟 npm 是同一个位置，只是名字不同。
请求 GET /api/posts?page=2
响应 {
"items": [
{ "id": 11, "title": "第一篇" },
{ "id": 12, "title": "第二篇" }
],
"total": 57,
"page": 2,
"pageSize": 10
}API 设计就是定下三件事
API 之所以也讲设计，是因为有三件事要定。
第一是地址规则。哪个地址返回列表，哪个地址返回单条详情。有了规则，下一个人光看地址就知道它做什么。
第二是动作的划分。用户做的事归结起来就四种：新增、读取、修改、删除，取首字母叫 CRUD。同一个地址靠请求方式来区分这四种。
第三是响应的形态。这一项最常被漏掉。给列表时光有条目是不够的，总共多少条、当前第几页要一起带上，画面才能画出翻页。登录响应、错误响应也各自要定好形态。
| 动作 | 请求方式 | 地址示例 |
|---|---|---|
| 读列表 | GET | /api/posts |
| 读单条 | GET | /api/posts/12 |
| 新增 | POST | /api/posts |
| 修改 | PUT · PATCH | /api/posts/12 |
| 删除 | DELETE | /api/posts/12 |
交给智能体时先把这三件给它
定下这三件事，原本是为了和其他开发者协作。有规则，别人才不会靠猜来用你的 API。
交给智能体时同样有价值。不定下来的话，每次产出的形态都不一样。昨天的列表有 total，今天做的没有；错误格式每个画面都不同。那前端代码就会不停地晃。
所以把顺序换一下。在让它写代码之前，先把地址规则、动作划分、响应形态作为文档定好，然后再说按这份规格来做。
光把这三件放在前面，后面接上的代码就稳得多。下一篇看后端取值的地方，也就是数据库。