RESTful WebService和web service的区别

 

RESTful 风格的 webservice 越来越流行了， sun 也推出了 RESTful WebService 的官方规范： JAX-RS ，全称：

Java API for RESTful WebService。该规范定义了一系列的注解

 

RESTful 简化了 web service 的设计，它不再需要 wsdl ，也不再需要 soap 协议，而是通过最简单的 http 协议传输数据 ( 包括 xml 或 json) 。既简化了设计，也减少了网络传输量（因为只传输代表数据的 xml 或 json ，没有额外的 xml 包装）。

下面为大家介绍使用 cxf 开发 RESTful WebService

Cxf2.7 实现了大部分的 jax -rs 规范，从 cxf3.0 开始实现 jax-rs 的全套规范

 

服务端

Spring3 +cxf 开发 RESTfulweb service

服务端 jar 包



上面的 jettison jar 包是用来将 jaxb 扩展为为 json 支持的 jar

实体类

package com.tgb.cxf.server;

import javax.xml.bind.annotation.XmlRootElement;

//一定要使用XmlRootElement注解进行标注
@XmlRootElement(name="user")
public class User {
  
  private String id;
  private String name;
  
  public String getId() {
    return id;
  }
  public void setId(String id) {
    this.id = id;
  }
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
  
} com.tgb.cxf.server;

import javax.xml.bind.annotation.XmlRootElement;

//一定要使用XmlRootElement注解进行标注
@XmlRootElement(name="user")
public class User {
  
  private String id;
  private String name;
  
  public String getId() {
    return id;
  }
  public void setId(String id) {
    this.id = id;
  }
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
  
}

WebService 接口

@Path("/userservice/")
public interface IMyService {
  
  @Path("/addUser/")
  @POST
  Response addUser(User user);
  
  @Path("/delUser/{id}/")
  @DELETE
  Response delUser(@PathParam("id") String id);
  
  @Path("/updateUser/")
  @PUT
  Response updateUser(User user);
  
  @Path("/getUserById/{id}/")
  @GET
  @Produces("application/json")//返回json数据格式
  User getUserById(@PathParam("id") String id);
  
  @Path("/")
  @GET
  @Produces("application/json")//返回json数据格式
  List<User> findAllUsers();
}("/userservice/")
public interface IMyService {
  
  @Path("/addUser/")
  @POST
  Response addUser(User user);
  
  @Path("/delUser/{id}/")
  @DELETE
  Response delUser(@PathParam("id") String id);
  
  @Path("/updateUser/")
  @PUT
  Response updateUser(User user);
  
  @Path("/getUserById/{id}/")
  @GET
  @Produces("application/json")//返回json数据格式
  User getUserById(@PathParam("id") String id);
  
  @Path("/")
  @GET
  @Produces("application/json")//返回json数据格式
  List<User> findAllUsers();
}

WebService 实现类

public class MyServiceImpl implements IMyService {

  private HashMap<String, User> users = new HashMap<String,User>();
  
  public MyServiceImpl(){
    init();
  }
  
  public Response addUser(User user) {

    users.put(user.getId(), user);
    System.out.println("添加用户成功");
    System.out.println(users.size());
    System.out.println(users.get("2").getName());
    return Response.ok().build();
  }


  public Response delUser(String id) {
    users.remove(id);
    System.out.println(users.size());
    return Response.ok().build();
  }


  public Response updateUser(User user) {
    users.put(user.getId(), user);
    System.out.println(users.get("1").getName());
    return Response.ok().build();
  }


  public User getUserById(String id) {
    return users.get(id);
  }
  
  
  
  private void init(){
    User user = new User();
    user.setId("1");
    user.setName("温欢");
    users.put(user.getId(), user);
  }

  
  public List<User> findAllUsers() {
    List<User> userlist = new ArrayList<User>();
    userlist.add(users.get("1"));
    return userlist;
  }

} class MyServiceImpl implements IMyService {

  private HashMap<String, User> users = new HashMap<String,User>();
  
  public MyServiceImpl(){
    init();
  }
  
  public Response addUser(User user) {

    users.put(user.getId(), user);
    System.out.println("添加用户成功");
    System.out.println(users.size());
    System.out.println(users.get("2").getName());
    return Response.ok().build();
  }


  public Response delUser(String id) {
    users.remove(id);
    System.out.println(users.size());
    return Response.ok().build();
  }


  public Response updateUser(User user) {
    users.put(user.getId(), user);
    System.out.println(users.get("1").getName());
    return Response.ok().build();
  }


  public User getUserById(String id) {
    return users.get(id);
  }
  
  
  
  private void init(){
    User user = new User();
    user.setId("1");
    user.setName("温欢");
    users.put(user.getId(), user);
  }

  
  public List<User> findAllUsers() {
    List<User> userlist = new ArrayList<User>();
    userlist.add(users.get("1"));
    return userlist;
  }

}

spring -cxf.xml配置文件

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:jaxrs="http://cxf.apache.org/jaxrs"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd">
  
  <!-- 
      
      注意这里的jaxrs命名空间需要大家手动添加 
      
  -->
  
  <!-- 发布webservice -->
  <bean id="serviceBean" class="com.tgb.cxf.server.MyServiceImpl"/>
  <jaxrs:server id="userService"  address="/myservice">
    <jaxrs:serviceBeans>
      <ref bean="serviceBean"/>
    </jaxrs:serviceBeans>
  </jaxrs:server>
  
</beans>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:jaxrs="http://cxf.apache.org/jaxrs"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd">
  
  <!-- 
      
      注意这里的jaxrs命名空间需要大家手动添加 
      
  -->
  
  <!-- 发布webservice -->
  <bean id="serviceBean" class="com.tgb.cxf.server.MyServiceImpl"/>
  <jaxrs:server id="userService"  address="/myservice">
    <jaxrs:serviceBeans>
      <ref bean="serviceBean"/>
    </jaxrs:serviceBeans>
  </jaxrs:server>
  
</beans>

web.xml 文件配置

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  
  <!-- 配置spring -->
  <context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>classpath:config/spring-cxf.xml</param-value>
  </context-param>
  
  <listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  
  <!-- 配置cxf servlet -->
  <servlet>
        <servlet-name>cxf</servlet-name>
        <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>cxf</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>

</web-app>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  
  <!-- 配置spring -->
  <context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>classpath:config/spring-cxf.xml</param-value>
  </context-param>
  
  <listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  
  <!-- 配置cxf servlet -->
  <servlet>
        <servlet-name>cxf</servlet-name>
        <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>cxf</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>

</web-app>

 

客户端

所需 jar 包



因为 RESTful 就是利用最原始的 http 协议传输数据，所以客户端其实就是一个 http客户端，有以下几种实现方式

JAX-RS Client API --cxf3.0+

Proxy 【使用起来简单，代理封装通信细节】

Apache HttpClient

WebClient

为了简单我使用了 Proxy 方式

代码如下

public class MyClient {
  
    /** @MethodName	: main
     * @Description	: JaxRs测试客户端
     * @param args
     */
    public static void main(String[] args) {
      IMyService myService = JAXRSClientFactory.create("http://localhost:8096/cxf02/services/myservice",IMyService.class);
      
      User user = myService.getUserById("1");
      System.out.println(user.getName());
      
      User user = new User();
      user.setId("2");
      user.setName("委座");
      myService.addUser(user);
      
      /*User user = new User();
      user.setId("1");
      user.setName("123");
      myService.updateUser(user);*/
      
      
      myService.delUser("1");
      
      System.out.println(myService.findAllUsers().get(0).getName());
    }
  
  } class MyClient {
  
    /** @MethodName	: main
     * @Description	: JaxRs测试客户端
     * @param args
     */
    public static void main(String[] args) {
      IMyService myService = JAXRSClientFactory.create("http://localhost:8096/cxf02/services/myservice",IMyService.class);
      
      User user = myService.getUserById("1");
      System.out.println(user.getName());
      
      User user = new User();
      user.setId("2");
      user.setName("委座");
      myService.addUser(user);
      
      /*User user = new User();
      user.setId("1");
      user.setName("123");
      myService.updateUser(user);*/
      
      
      myService.delUser("1");
      
      System.out.println(myService.findAllUsers().get(0).getName());
    }
  
  }

大家可以使用 TCPMON 这个工具监控以下，可以看到 http body 中只是简单的 json串，没有像 soap 协议那样的“信封”包装

使用 RESTful 设计风格 + 传输 json 数据格式 可以大大的简化 web service 的设计并提高传输效率

 

其实springMVC也采用了RESTful的设计风格，不过它使用的是spring自己的注解，这些注解和jax-rs中的注解惊奇的类似。如果大家有兴趣可以研究一下springMVC的RESTful特性。

以下内容为转载，原文链接：http://blog.sina.com.cn/s/blog_493a845501012566.html
REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：

1.网络上的所有事物都可以被抽象为资源(resource)
2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识
3.所有的操作都是无状态的

REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP
 规范定义的。其核心操作只有GET,PUT,POST,DELETE。

由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。

对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。

如果从这个意义上讲，是否使用REST就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。

其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。

简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。

正如另外一篇文章里面谈到的，REST核心是url和面向资源，url代替了原来复杂的操作方法。REST允许我们通过url设计系统，就像测试驱动开发使用测试用例设计类接口一样。所有可以被抽象为资源的东西都可以使用RESTful的url，当我们以传统的用SOAP方式实现的一个查询订单服务的时候可以看到，这个服务首先存在输入的查询条件，然后才是输出结果集。那么对于类似场景要使用REST，不可避免的会将传统的SOAP服务拆分为一个HTTP
 POST操作和一个HTTP GET操作。前面是输入，而后面是输出。

使用REST的关键是如何抽象资源，抽象的越精确，对REST的应用越好。如何进行抽象，面向资源的设计和传统的面向结构和对象设计区别，资源和对象，数据库表之间的差别是另外一个在分析设计时候要考虑的问题。在REST分析设计中如何改变传统的SOAP分析设计思想又是一个重要问题。

下文转载自：http://hi.baidu.com/gaohong230/blog/item/cd3924396bc7332fb9998f52.html

在SOA的基础技术实现方式中WebService占据了很重要的地位，通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受，同时各大网站不断开放API提供给开发者，也激起了REST风格WebService的热潮。

SOAP

什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。

REST

REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。

REST的思想归结以下有如下几个关键点：

1．面向资源的接口设计

所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计，其实是RPC-REST的混合体，并非是REST的思想。

2．抽象操作为基础的CRUD

这点很简单，Http中的get,put,post,delete分别对应了read,update,create,delete四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题，如果要完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。      

3．Http是应用协议而非传输协议

这点在后面各大网站的API分析中有很明显的体现，其实有些网站已经走到了SOAP的老路上，说是REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。

4．无状态，自包含

这点其实不仅仅是对于REST来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP的WebService也是一样。

SOAP Webservice和RESTful Webservice的比较

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

SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正）

REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web
 service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。

由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。

效率和易用性(REST更胜一筹)

SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。

REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。

安全性：

这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全已经被提到了很高的高度，特别是作为外部接口给第三方调用，安全性可能会高过业务逻辑本身。

SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。

REST没有任何规范对于安全方面作说明，同时现在开放REST风格API的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，其实是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范，是未知的，但是加入的越多，REST失去它高效性的优势越多。

应用设计与改造：

我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。总的来说，其实还是一个老观念，适合的才是最好的

技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。

REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。

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

    
REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：

      1.网络上的所有事物都可以被抽象为资源(resource)
      2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识
      3.所有的操作都是无状态的

       REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。

       由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。

       对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。

REST ful 应用问题
       是否使用REST就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。

       其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。

       简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。

效率和易用性
      SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。

      REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息

安全性
       技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。

       REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。

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

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

       由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。

转载于:https://www.cnblogs.com/h-c-g/p/10911085.html

一、WebService涉及的相关概念：

1、Soap：简单对象访问协议（Simple Object Access Protocol，SOAP）是一种基于 XML 的协议，由Dave Winer, Don Box，Bob Atkinson, Mohsen Al-Ghosein于1998年设计，当时只作为一种对象访问协议。现在SOAP采用了已经广泛使用的两个协议:HTTP 和XML（标准通用标记语言下的一个子集）。HTTP用于实现 SOAP 的RPC 风格的传输, 而XML 是它的编码模式。采用几行代码和一个XML 解析器, HTTP 服务器( MS 的 IIS 或 Apache) 立刻成为SOAP 的 ORBS。SOAP 通讯协议使用 HTTP 来发送XML 格式的信息。

2、WSDL：WSDL （(Web Services Description Language）是基于 XML 的用于描述 Web Services 以及如何访问 Web Services 的语言，就是用机器能阅读的方式提供的一个正式描述文档而基于XML（标准通用标记语言下的一个子集）的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。WSDL 文档的主要结构是类似这样的：

<definitions>

<types>
   definition of types........
</types>

<message>
   definition of a message....
</message>

<portType>
   definition of a port.......
</portType>

<binding>
   definition of a binding....
</binding>

</definitions>

3、UDDI：UDDI（Universal Description, Discovery and Integration），可译为“通用描述、发现与集成服务”。 目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

W3school定义：

UDDI 指的是通用描述、发现与集成服务
	
UDDI 是一种用于存储有关 web services 的信息的目录。
	
UDDI 是一种由 WSDL 描述的 web services 界面的目录。
	
UDDI 经由 SOAP 进行通信
	
UDDI 被构建入了微软的 .NET 平台
       上面讲了WebService的三要素，下面我们给出WebService定义：从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API，能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。

 

二、RestFul，REST（Representational State Transfer，表述性状态转移） 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。

RESTful 架构的核心规范：

1. 网络上的所有事物都可以被抽象为资源(resource)

2. 每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识

3. 所有的操作都是无状态的

比较：

1、

SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。

RESTful由于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了http最初的应用协议设计理念。

2、

RESTful对于资源型服务接口来说很合适，同时特别适合对效率要求很高，但是对于安全要求不高的场景。

SOAP的成熟性可以给需要提供给多开发语言，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。