http,soap and rest

http://www.cnblogs.com/hyhnet/archive/2016/06/28/5624422.html

http://www.cnblogs.com/bellkosmos/p/5213491.html

https://www.zhihu.com/question/28557115

http是标准超文本传输协议。使用对参数进行编码并将参数作为键值对传递，还使用关联的请求语义。每个协议都包含一系列HTTP请求标头及其他一些信息，定义客户端向服务器请求哪些内容，服务器用一系列HTTP响应标头和所请求的数据进行响应。HTTP-GET 使用 MIME 类型application/x-www-form-urlencoded（将追加到处理请求的服务器的 URL 中）以 URL 编码文本的形式传递其参数。 URL 编码是一种字符编码形式，可确保传递的参数中包含一致性文本，例如将空格编码为 %20，其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII（或ISOLatin-1）值。 追加的参数也称为查询字符串;HTTP-POST参数也是 URL 编码的，但是，键/值对是在实际的 HTTP 请求消息内部传递的，而不是作为 URL 的一部分进行传递。

SOAP（Simple Object AccessProtocol）简单对象访问协议。它是轻型协议，用于分散的、分布式计算环境中交换信息。SOAP有助于以独立于平台的方式访问对象、服务和服务器。它借助于XML，提供了HTTP所需的扩展。

SOAP协议规范由4个主要的部分组成。

第一部分：SOAP封装（Envelop）定义了一个的框架（描述消息的内容多少、谁发送、谁应当接受、处理，以及如何处理它们）。

第二部分：SOAP编码规则（Encoding Rules）定义了可选数据编码规则，用于表示应用程序定义的数据类型和直接图表，以及一个用于序列化非语法数据模型统一标准。

第三部分：SOAP RPC表示（RPC Representation）定义一个远程调用风格（请求/响应）信息交换的模式。

第四部分：SOAP绑定（Binding）定义了SOAP和HTTP之间的绑定和使用底层协议的交换。

SOAP协议可以简单地理解为：SOAP=RPC+HTTP+XML，即采用HTTP作为通信协议，RPC（Remote Procedure Call Protocol - 远程过程调用协议）作为一致性的调用途径，XML作为数据传送的格式，从而允许服务提供者和服务客户经过防火墙在Internet上进行通信交互。

REST(Representational State Transfer)一种轻量级的Web Service架构。可以完全通过HTTP协议实现。其实现和操作比SOAP和XML-RPC更为简洁，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。
REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法

SOAP与HTTP的区别

web service相对http（post/get）由于要进行xml解析，速度可能会有所降低。

web service完全可以被http（post/get）替代。

Restful与SOAP的区别

安全性：SOAP会好于restful

效率和易用性(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

　　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风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

接口
rest 架构风格
建立api时要遵守的规则

web是分布式信息系统为超文本和其他对象（资源）提供访问接口
资源是web架构的关键点，需要3个操作 识别identify，标示represent 交互 interact with
通过这三个操作又引出uri（统一资源标识符url和urn）识别资源
representation（html，xml，图片，视频）标示资源
通过协议（http，rpc，ftp）与资源进行交互

所以REST就是通过http和uri，利用cs mode对资源进行CRUD操作

限制和好处
1. cs 客户端服务器分离

提高user gui的便携性，通过简化服务器提高伸缩性（高性能，低成本）
允许组件分别优化（服务端和客户端分别改进优化）

2 stateless 无状态

提高了可见性（可以单独考虑每个请求）
可靠性（更容易从局部故障中修复）
可扩展性（降低服务器资源）

3 缓存 cachable

服务器返回信息必修被标记是否可以缓存
减少互动次数
减少交互平均延迟

4 分层系统layered system

封装服务，引进中间层

限制系统复杂性
提高可扩展性

5 统一的接口 uniform interface

提高交互可见性

6 支持按需代码 code on demand

提高可扩展性