【接口】Rest和WebService

素颜马尾好姑娘i 2024-04-18 06:38 106阅读 0赞

先转一篇博客：[https://blog.csdn.net/ningjiebing/article/details/90602470][https_blog.csdn.net_ningjiebing_article_details_90602470]

首先需要了解：REST是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动；

## 　相关概念： ##

**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服务，这种使用方式是没有意义的。**  
————————————————  
通过上一篇博客说明，**REST**的优势是轻量级，简单调用；而**soap**慢慢系统化规范化，适用于面向复杂的活动服务。

## rest api和webservice 的区别比较 ##

转载至：[https://blog.csdn.net/u011221715/article/details/47036735][https_blog.csdn.net_u011221715_article_details_47036735]

一般客户端访问服务器端web服务通常可以由HTTPService、WebService、RemoteObject等方式来实现。通常实现web服务我们最容易想到的是SOAP协议的WebService，这在目前web服务中占有很重要的地位。随着REST思想的出现，目前很多公司开始使用REST风格的WebService。  
   SOAP： 简单对象访问协议，简单对象访问协议（SOAP）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。 SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。  
     REST: 即REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。  
     REST 与SOAP的比较：   
成熟度  
     SOAP目前成熟，不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。REST相对不太成熟，由于没有类似于SOAP的权威性协议作为规范，REST实现的各种服务风格不一，通用性不强。  
效率和易用性  
     SOAP使用门槛高（学习成本高，开发难度大），由于SOAP由于各种需求不断扩充其本身协议的内容，在大并发下性能有所下降。REST 目前大量的Web 2.0网站使用，高效以及简洁易用。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。REST 是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。  
安全性  
     SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。REST没有任何规范对于安全方面作说明。因此在考虑安全性上，SOAP要高于REST。  
     总的来说，我认为REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。  
Rest Service具备Web Service的所有特点：平台独立、松耦合、互操作性。并且，Rest 更轻量级，更简单。可以这么说吧，Rest Service 是Web Service的一种实现，并不是说Rest是Web service替代。

[https_blog.csdn.net_ningjiebing_article_details_90602470]: https://blog.csdn.net/ningjiebing/article/details/90602470
[https_blog.csdn.net_u011221715_article_details_47036735]: https://blog.csdn.net/u011221715/article/details/47036735