什么是Web服务

你打开手机查天气，服务这个动作背后至少发生了三次Web服务调用。服务手机向气象服务商发请求，服务服务商从卫星数据源拉取云图，服务再把结果塞进你屏幕上的服务那个小方块里。整个过程没人手动操作，服务全是服务程序在对话。

Web服务本质上就是服务程序之间的对话方式。一个程序问，服务另一个程序答，服务通过HTTP协议传输，服务用XML或JSON格式交换数据。服务它不负责界面好不好看，服务只负责把数据从A搬到B。服务你看到的服务天气图标、温度数字，都是前端拿到数据后自己渲染的。

2000年前后，大家管这东西叫SOAP。微软和IBM推得很凶，XML层层包裹，信封套信封，一个简单查询能写出几十行标签。我翻过早期SOAP文档，光命名空间声明就占半屏。那会儿做企业集成的程序员，调试SOAP接口得用专门的嗅探工具，肉眼根本看不下去。后来REST风格起来了，简单直接，用URL定位资源，用HTTP动词表达操作。GET拿数据，POST创建，PUT更新，DELETE删除。同一个HTTP协议，浏览器用了几十年，程序员早就熟得不能再熟。

REST不是标准，是一套设计约束。Roy Fielding在博士论文里提的，核心就几条：无状态、统一接口、资源导向。无状态意味着每次请求都得带全信息，服务器不记你上次问了什么。这听起来麻烦，但换来了可伸缩性。服务器不用为每个用户维护会话，加机器就能扛流量。淘宝双十一那种量级，靠的就是这个。

实际开发中，纯REST很少见。多数API是混合体。GitHub的API用REST风格，但搜索接口又带查询参数。Stripe的支付API把REST和RPC混着用，创建退款用POST /v1/refunds，查询余额用GET /v1/balance。没人严格按论文来，能跑通就行。

JSON取代XML是必然的。JavaScript原生支持JSON解析，eval一下就行。XML得用DOM解析器，内存开销大，代码还啰嗦。2005年Ajax流行起来，前端工程师发现JSON传数据轻便太多。一个用户对象，XML写二十行，JSON三行搞定。现在除了银行和电信的老系统，新项目基本看不到SOAP了。

Web服务不限于公网。微服务架构里，订单服务调用库存服务，走的也是HTTP。Kubernetes集群内部，服务发现加负载均衡，底层还是Web服务那套东西。gRPC用HTTP/2做传输，Protocol Buffers做序列化，性能比JSON好，但调试起来麻烦。得装专门的工具才能看懂二进制流。

安全是个绕不开的坑。早期API很多裸奔，URL里带个api_key就完事。现在至少得走HTTPS，OAuth 2.0做授权。我见过一个内部系统，数据库连接字符串直接写在API响应里返回，测试环境无所谓，上线前忘了删。第二天就被扫端口的人发现了。

写Web服务不难，写好很难。版本管理、错误码设计、限流策略、文档维护，每样都得花心思。Stripe的API文档被当成行业标杆，因为他们把错误信息写得像人话。参数错了告诉你哪个字段错了，为什么错，怎么改。多数公司的API返回个500，日志里翻半天才知道是空指针。

下次你点外卖，从选餐到支付到骑手接单，背后至少跑了十几个Web服务。它们互相不认识，但通过HTTP和JSON把事办成了。这大概就是Web服务最实在的价值——让不同语言、不同团队、不同公司写的程序，能凑在一起干活。