后端
应用程序接口API
你可能会问
应用程序接口到底是什么？大家天天说「调 API」，到底在调什么？
简单来说
让前端、后端或第三方服务按照约定交换数据和调用能力的接口。
照约定点单
GET/weather
city"上海"
照约定上菜，前端拿来就用
01 · 先这样理解
把抽象概念放进真实场景
让前端、后端或第三方服务按照约定交换数据和调用能力的接口。
换个角度想API 像餐厅的菜单：你不进后厨，也不用知道菜怎么做——照着菜单点、按约定付钱，后厨就按约定上菜。菜单上没有的，你点不了。
02 · 点击演示
调一次天气 API，会发生什么？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 双方的约定
路径GET /weather参数city返回{ temp, sky } GET /weather?city=上海
照约定发出
{
"temp": 25,
"sky": "晴"
}
按约定的格式返回- 字段名和约定一致，数据到手约定里没有 temperature 这个字段——九成的接口 bug 长这样
取
1 / 4
Contract · 约定路径、参数和返回格式
03 · 放进真实任务
什么时候会遇到它
前后端分工
前端管界面、后端管数据，中间全靠 API 说话。
借用外部能力
天气、支付、AI 模型——都是在调别人家的 API。
排查对不上
前端说传了、后端说没收到？先对照约定查字段名和路径。
04 · 想一想
用一个问题检查理解
AI 帮你接入了天气 API，页面却一直显示不出温度。你会先检查什么？
查看答案
打开开发者工具看这次请求：路径和参数对不对、返回的是 200 还是报错、返回 JSON 里的字段名和代码里取的是否一致——API 出问题，九成是两边没按同一份约定办事。
最容易踩的坑
API 是承诺：改字段名、改路径就是毁约，所有调用方一起坏。要改就发新版本（/v2），旧版先留着。