浅谈 SOAP Webserver 与 Restful Webserver 区别

谁借莪１个温暖的怀抱￠ 2024-04-18 22:05 84阅读 0赞

**一　　REST：**

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

**REST提出设计概念和准则为：**  
　　　　1.网络上的所有事物都可以被抽象为资源(resource)  
　　　　2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识  
　　　　3.所有的操作都是无状态的  
  
　　REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：**创建，获取，更新和删除**就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有**GET,PUT,POST,DELETE**。

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

**二　　SOAP**

SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容。

SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。

而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。

**如何确定使用REST：**

若本身只是简单的CRUD业务操作，那么抽象资源就比较容易。

而对于复杂的业务活动抽象资源并不是一个简单的事情，比如校验用户等级，转账，事务处理等。  
　　**如何确定使用SOAP：**  
　　　　若有严格的规范和标准定义要求，且前期需要指导多个业务系统集成和开发的时，

因SOAP风格有清晰的规范标准定义，SOAP更适合。

我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。  
　**　一句话：**

简单数据操作，无事务处理，开发和调用简单使用REST架构风格较好。

**再者：**  
　　　　**REST**核心是url和面向资源，url代替了原来复杂的操作方法。

**REST**允许我们通过url设计系统，就像测试驱动开发使用测试用例设计类接口一样。

所有可以被抽象为资源的东西都可以使用**RESTful的url**。

**REST关键：**  
　　　　使用**REST**的关键是如何抽象资源，抽象的越精确，对REST的应用越好。

———————————————————————————————————————

**三　　REST思想**

**1．面向资源的接口设计**

所有的接口设计都是针对**资源**来设计的（包括操作也是一种资源）。

**　　　　URI**的设计也是体现了对于资源的定位设计。

**2．抽象操作为基础的CRUD**  
  
　　　　Http中的**get,put,post,delete**分别对应了**read,update,create,delete**四种操作

如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于复杂的业务接口，未必能够满足。

完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。        
  
　　**3．Http是应用协议而非传输协议**  
  
　　　　部分认为：REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。  
  
　　**4．无状态，自包含**  
  
　　　　接口设计都需做到这点，不仅仅是REST，也是作为可扩展和高效性的最基本的保证，SOAP也类似。

**四　　SOAP Webservice和RESTful Webservice的比较**

**1.成熟度(总的来说SOAP在成熟度上优于REST)**  
  
　　　　SOAP对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。  
  
　　　　REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，

但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套。  
  
　　　　REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想。  
  
**　　2.效率和易用性(REST更胜一筹)**  
  
　　　　**SOAP**协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，

WS-\*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP

处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。  
  
　　　　**REST**被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。

这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，

同时也最大限度的利用了Http最初的应用协议设计理念。

同时，REST很好的融合当前Web2.0的很多前端技术来提高开发效率。

**例如:**很多大型网站开放的REST风格的API都会有多种返回形式（XML,JSON,RSS,ATOM）等形式。  
  
　　**3.安全性**

**SOAP**在安全方面使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，

当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。  
  
　　　　**REST **开放REST风格API的网站主要分成两种:

一种是自定义了安全信息封装在消息中，

另外一种就是靠硬件SSL来保障,这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。

安全这块其实也是一个很大的问题。

**五　　应用设计与改造**

我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。总的来说，其实还是一个老观念，适合的才是最好的  
  
技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。  
  
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。  
  
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

(本文结合各大博客论坛，学习，借鉴，总结而来，欢迎转载)