web接口是什么

你打开手机点外卖，点了份黄焖鸡米饭。这个动作背后，你的手机正在和美团服务器说一句话：“给我一份黄焖鸡米饭的订单，送到这个地址。”服务器回了一句：“收到，骑手20分钟后到。”这一问一答，就是web接口在干活。

说白了，web接口就是两个程序之间约定好的对话方式。一个程序问，另一个程序答。问什么、怎么问、答什么、怎么答，全都提前定好了规矩。这个规矩，就是接口。

拿最常见的场景来说。你在浏览器里输入网址，按下回车，浏览器向服务器发了一个请求。服务器收到后，把网页内容打包扔回来，浏览器再渲染成你看到的页面。这一整套流程里，浏览器和服务器之间传递数据的那个通道，就是web接口。它不负责好看不好看，只负责把数据从A搬到B，再从B搬回A。

很多人会把web接口和网页混在一起。网页是给人看的，接口是给程序看的。你刷抖音，视频一条条滑出来，背后是APP在不停调用接口拉取新视频数据。你看到的画面是结果，接口是那个跑腿的。它不生产数据，只做数据的搬运工。

接口长什么样？最常见的一种叫RESTful API。它的工作方式很像点菜。你告诉服务员“我要一份宫保鸡丁”，服务员传给厨房，厨房做好端出来。对应到接口上，你发一个GET请求到某个地址，比如 /api/user/123，服务器就返回ID为123的用户信息。你想改用户名字，就发一个PUT请求，带上新名字。想删掉这个用户，发DELETE。这套动作干净利落，每个请求对应一个明确的操作。

还有一种叫GraphQL。它跟RESTful不一样。RESTful是你去餐厅，菜单上写什么你点什么。GraphQL是你直接跟厨师说：“我要宫保鸡丁里的鸡丁，不要花生，再加一勺辣。”厨师就按你说的做。好处是你一次就能拿到想要的所有数据，不用跑好几趟。坏处是厨师得听懂你那些细碎的要求，实现起来更费劲。

接口的地址通常长这样：https://api.example.com/v1/orders。拆开看，https是协议，api.example.com是服务器地址，/v1/orders是路径。路径告诉你你要操作什么资源。v1表示版本，万一以后改了规矩，老版本还能继续用，不至于把老用户全摔下车。

数据格式上，现在绝大多数接口都用JSON。它长得像JavaScript里的对象，键值对排列，人也能读，机器也能解。比如一个用户信息返回过来是这样：

{  "id": 123, "name": "张三", "email": "zhangsan@example.com" }

早些年XML也流行过，但写起来啰嗦，一个简单数据要套好几层标签。JSON胜在轻，传得快，看着也清爽。

接口调用不是每次都能成功。你请求一个不存在的用户，服务器不能装死。它会返回一个状态码。200表示一切正常，404表示你要的东西没找到，500表示服务器自己崩了。这些数字是接口之间的暗号，程序员一看就知道问题出在哪一层。

我见过不少人把接口文档写得像天书。参数名用拼音缩写，返回值不写类型，错误码只有一句“出错了”。这种接口，谁调谁骂人。好的接口文档应该像菜谱：需要什么食材，几步做完，火候多少，写得明明白白。不然对接的人只能靠猜，猜错了就甩锅。

安全也是接口绕不开的事。你不能让谁都能调你的接口删数据。常见的做法是发一个token，每次请求带上它，服务器验证通过才干活。token就像进小区刷的门禁卡，没卡进不去。但卡也不能一直有效，过期了就得重新申请。不然被人捡到，你家就被搬空了。

说到底，web接口就是程序世界的传话游戏。一端说，一端听，中间不能传错话。传错了，轻则页面报错，重则数据乱套。写接口的人得想清楚：别人会怎么问，问错了怎么答，答的时候给多少信息。这些想明白了，接口就好用了。