SOA之（5）——REST的SOA（SOA with REST）概念

引自：http://www.cnblogs.com/richaaaard/p/5006432.html

REST的SOA（SOA with REST）概念

发展

1992年网站（Web Sites）是在Web浏览器和Web服务器直接经过HTTP传输HTML。

2000年WS-* （Web Services）是在客户端和服务器之间基于HTTP传输SOAP XML格式的数据，服务端用WSDL来规定契约。

2007年RESTful （Web Services）是在客户端和服务器之间基于HTTP传输JSON、PO-XML、RSS格式的数据，服务端用WADL来规定契约。

 

Web services从哪来？

解决企业软件标准化的问题

企业计算的互用性标准

一个提供消息、描述、发现规范的分层架构

可以快速从底层构建提供解决方案

工具能够将复杂性屏蔽

处理异构（Heterogeneity）

Web应用（Web Applications）与 企业计算（Enterprise Computing）

庞然大物（Big Web Services）

• 复杂难以理解（High perceived complexity）
• 标准化存在问题
  • 斗争中（infighting）
  • 缺少架构的一致性（architectural coherence）
  • 碎片化（fragmentation）
  • 设计委员会（committee）
  • 特性膨胀（feature bloat 主要提如今不断新增的文档）
  • 缺少参考实现（reference implementations）
  • 标准的标准（Standardization of standards (WS-I)）
• 看似另外一个CORBA？
• Web services的互用性真的存在？
• 咱们真的须要采用XML来提高性能？

一个关于Web Services文档的不彻底统计（http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research）

Group	Spec	Page Count
安全Security
	Web Services Security (O)	56
	UsernameToken Profile (O)	15
	X.509 Certificate Token Profile (O)	16
	Policy Language (M)	13
	Trust Language (M)	41
	Secure Conversation Language (M)	17
	Web Services Federation Language(M)	28
	WS-Federation: Active Requestor Profile (M)	14
	WS-Federation: Passive Requestor Profile (M)	13
	Kerberos Binding (M)	17
可靠消息Reliable Messaging
	Reliable Messaging (M)	21
事务Transactions
	Coordination (M)	16
	Atomic Transaction (M)	10
	Business Activity Framework (M)	13
元数据Metadata
	WSDL 1.1 (W)	32
	Policy Framework (M)	15
	Policy Attachment (M)	10
	Policy Assertions Language (M)	9
	Dynamic Discovery (M)	22
	Metadata Exchange (M)	23
消息Messaging
	SOAP 1.2 Primer (W)	39
	SOAP 1.2 Messaging Framework (W)	47
	SOAP 1.2 Adjuncts (W)	25
	Addressing (M)	15
	MTOM (W)	13
	Enumeration (M)	27
	Eventing (M)	21
	Transfer (M)	17
	SOAP-over-UDP (M)	7
管理Management
	Web Services for Management (M)	23
业务流程Business Process
	BPEL4WS (M)	74
配置文档pecification Profiles
	Devices Profile (O)	24
	WS-I Basic Profile (O)	50
	TOTAL PAGES:	783

正文目录

什么是REST？

RESTful的设计

WS-*与REST的比较

讨论

前瞻

表述性状态转移（REpresentational State Transfer）

REST为Web定义了一个架构风格

它的四个原则能够用HTTP协议来实现

1. URI资源识别（Resource Identification）
2. 全部资源统一接口（Uniform Interface）
   • GET（状态查询、幂等性、缓存）
   • POST（建立子资源）
   • PUT（更新、状态转换）
   • DELETE（删除资源）
3. 自解释（Self-Describing），消息的元数据和多种资源表述
4. 超连接（Hyperlinks），定义应用的状态转换和资源之间的关系

一个RESTful Web Service的例子

统一接口原则（CRUD的例子）

建立（POST《-》）——建立一个子资源

读取（GET《-）——获取当前资源的状态

更新（PUT -》）—— 初始化或更新一个URI对应的资源状态

删除（DELETE）——清除一个资源（在一个URI失效以后）

统一资源标识符URI（Uniform Resource Indentifier）是什么？

• 因特网对于资源命名和标识的标准

例如：

http://tools.ietf.org/html/rfc3986

http——统一资源标识符方案（URI Scheme）

://tools.ietf.org——受权（Authority）一般是一个主机名

/html/rfc3986——路径（Path）

https://www.google.ch/search?q=rest&start=10#1

?q=rest&start=10——查询（Query）

#1——片断（Fragment）

• REST并不拥护“好”的URI
• 在多数HTTP栈中URI的长度不能大于4Kb

什么是“好”的URI？

 

URI的设计指南

• 名词（Nouns）优于动词（Verbs）
• URI保持简短

　　　　GET /book?isbn=24&action=delete

　　　　DELETE /book/24

• 听从位置经过参数传递的方案

　　　　REST URI对于客户端透明的意思是它是由后续的连接提供，而不是经过客户端自行建立

• 不要改变URI
• 真的须要改变时，用重定向实现（redirection）

　　　　注意：URI模板引入了客户端和服务端的耦合

高级REST 和 低级REST

关于REST实现的最佳实践有些区别（在本人实际工做中，不少技术实力雄厚的大型企业，对于REST最佳实践的方案也基本能够归为如下两种，而第一种“低级”REST比较广泛）

低级REST（Low REST）

• 用HTTP GET实现幂等请求，其余全部请求都用POST（没有HTTP PUT DELETE等其余方法）
• 响应格式（MIME Type）多种多样（e.g. XHTML, application/json, application/xml）

高级REST（High REST）

• 推荐使用好的URI
• 充分使用4个动词：GET、POST、PUT和DELETE（*）
• 响应体用（Plain Old） XML（**）

补充说明：

（*）有些防火墙或者HTTP的代理可能丢弃PUT/DELETE请求

（**）XML能够被RDF、JSON、YAML或者ATOM（ATOM存在很大的争议）替代

资源表述的格式XML vs. JSON

XML	JSON（JavaScript Object Notation）
—PO-XML	为AJAX Web应用引入格式供（浏览器－Web服务器通信）
—SOAP（WS-*）
—RSS，ATOM
半结构化的数据和标准的文本语法	文本语法支持序列化非循环的数据结构
工具：XML Schema，DOM，SAX，Xpath，XSLT，Xquery	有不少语言支持（不只仅JavaScript）
每一个人均可以解析它（不须要理解）	不须要扩展
慢、臃肿	JSON已经成为AJAX中的X而不是XML

 一个JSON的例子

REST 的优与劣

 

优点（Strengths）	劣势（Weakness）
简单 —统一接口不可变动	混乱（区分high REST和low REST)
HTTP／POX 无处不在	在先后台系统设计中存在不匹配的状况（异步消息和事件驱动）
无状态／同步交互	除了HTTP／SSL不能实现其余的企业应用的风格(*)
可扩展
易于理解并采用（轻量级） —只须要一个浏览器，不须要WS中间件	对于合适的识别和定位全部应用中的资源时一个挑战
朴素的方法(grassroot approach)	缺少标准（本人认为REST是一个设计风格而非标准）
被全部的Web2.0应用采用 —85%的客户都喜欢Amazon的RESTful API —Google再也不支持SOAP／WSDL API	语法和语义的描述是非正式的（面向用户的） （本人认为这也偏偏是一个优点）

 (*) 关于企业的应用风格（-ilities）参照文章http://www.cnblogs.com/richaaaard/articles/5006681.html

是否不能实现咱们还有待探讨

关于RESTful Web Services的设计方法

1. 识别资源并暴露成服务（例如，年度风险报表，图书分类，采购订单，缺陷，调查投票等）
2. 定义好的URL供寻址
3. 理解GET、POST、PUT、DELETE对于一个URI资源的意义
4. 设计并记录资源的表述
5. 用超连接（hyperlinks）为资源关系建模
6. Web服务器实现与部署
7. 用浏览器进行测试（固然这里还有其余一些好的辅助测试工具，后面能够专门开文章探讨）

一个简单的Doodle API例子

• 建立一个投票

• 查询一个投票

• 参加投票并建立一个新的子投票资源

• 更新一个一有投票（访问控制头没有显示）

• 当投票结果和决定产生后，投票能够将其删除

更多的信息能够查看Doodle API: http://doodle.com/xsd1/RESTfulDoodle.pdf

（固然在RESTful下也有不少其余的API实现）

REST设计的相关小贴士

• 理解GET、POST、PUT
  • GET 是一个只读操做。它能够重复执行屡次而不影响资源的状态（幂等性），也能够被缓存
  • POST是一个读写操做，能够改变资源的状态，也会读服务器产生影响
  • PUT 是一个写操做，但问题是如何正确的使用PUT？由于 PUT /resource/{id}能够被多个客户端并发调用，如何保证资源{id}的惟一性？
• 多种表述形式的妥协（Content-Type）
  • 一般客户端能够提供本身能够处理的格式列表 Accept: text/html, application/xml, application/json
  • 服务端则本身选择最合适的响应格式200 OK Content-Type: application/json
  服务端一般经过资源表述不一样的后缀形式提供不一样的内容格式(只是一个best practice而不是标准)
  • GET /resource.html
  • GET /resource.xml
  • GET /resource.json
• 异常处理（Idempotent vs. Unsafe）

　　　　主要体如今HTTP的标准响应码上

　　

对于GET、PUT、DELETE这些幂等操做，能够执行屡次而不会对服务端的状态产生其余影响，能够在服务器宕机或者出现内部错误而恢复事后，从新发起这些请求。对于POST这种非幂等操做就须要在出现异常以后特殊处理，在有些场景下，它也能够被设计成幂等操做来实现：

B = GetBalance()  // safe
B = B + 200$       // local
SetBalance(B)      // safe

总而言之，对比WS-*和REST

就是一个苹果和一个橘子的对比。一个是中间件互用性的标准，另外一个是Web架构的风格。

那咱们仍是来比较一下SOAP和REST吧

• 先举例
• 概念比较
  • REST做为连接
• 技术性比较
  • 服务的表述
  • 安全
  • 状态管理
  • 异步消息

举一个RESTful Web 应用的栗子

一样的场景下WS是这样的

REST和SOAP最主要的区别在于

• 对于REST而言，Web是一个任何人都能访问的信息

　　　　—应用须要把它的信息经过URI发布到网络

• 对于WS而言，Web是任何传输的消息

　　　　—应用能够与网络交互，可是他们处于网络以外

 REST是一种连接方式

 

他们（REST vs. SOAP）是如何描述服务的呢？

REST	SOAP
REST是基于人类可读的文档，它定义了请求的URI和响应（XML，JSON）	客户端的stubs能够经过WSDL的描述用大多数语言生成 （实际上SOAP也是一种XML，也是可读的）
须要大量的测试和调试，由于URI是手工建立的 （是否有相关工具）	每一个服务都根据本身的语法发布本身的接口
咱们为何须要强类型的消息？ （若是客户端和服务端都很清楚传输的内容是什么）	强类型
WADL	WSDL1.1（整个开放端口对于GET和POST是统一的）
XML 足够了？（实际上有JSON、XML等其余）	WSDL2.0（更灵活，每一个方法的GET or POST可选）

 REST和SOAP安全对比

REST	SOAP
REST的安全就是HTTPs	SOAP的安全定义在WS－Security中
被证实的（SSL1.0 自1994）	XML加密
	XML签名
	—完全的互用性没有意义
	—性能？
点到点安全（认证、完整和加密）	端到端安全，不须要HTTPs

一直争论的状态仍是无状态

REST	SOAP
显性的状态转换	隐性的状态转换
—通讯是无状态的	—服务端能够保持状态
—资源数据包含了有效的状态连接	—消息只包含数据
—客户端根据连接来获取并维护状态	—客户端根据服务端的状态机逻辑来维护本身的状态
Session技术	Session技术
—Cookies（HTTP Headers）	—Session Headers（非标准）
—URL Re-writing
—表格字段隐藏

 异步可靠的消息

• 对于REST来讲，HTTP是一个同步的协议，可是它也能够模拟异步消息

POST /queue

202 Accepted
Location:
        /queue/message/1230213
____________________________
GET  　　/queue/message/1230213
DELETE
        /queue/message/1230213

• SOAP消息能够经过异步协议传输（好比，JMS、MQ等）
  • WS－Addressing能够用来定义独立的传输点
  • WS－ReliableExchange定义了一个可靠的传输协议（SOAP headers）　　

REST 和SOAP/WS*的类似点

REST	SOAP
XML	O/XML 绑定
	其余的方式JSON、YAML、RDF
XML Schema	数据格式的契约须要和接口一块儿定义
HTTP	尽管REST认为SOAP误用了POST
松耦合可扩展	SOAP提供同步异步方式
	SOAP认为统一的接口不会改变

揭露所谓的秘密

• 许多REST的拥趸认为REST和Web service是不相兼容的
• 实施上：SOAP和WSDL的新版本已经将Web services设计得更“RESTful”
• SOAP1.2
  • Response MEP
  • Web Method
• WSDL2.0
  • HTTP绑定新增了操做级别（per－operation）对于GET、POST指定
  • 增长对于safe／cacheable的属性标签
• 可是想让RESTful彻底使用Web services仍是很困难

（然而市面上有些产品实际上能够支持他们的相兼容）

总结和前瞻

• SOA能够用不一样方式实现
• 关注架构如何解决问题以及这些相关标准的价值，而非具体架构和技术的盲从
• SOAP/WS-* 与 REST都有本身的优点和适合的应用场景
• 将来会有融合两种技术优点的中间件技术出现（新SOAP和WSDL标准）