webservice是什么协议

WebService不是“一个”协议。它更像一个技术家族，什协里面塞了好几种协议，什协各干各的什协活儿。你如果只盯着一个标准看，什协很容易被绕晕。什协我第一次接触它的什协时候，以为就是什协HTTP加XML，结果发现SOAP、什协WSDL、什协UDDI全冒出来了，什协头大。什协

最核心的什协那个叫SOAP——简单对象访问协议。名字听着挺朴素，什协实际上它是什协一套基于XML的消息格式规范。你发一个请求，得包一层Envelope，里面塞Header和Body，跟寄快递要填单子一样。SOAP本身不绑定传输层，你可以用HTTP，也可以用SMTP，甚至TCP。但绝大多数人只用HTTP，因为防火墙放行方便。有个做银行接口的老哥跟我说，他们内部系统还在用SOAP over JMS，稳得一批，但调试起来能让人摔键盘。

光有SOAP还不够，服务怎么描述？靠WSDL。这玩意儿是WebService的“说明书”，用XML写清楚：服务叫什么、在哪个地址、有哪些方法、参数什么类型、返回什么结构。没有WSDL，客户端根本不知道该怎么调。以前用Axis2生成客户端代码，对着WSDL跑一下，一堆Java类就出来了。方便是真方便，但WSDL文件一旦写错一个命名空间，整个调用链全崩，报错信息还特别抽象。

还有UDDI，统一描述、发现和集成。理论上是个全球目录，企业把服务注册上去，别人就能搜到。现实里几乎没人用。为什么？太理想化了。跨企业的服务发现涉及信任、安全、治理，不是技术能解决的。我见过唯一用UDDI的场景是某大型制造企业的内网，用来管理几十个内部服务，但也只是当个静态注册表用，跟“全球发现”没半毛钱关系。

那WebService到底算什么协议？严格说，它是一组协议的集合：SOAP管消息格式，WSDL管服务描述，UDDI管注册发现，WS-Security管安全，WS-Addressing管路由……这些标准由W3C和OASIS制定，堆在一起才能跑通一个完整的“服务调用”。你单独拿SOAP出来，它只是消息协议；单独拿WSDL，它只是描述语言。合起来才叫WebService技术栈。

我见过一个典型的翻车案例。某电商早期把订单查询做成SOAP服务，WSDL里定义了一个getOrderStatus方法。后来业务加了个“批量查询”，开发直接在原方法上改参数，把单个orderId改成数组。结果老客户端传单个字符串，服务端解析失败，日志里全是Unmarshalling Error。他们忘了WSDL是契约，改契约就得版本化。这事跟协议本身没关系，是人的问题。但SOAP的严格模式放大了这种错误——XML Schema校验一板一眼，错一个标签就拒收。

REST这边就松散多了。同一个查询，用GET /orders/123和GET /orders?ids=1,2,3都行，返回JSON，客户端自己解析。没有WSDL，靠OpenAPI（Swagger）写文档。协议约束少，开发快，但不同团队写出来的接口风格能差出十万八千里。有人把所有操作都塞进POST，有人用PUT做部分更新，还有人拿DELETE当查询用——看着血压高。

所以回答“WebService是什么协议”，得看语境。面试官问这个，大概率想听SOAP、WSDL、UDDI三件套。实际工作中，你更可能用RESTful API，或者gRPC。WebService这个词本身已经有点过时了，像“信息高速公路”一样，带着上世纪的味道。但它背后的思想——服务契约、跨平台调用、松耦合——一点没过时，只是换了身衣服继续跑。

最后说个冷知识：SOAP 1.2 的规范里，其实允许用非XML的序列化？不，我记错了。SOAP 1.2 依然强制XML infoset。但SOAP 1.1 和 1.2 的HTTP绑定不一样，1.1用SOAPAction头，1.2改用Content-Type参数。这种细节坑过不少人。你要是维护老系统，翻出WSDL看一眼soap:binding的transport属性，是http://schemas.xmlsoap.org/soap/http还是http://www.w3.org/2003/05/soap/bindings/HTTP/，能直接判断版本。别问我怎么知道的，都是泪。