如果世界上所有的程序都使用同一个平台，同一个组件模型，同一个编程语言编写，比如基于单一的Windows平台，运用COM组件模型以及使用.NET语言程序设计。那么就没有Web Services什么事了。从这个角度说，Web Services技术的出现，正是为了解决跨平台，跨语言这些异构环境下的程序互操作问题。

　　那么，到底什么是Web Services呢？先举个例子吧。 我们看到很多的Web应用程序都提供了谷歌地图功能。用户只输入起点与终点，就能找到乘车路线，无论是自驾、公交、还是地铁。那么这是不是意味着Web应用程序开发者需要去开发谷歌地图的程序呢?很显然，理论上可行，现实中，还是拿来主意比较好，谁愿意重复发明轮子呢?就意味着，谷歌地图功能必须是一个可被其它程序调用的Web API，这样，这样，其它 Web应用程序才能够调用谷歌地图功能。那么，我们称谷歌地图功能就是Web Services。因此，简单来说，Web Services 就是一个应用程序，向外界暴露出一个能够通过Web调用的API。这样一来，你能够运用编程手段通过Web来调用这个应用程序。

　　确切地说，Web Services 是一种基于组件的软件平台，是面向服务的Internet 应用。Web Services 框架的核心技术包括SOAP ,WSDL 和UDDI ,它们都是以标准的XML 文档的形式表示。

　　SOAP (“Simple Object Access Protocol”的缩写)是Web Services 的通信协议。SOAP是一种简单的、轻量级的基于XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP包括三部分:一个定义描述消息内容的框架的信封，一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用和响应的约定。

　　1. 传递信息的格式为XML.这就使Web Services能够在任何平台上，用任何语言进行实现。

　　2. 远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。

　　3. 参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。

　　WSDL表示WEB服务说明语言。WSDL文件是一个XML 文档，用于说明一组SOAP消息以及如何交换这些消息。当实现了某种服务的时候(如：股票查询服务)，为了让别的程序调用，必须告诉大家服务接口。例如：服务名称，服务所在的机器名称，监听端口号，传递参数的类型，个数和顺序，返回结果的类型等等。这样别的应用程序才能调用该服务。WSDL协议就是规定了有关Web Services描述的标准。

　　UDDI(“Universal Description， Discovery，and Integration”的缩写)提供一种发布和查找服务描述的方法。UDDI 数据实体提供对定义业务和服务信息的支持。WSDL 中定义的服务描述信息是UDDI注册中心信息的补充。

　　XML(“eXtensible Markup Language”的缩写)是Internet上数据表示和数据交换的新标准。它是ISO(“International Organization for Standardization”的缩写，国际标准化组织)的SGML(“Standard for General Markup Language”的缩写，通用标记语言标准)的一个简化子集。XML关注信息本身，是Web上表示结构化信息的一种标准文本格式。

　　Web Services的工作原理如下：

　　1. Web Services 服务提供方通过WSDL描述所提供的服务，并将这一描述告知Web Services 注册服务器。

　　2. 注册服务器依据WSDL 的描述，依照UDDI的协定更新服务目录并在Internet 上发布。

　　3. 用户在使用Web Services 前先向注册服务器发出请求，获得Web Services 提供者的地址和服务接口信息。

　　4. 使用SOAP 协议与Web Services 提供者建立连接,进行通信。

　　通常我们提到Web Services第一想法就是SOAP消息在各种传输协议上交互。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，但是随着SOAP作为Web Services的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在大并发情况下会有性能问题，在互联网上使用不太普及，因此并不太适合Web 2.0网站服务使用，目前大量的Web 2.0网站使用另外一种解决方案——REST。

　　作为SOAP模式的替代者，REST(是“Representational State Transfer”的缩写)是一种轻量级的Web Services架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。

　　REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数(例如编码，错误码等)都置之不顾。

　　举个例子吧，HTTP GET 请求中的请求 URI 中的查询字符串包括一组参数，这些参数定义服务器用于查找一组匹配资源的搜索条件。但是在许多情况下，不优雅的 Web API 使用 HTTP GET 来触发服务器上的事务性操作——例如，向数据库添加记录。如：

　　GET /adduser?name=John HTTP/1.1

　　这不是非常好的设计，因为上面的 Web 方法支持通过 HTTP GET 进行状态更改操作。Web 服务器旨在通过检索与请求 URI 中的查询条件匹配的资源，并在响应中返回这些资源或其表示形式，从而响应 HTTP GET 请求，而不是向数据库添加记录。以这种方式使用 GET 是不一致的。

　　REST架构遵循了CRUD原则：CRUD原则对于资源只需要四种行为：Create(创建)、Read(读取)、Update(更新)和Delete(删除)就可以完成对其操作和处理。REST 要求开发人员显式地使用 HTTP 方法，并且使用方式与协议定义一致。这个基本 REST CRUD操作与 HTTP 方法之间的一对一映射如下：

　　如果要在服务器上创建资源，应该使用 POST 方法。

　　如果要检索某个资源，应该使用 GET 方法。

　　如果要更改资源状态或对其进行更新，应该使用 PUT 方法。

　　如果要删除某个资源，应该使用 DELETE 方法。

　　除了抽象操作为基础的CRUD。所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。

　　我们看一下REST与SOAP的对比：

　　先说成熟度，SOAP发展到现在虽然已经背离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的Web Services都能够较好的互通。

　　反观REST，相比于SOAP的权威性协议规范，REST实现的各种协议只能算是私有协议，当然需要遵循REST的思想，在兼容性方面会差很多。

　　总的来说SOAP在成熟度上优于REST。

　　再说效率，SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础。REST被人们的重视，其实很大原因是源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了HTTP最初的应用协议设计理念。

　　同时， REST还很好的融合Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有JSON，RSS，等形式。

　　因此，相对于SOAP， REST的效率更胜一筹。

　　最后说安全性，SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持。 REST没有任何规范对于安全方面作说明。