把它想成一张给程序看的菜单
你在天气应用里选城市，应用可能向天气服务请求数据。服务约定需要城市编号和日期，返回温度、天气状况等字段。应用按约定发出请求，就不用自己收集全部气象数据。
菜单的比喻强调的是“可调用的功能和规则”。你不必进入厨房完成烹饪，调用方也不必知道对方内部如何实现。但参数格式、权限和错误处理都得遵守约定。
程序之间，怎样点单和拿结果
- 01请求
传入约定的信息
- 02返回
由应用决定怎样展示
网络API示例；API也可以存在于本地软件内部。
同一份天气数据，可以出现在不同应用里
假设天气服务约定：发来城市编号，就返回温度和天气状况。旅行应用拿到这些数据，可以做成穿衣提醒；日历应用可以把它放到当天的行程旁。它们共用取数据的方式，却不用长成同一张页面，也不用各自建一套气象观测网。
这里有两层界面：屏幕上的城市按钮给人点，按钮背后的API给程序调用。API也不是整间厨房的钥匙，只开放规定的能力；“查天气”的接口不会因此允许调用者修改气象数据库。开发者说“接入某服务的API”，通常就是按它的说明传入必要信息，处理返回结果，并把功能接进自己的应用。
接口不一定是一个网址
常见的网络API通过HTTP通信，看起来像请求一个地址。但操作系统、浏览器或软件库提供的函数，也可以是API，不一定涉及互联网。
例如浏览器让网页申请摄像头权限并读取视频，也是通过规定的接口。接口是否对公众开放，是否收费，是否需要密钥，都是另外的设计问题。
调用成功，不等于结果永远相同
服务可能限流、超时、拒绝权限不足的请求，或者升级版本改变字段。调用者需要处理失败，而不是假定按一次按钮总能成功。
缓存可以减少重复请求，但有些数据需要最新结果，不能无限期保存旧答案。因此，按约定发出了请求，还要看服务是否可用、有没有权限以及返回了什么。