Web service概述
Web service是一种可以跨网络访问的服务，例如通过全球互联网访问。通常，这些Web服务及其客户端通过HTTP等网络协议进行通信。
术语“web服务”经常用来描述一个客户端（计算机）可通过互联网进行远程调用一个服务，通过诸如HTTP的Web协议。比如调用不同机器上的一个方法、过程或函数。因此Web服务非常类似于是“远程过程调用”（或只是“远程”）协议。比如java的RMI，Windows DCOM，CORBA的IIOP等。这些Web服务的原理如下图所示：
(一个客户端通过互联网调用Web服务）
web服务还可以使用在内部的网络，作为许多不同的应用程序能够与彼此交互的方式。标准化的Web服务协议，使得各种应用程序集成更加容易。这一原则如下图：
(通过web服务通信的各个独立的应用）
web服务与web站点（web应用）
web服务和web站点之间的主要区别是：web站点主要是用来供人使用（人机交互），而web服务通常用于计算机到计算机的交互。
当然，这种区分是有点模糊。 Web应用程序可以包含一个图形用户接口提供给人类用户，而一组web服务是提供给计算机“用户”（客户端）。例如：像Paypal支付服务既有提供给人的图形化用户界面，也有一组通过后端系统访问Web支付服务。
此图显示的是一个图形用户界面，和一个Web服务接口（一组Web服务暴露出Web应用程序中需要的功能）的Web应用程序：
（包含GUI人机交互和web服务的web应用）
Web服务消息交换模式
有多种类型的web服务。某些Web服务 被客户端调用，以获取一些信息。 例如，客户端可以调用天气Web服务来获取天气信息。 这些都是典型的只读的Web服务。实际上，只读的Web服务可能发送一个空请求到Web服务器，然后将数据返回。所以，即使一个Web服务是只读的，客户端也会发送一些数据（最小请求）到Web服务器来获得它要读取的数据。
还有只写的web服务，例如，你可能会定期转移一些数据到web服务器。其他的是读写的web服务，它需要发送一些数据到web服务，然后再接收返回的数据。这三种通讯模式如下图：
（Web服务的三种消息交换模式：只读，只写和读/写）
Web Service 消息格式
当客户端和Web Service服务器进行通信时，他们交换消息。客户端发送请求消息到Web Service服务器。 Web Service服务器响应并返回消息。这就像普通的HTTP，浏览器发送一个HTTP请求到Web服务器， Web服务器会提供一个HTTP响应。
最初唯一可用的Web Service消息格式是SOAP，后来出现了REST式的Web Service，它采用纯XML和HTTP。随着REST的兴起，出现了很多人使用JSON（JavaScript对象符号）作为消息格式。另外一个很简单的远程协议被称为XML-RPC（XML远程过程调用）。 对最常见的是SOAP协议我不会在这里详述消息格式细节，因为在后续的教程中会提到。在这里，我只是简单提一下。
客户端发送请求到web服务，并且接收web服务的响应
SOAP
SOAP（简单对象访问协议）是基于XML的消息格式。下面是一个简单的SOAP消息：
<span style="font-size:14px;"><?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> </soap:Header> <soap:Body> ... message data ... <soap:Fault> </soap:Fault> </soap:Body> </soap:Envelope></span>
正如你可以看到一个SOAP消息包括：
Envelope
Header
Body
Message Data
Fault (optional)
相同的SOAP消息结构用于客户端和Web Service服务器之间的请求和响应。
Body内的Fault元素是可选的。只有Web服务中发生内部错误里才返回。否则，返回正常信息数据。
SOAP不指定一个消息从客户端如何获取到Web Service，但最常见的情况是通过HTTP。
REST + XML
REST（具象状态传输）Web服务与SOAP Web服务有一点不同。一个REST请求就像一个普通的浏览器发送一个简单的HTTP请求到Web服务器。一般情况不发送XML请求。一个REST响应通常在一个普通的HTTP响应中发送回一个XML文档，就像浏览器请求一样。在REST中，你不用太多关注“服务”方面，而是在“资源”。一个资源有一个给定的URL，就像在一个网站的HTML页面。比如社交应用中一个用户的基本信息资源，可能是下面的网址：
http://social.jenkov.com/profiles/jakobjenkov
这个URL可能会返回一个XML文档（资源）描述了我。 返回的XML文件会是下面这样：
<span style="font-size:14px;"><profile> <firstName>Jakob</firstName> <lastName>Jenkov</lastName> <address> <street>The Road 123</street> <zip>12345</zip> <city>Copenhagen</city> </address> </profile></span>
REST也自然地支持资源的集合。举例来说，这个URL可能代表所有的公共用户配置文件的列表：
<span style="font-size:14px;">http://social.jenkov.com/profiles/ 下面是这样的XML配置文件列表的一个例子：</span>
<span style="font-size:14px;"><profiles>
<profile>...</profile>
<profile>...</profile>
<profile>...</profile>
</profiles></span>
上面这两个网址只能读取一个资源或资源集合。如果您需要修改REST中的资源，您需要发送不同的HTTP请求到服务器。当你读一个资源要发送HTTP GET请求。如果你需要写一个资源，就需要发送一个HTTP PUT来代替。如果你需要删除一个资源，需要发送一个HTTP DELETE等。
REST + JSON
REST+ JSON跟REST + XML基本上是一样的，只不过传输的数据是JSON（JavaScript对象符号）格式的。JSON的基于XML的优点是Web浏览器能够自然地解析JSON结构并且转换成JavaScript对象，不需要自己在浏览器中转换。这使得许多使用AJAX的应用程序变得简单。
下面是一个json的例子：
{
firstName : "Jakob",
lastName : "Jenkov",
address : {
street : "The Road 123",
zip : "12345",
city : "Copenhagen"
}
}
XML RPC
相比REST，XML RPC更类似于SOAP，XML RPC的请求和响应都是一样的格式，相比SOAP ，XML RPC是一种较为简单的协议，它很接近标准过程调用的建模。有些人声称，XML RPC现在已死或过时。
下面是一个XML RPC的请求示例：
POST /RPC2 HTTP/1.0 User-Agent: My XML-RPC API/1.0.0 (Win7) Host: jenkov.com Content-Type: text/xml Content-length: 200 <?xml version="1.0"?> <methodCall> <methodName>getProfile</methodName> <params> <param> <value><string>Jakob Jenkov</string></value> </param> </params> </methodCall>
标注：这个HTTP请求的Content-Length头没有正确设置，它应该是XML请求的字节数。
下面是一个XML RPC响应示例：
HTTP/1.1 200 OK Connection: close Content-Length: 213 Content-Type: text/xml Date: Wed, 03 Feb 2010 20:00:00 GMT+1 Server: jenkov.com <?xml version="1.0"?> <methodResponse> <params> <param> <struct> <member> <name>firstName</name> <value>Jakob</value> </member> <member> <name>lastName</name> <value>Jenkov</value> </member> <member> <name>address</name> <value> <struct>...</struct> </value> </member> </struct> </param> </params> </methodResponse>
Web 服务接口
假设一个web服务可以被外面的客户端调用了，那么客户端就需要一个对接口的描述，除了接口的描述，如何知道要发送的数据是什么格式呢？ 你可以把服务想像成java或者c#的接口，唯一需要的额外信息是该服务的位置（IP地址）和该服务的消息格式，下面是一个服务描述应该包含的信息：
接口名称
操作名称（如果服务包含多个操作的话）
输入参数
返回值
服务消息格式
服务地址（IP或者URL）
如何描述一个Web服务接口取决于服务所使用的消息格式。 目前，只有SOAP Web服务有一个标准化的接口描述 – Web服务描述语言（WSDL）。
更多参考：WebService学习总结