有好多人问咱们在设计底层服务的时候究竟是应该选择目前最流行的RestFul架构仍是选择老牌的webService呢？今天我就将这两个概念作一下阐述，到底什么状况下选择什么比较合理。html
首先须要了解：REST是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动；web
相关概念：数据库
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专门针对网络应用设计和开发方式，以下降开发的复杂性，提升系统的可伸缩性。REST提出设计概念和准则为：
1. 网络上的全部事物均可以被抽象为资源(resource)
2. 每个资源都有惟一的资源标识(resource identifier)，对资源的操做不会改变这些标识
3. 全部的操做都是无状态的
REST简化开发，其架构遵循CRUD原则，该原则告诉咱们对于资源(包括网络资源)只须要四种行为：建立，获取，更新和删除就能够完成相关的操做和处理。咱们能够经过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，而且针对这些资源而执行的操做是经过 HTTP 规范定义的。其核心操做只有GET,PUT,POST,DELETE。因为REST强制全部的操做都必须是stateless的，这就没有上下文的约束，若是作分布式，集群都不须要考虑上下文和会话保持的问题。极大的提升系统的可伸缩性。网络
SOAP webService有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操做方法和操做对象的分离，有WSDL文件规范和XSD文件分别对其定义。架构
若是从这个意义上讲，是否使用REST就须要考虑资源自己的抽象和识别是否困难，若是自己就是简单的相似增删改查的业务操做，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并非一个简单的事情。好比校验用户等级，转帐，事务处理等，这些每每并不容易简单的抽象为资源。
其次若是有严格的规范和标准定义要求，并且前期规范标准须要指导多个业务系统集成和开发的时候，SOAP风格因为有清晰的规范标准定义是明显有优点的。咱们能够在开始和实现以前就严格定义相关的接口方法和接口传输数据。（不少状况下是为了兼容之前项目且前台调用逻辑代码都不能动的前提下，更改底层应用，通常就须要使用webService模式开发，由于老代码中已经有了明确的方法定义以及参数类型、个数等申明）
简单数据操做，无事务处理，开发和调用简单这些是使用REST架构风格的优点。而对于较为复杂的面向活动的服务，若是咱们仍是使用REST，不少时候都是仍然是传统的面向活动的思想经过转换工具再转换获得REST服务，这种使用方式是没有意义的。less