导航
导航
文章目录
  1. 特点
  2. 实例
  3. REST与SOAP
  4. 拓展阅读

关于REST

REST,全称REpsentation State Transfer,表现状态转换

特点

1、由Roy Thomas Fielding在他2000年的博士论文中提出,他是HTTP协议(1.0版和1.1版)的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席
2、以资源为中心
资源(Resources),即网络上的一个实体,或者说是网络上的一个具体信息
如文本、图片、歌曲、服务、应用程序对象、数据库记录、算法等
每个资源都使用URI(Universal Resource Identifier)得到一个唯一的地址
3、显式地使用 HTTP 方法
REST要求开发人员显式地使用HTTP方法,并且使用方式与协议定义一致
这个基本的REST设计原则建立了创建、读取、更新和删除(create、read、update、delete,CRUD)操作,与HTTP方法之间的一对一映射:
使用POST方法,在服务器上创建资源
使用GET方法,检索某个资源
使用PUT方法,更改资源状态或对其进行更新
使用DELETE方法,删除某个资源
4、是风格,而不是标准
在我看来,风格与标准的最大区别是是否可以准确判定。
对于标准,应该是非黑即白的。例如,对于web services标准,一个XML是不是符合SOAP协议的,很简单就可以判定,是或者不是。
而对于风格,只是一个高层次的描述,它的边界是模糊的,很难界定一个实现是否是某种风格,但可以说它是符合某种风格的,所以对于REST风格的应用,使用RESTful这个词汇,ful后缀一般用来放在边界较为模糊的形容词上,例如Beautiful。
5、无状态的
从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
REST Web 服务需要扩展以满足日益提高的性能要求。 具有负载平衡和故障转移功能、代理和网关的服务器集群通常以形成服务拓扑的方式进行组织,从而允许根据需要将请求从一个服务器路由到另一个服务器,以减少 Web 服务调用的总体响应时间。 要使用中间服务器扩大规模,REST Web 服务需要发送完整、独立的请求;也就是说,发送的请求包括所有需要满足的数据,以便中间服务器中的组件能够进行转发、路由和负载平衡,而不需要在请求之间在本地保存任何状态。
完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。 REST Web 服务应用程序(或客户端)在 HTTP Header 和请求正文中包括服务器端组件生成响应所需要的所有参数、上下文和数据。 这种意义上的无状态可以改进 Web 服务性能,并简化服务器端组件的设计和实现,因为服务器上没有状态,从而消除了与外部应用程序同步会话数据的需要。
6、无法应用于事务性
对于事务型的服务,一个简单的例子就是银行事务,在那里用户可以把钱从一个账户转移到另一个账户上。用户不想直接操作资源(钱、银行账户等等),他们只想告诉银行他们想要达到的目的,并且让银行根据他们的利益对资源进行处理。
所以从这一条,我们应该明白,选择基于REST或SOAP RPC风格的Web 服务,我们应该首先考虑这个服务是针对资源的还是针对活动的。

  • James Snell,面向资源与面向活动的 Web 服务

实例

在Web API中,存在很多将HTTP方法用于非预期用途的设计,很不优雅,且容易引起误调用(如使用GET获取内容而不小心向服务器添加了数据)。
通过实例,可以更加直接地理解REST解决的问题和优势:
糟糕的设计:
增加用户:GET /adduser?name=Robert HTTP/1.1
更新用户:GET /updateuser?name=Robert&newname=Bob HTTP/1.1
REST:
增加用户:
POST /users HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version=”1.0”?>


Robert

更新用户:
PUT /users/Robert HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version=”1.0”?>


Bob

查询用户:
GET /users/Robert HTTP/1.1
Host: myserver
Accept: application/xml

REST与SOAP

随着RESTful架构高效简洁易用的特性越来越深入人心,Web Services渐渐也引入了REST风格的写法,REST与SOAP相比:
1、SOAP面向XML,REST面向HTTP
使用SOAP的Web Services实现将HTTP简化为POST方式,行为和参数都封装在SOAP里
而REST更加面向HTTP的操作映射,同时支持JSON等多种格式
另一方面,REST的提出者是HTTP的主要设计者,这一点就更容易理解了
2、SOAP面向操作,REST面向资源
SOAP协议描述了提供服务的方法和参数,用来描述用什么数据来做什么样的行为,是面向操作的,有操作,才有资源
RESTful的设计中,url表达的是资源,更加关注资源的定位,以资源为中心,其次才是HTTP头中的操作,有资源,才有操作
在使用SOAP协议的Web Services中,HTTP请求被简化为全部使用POST请求,而操作封装在SOAP里;使用REST则遵循HTTP的规范,在HTTP头中定义操作
3、SOAP更容易扩展,REST无法胜任一些复杂服务
对于一些复杂的服务接口来说,按照REST的风格来设计会有些牵强
观察各大网站的接口,很多网站还要传入function的名称作为参数,明显已经违背了REST本身的设计思路
4、SOAP更加成熟,REST更加高效
SOAP发展至今,厂商的支持已经达到了较为成熟的情况,不同平台语言之间通过SOAP来交互的Web Services都能够较好地互通
但SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加
REST高效简洁,且除了XML还支持JSON、RSS、ATOM等,更加易用
5、安全性
SOAP使用XML-Security和XML-Signature两个规范,组成WS-Security实现安全控制,且得到了各大厂商和平台的很好支持
REST没有任何安全方面的说明,现在开放REST风格API的网站主要分成两种:
a. 封装自定义的安全信息在消息中,这和SOAP没有什么区别
b. 硬件SSL,只能够保证点到点的安全,如果是需要多点传输的话SSL就无能为力了

拓展阅读

RESTful API设计指南: http://www.ruanyifeng.com/blog/2014/05/restful_api.html
各大网站REST风格API设计: http://blog.csdn.net/cenwenchu79/article/details/2112275

参考:
http://baike.baidu.com/link?url=lPP8IHeih-P3pBDlqaLm3BMRHSPdsCMIJeuuRRRLRLUsPFbC8ygng7kCp5-wGA49EUIgAfMFWfJjws5S5HoG3K
http://blog.csdn.net/cenwenchu79/article/details/2112275
https://www.ibm.com/developerworks/cn/webservices/ws-restful/
http://zhangjunhd.blog.51cto.com/113473/47283/
http://www.ruanyifeng.com/blog/2011/09/restful