三种主流的Web服务实现方案（REST+SOAP+XML-RPC）

目前知道的三种主流的Web服务实现方案为：
REST：表象化状态转变 (软件架构风格）
SOAP：简单对象访问协议
XML-RPC：远程过程调用协议

下面分别作简单介绍：

REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

其实，RESTful是一种开发理念，是对http很好的诠释。维基百科说：REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。维基百科称其为“具象状态传输”（英文：Representational State Transfer，简称REST），我理解为“表现层状态转化”，是Roy Thomas Fielding博士于2000年在他的博士论文 “Architectural Styles and the Design of Network-based Software Architectures” 中提出来的一种万维网软件架构风格。

我们先来具体看下RESTful风格的url,比如我要查询商品信息，那么

非REST的url：http://.../queryGoods?id=1001&type=t01

REST的url: http://.../goods/1001

可以看出REST特点：url简洁，将参数通过url传到服务器，而传统的url比较啰嗦，而且现实中浏览器地址栏会拼接一大串字符，相必你们都见过吧。但是采用REST的风格就会好很多，现在很多的网站已经采用这种风格了，这也是潮流方向，典型的就是url的短化转换。

我认为理解RESTful的核心就是理解Representational State Transfer这三个单词的意思。

具象的，就是指表现层，也就是“资源”，什么是资源呢？网站就是资源共享的东西，客户端（浏览器）访问web服务器，所获取的就叫资源。比如html，txt，json，图片，视频等等。浏览器通过URI确定一个资源，但是如何确定它的具体表现形式呢？应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

状态转换，就是客户端和服务器互动的一个工程，在这个过程中产生了数据的状态的变化叫做状态转换。客户端访问必然使用HTTP协议，HTTP协议实际上含有4个表示操作方式的动词，分别是 GET,POST,PUT,DELETE,他们分别对应四种操作。GET用于获取资源，POST用于新建或者更新资源，PUT用于更新资源，DElETE用于删除资源。GET和POST是表单提交的两种基本方式，比较常见，而PUT和DElETE不太常用。而且HTTP协议是一种无状态协议，这样就必须把所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）

综合上面的解释，RESTful架构就是：

    每一个URI代表一种资源；

    客户端和服务器之间，传递这种资源的某种表现层；

    客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准，汲取了WWW的成功经验：无状态，以资源为中心，充分利用HTTP协议和URI协议，提供统一的接口定义，使得它作为一种设计Web服务的方法而变得流行。在某种意义上，通过强调URI和HTTP等早期Internet标准，REST是对大型应用程序服务器时代之前的Web方式的回归。目前Go对于REST的支持还是很简单的，通过实现自定义的路由规则，我们就可以为不同的method实现不同的handle，这样就实现了REST的架构。

上边说的是标准，但是实际开发中并没有全部实现标准，因为那样会增加开发成本。增加代码复杂度。我们就ssm框架例举一下restful风格的开发方法。

需求：RESTful方式实现商品信息查询，返回json数据

1.添加DispatcherServlet的rest配

//添加spring的servlet



springmvc-servlet-rest

org.springframework.web.servlet.DispatcherServlet



contextConfigLocation

classpath:spring/springmvc.xml





//映射路径



springmvc-servlet-rest

/

2.URL 模板模式映射

@RequestMapping("/Items/{id}")

public @ResponseBody Items(@PathVariable("id") String id,Model model) throws Exception{

//方法中使用@PathVariable获取id的值，使用model传回页面

//调用 service查询商品信息

ItemsCustom items = itemsService.findItemsById(id);

return items;

}

解释：@RequestMapping(value=”/ Items/{id}”)：{×××}占位符，请求的URL可以是“/Items/1”或“/Items/2”，通过在方法中使用@PathVariable获取{×××}中的×××变量。

@PathVariable用于将请求URL中的模板变量映射到功能处理方法的参数上。

如果RequestMapping中表示为”/Items/{id}”，id和形参名称一致，@PathVariable不用指定名称。

简单讲就是使用了两个注解@ResponseBody和@PathVariable，@ResponseBody指返回的数据，@PathVariable指传入的参数。@PathVariable将@RequestMapping(“/Items/{id}”)的占位符id的数据取出，放到形参中，处理完数据用@ResponseBody返回。其中spring框架都给我们定义好了，我们只需要明确指定传入参数是什么，返回 值是什么就行了，而指定方式就是两个注解。是不是很方便？这就大大简化了开发，提高了效率。

SOAP：简单对象访问协议（Simple Object Access Protocol）是一种标准化的通讯规范，主要用于Web服务（web service）中。用一个简单的例子来说明 SOAP 使用过程，一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。

XML-RPC：一个远程过程调用（remote procedure call，RPC)的分布式计算协议，通过XML将调用函数封装，并使用HTTP协议作为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

三种方案的简单比较

XML-RPC已慢慢的被SOAP所取代，现在很少采用了，但它还是有版权的，我在此就不作多介绍
成熟度上：SOAP在成熟度上优于REST

效率和易用性上：REST更胜一筹

安全性上：SOAP安全性高于REST，因为REST更关注的是效率和性能问题

总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景，正是那句老话：适合的才是最好的

同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。