web服务技术

打开浏览器，输入网址，敲下回车——几毫秒内，你看到了网页。这背后，是Web服务技术在跑接力。它不是单一技术，而是一套协作机制：客户端发请求，服务器处理并返回响应。核心协议是HTTP，一个无状态的请求-响应模型。每次点击，都是一次独立的对话，服务器不记得你上一次说了什么。为了记住状态，Cookie和Session被发明出来，像给对话贴标签。

我最早接触Web服务，是帮朋友调试一个天气查询接口。他用Python写了个脚本，向某个公开API发GET请求，结果返回一堆乱码。问题出在编码上——服务器返回的是GBK，他按UTF-8解析。这让我意识到，Web服务不只是“能通就行”，细节决定成败。HTTP头部里的Content-Type、字符集、缓存控制，每一个字段都可能让程序崩溃。后来我用Postman测试，发现那个API其实支持JSON格式，只要在请求头里加上Accept: application/json。改一行代码，问题解决。

Web服务的架构风格主要有两种：REST和SOAP。REST用HTTP动词（GET、POST、PUT、DELETE）操作资源，URL即资源标识。比如GET /users/123获取用户信息，DELETE /users/123删除。SOAP则基于XML，协议重，但支持事务和安全扩展。现在多数互联网公司选REST，因为轻量、易调试。不过银行、电信系统里，SOAP仍有地盘——它那套WS-Security不是白写的。

实际开发中，跨域是个绕不开的坑。浏览器同源策略阻止不同域名间的AJAX请求。解决方案有CORS（服务器加Access-Control-Allow-Origin头）、JSONP（只支持GET，老土但有效）、反向代理（Nginx转发）。我见过一个团队用JSONP调内部API，结果因为回调函数名冲突，页面白屏。后来改CORS，十分钟搞定。技术选型别恋旧，该换就换。

性能方面，缓存是头号功臣。HTTP缓存分强缓存（Cache-Control、Expires）和协商缓存（ETag、Last-Modified）。强缓存直接读本地，不发请求；协商缓存会问服务器“资源变了吗”，没变就返回304。合理设置缓存，能省下大量带宽。另一个是压缩，Gzip或Brotli压缩响应体，文本类资源能压到30%以下。图片则用WebP，比JPEG小三成。这些优化不复杂，但效果立竿见影。

安全不能事后补。常见问题：SQL注入、XSS、CSRF。SQL注入靠参数化查询防；XSS靠转义输出和CSP（内容安全策略）；CSRF靠Token校验。HTTPS是底线，现在Let's Encrypt免费证书，没理由不上。我见过一个电商网站，登录接口用HTTP明文传密码，被抓包直接泄露。修起来不难，但用户信任丢了就难找回。

Web服务技术还在进化。HTTP/2支持多路复用，一个连接跑多个请求；HTTP/3基于QUIC，用UDP减少延迟。gRPC用Protobuf做序列化，比JSON快，适合微服务内部通信。GraphQL让客户端指定要哪些字段，避免过度获取。这些新东西不是噱头，是实打实解决老问题的。比如GraphQL，移动端弱网下少传几个字段，体验就上来了。

写代码时，别把Web服务当黑盒。抓包看看请求响应，用curl测测接口，读读RFC文档。HTTP/1.1的RFC 7230系列，虽然枯燥，但能解释很多“玄学”问题。比如为什么有时候POST要加Content-Length，有时候用Transfer-Encoding: chunked。懂了原理，调试不慌。

最后说个观察：很多团队把Web服务当“胶水”，随便糊。结果接口没版本控制，改字段不通知，错误码乱返回。好的Web服务设计，URL要语义化，状态码要准确（200成功，400客户端错，500服务端错），错误信息要具体。别返回“系统错误”，写清楚“用户ID格式不对”。这省的是未来调试的时间。