RESTful架构,就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便,因此正获得愈来愈多网站的采用。html
可是,到底什么是RESTful架构,什么是REST原则,二者是什么关系?前端
一句话总结:REST 指的是一组"架构"的约束条件和原则。知足这些约束条件和原则的应用程序或设计就是 RESTful。web
即,若是一个架构符合REST原则,就称它为RESTful架构。
算法
基础概念:数据库
REST是设计风格而不是标准。
REST一般基于使用HTTP,URI,和XML以及HTML这些现有的普遍流行的协议和标准。
资源是一个概念实体,它向客户端公开。
资源是由URI来指定。
对资源的操做(获取、建立、修改和删除资源),正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
经过操做资源的表现形式来操做资源。
资源的表现形式则是XML或者HTML,取决于读者是机器仍是人,是消费web服务的客户软件仍是web浏览器。固然也能够是任何其余的格式。
REST (Representation State Transfer) 描述了一个架构样式的网络系统,好比 web 应用程序。REST 一词的出于 2000 nian Roy Fielding (HTTP1.0/1.1 规范的主要编写者之一)的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中,简单的从标题来看,它应该是一种架构样式 (Architectural Styles) 与软件架构 (Software Architectures),并且是以网络 (Network-based) 为基础,重点就是:json
架构样式 (Architectural Styles)设计模式
软件架构 (Software Architectures)api
网络 (Network-based) 为基础浏览器
REST 指的是一组架构约束条件和原则,是设计风格而不是标准。知足这些约束条件和原则的应用程序或设计就是 RESTful。缓存
REST 谈论的是: 如何正确地使用 Web标准,例如,HTTP 和 URI。因此,想要了解 REST 就是要先了解 Web 及其工做方式。若是你设计的应用程序能符合 REST 原则 (REST principles),这些符合 REST 原则的 REST 服务可称为 "RESTful web service" 也称 "RESTful Web API"。"-ful" 字尾强调它们的设计彻底符合 REST 论文里的建议内容。
REST的名称"表现层状态转化"中,省略了主语。"表现层"其实指的是"资源"(Resources)的"表现层"。
在 REST 中的资源 (Resource) 表明整个网络上的资源(一个概念实体,或者说是一个具体信息)。
在服务器端,应用程序状态和功能能够分为各类资源。资源是一个有趣的概念实体,它向客户端公开。
网络上提供了各式各样的资源(资源的例子有:应用程序对象、数据库记录、算法、一段文本、一张图片、一首歌曲、一种服务等等),而每一个资源都使用 URI (统一资源标识符,Uniform Resource Identifier) 获得一个唯一的地址。你能够用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI。要获取这个资源,访问它的URI就能够,所以URI就成了每个资源的地址或独一无二的识别符。
所谓"上网",就是与互联网上一系列的"资源"互动,调用它的URI。
全部资源都共享在统一的层面上,以便在客户端和服务器之间传输状态。
"资源"是一种信息概念实体,它能够有多种外在表现形式。咱们把"资源"具体呈现出来的形式,叫作它的"表现层"(Representation)。
注意:网络上是经过操做资源的表现形式来操做资源的。
好比,文本能够用txt格式表现,也能够用HTML格式、XML格式、JSON格式表现,甚至能够采用二进制格式;图片能够用JPG格式表现,也能够用PNG格式表现。
URI只表明资源的实体,不表明它的形式。严格地说,有些网址最后的".html"后缀名是没必要要的,由于这个后缀名表示格式,属于"表现层"范畴,而URI应该只表明"资源"的位置。它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。
访问一个网站,就表明了客户端和服务器的一个互动过程。在这个过程当中,势必涉及到数据和状态的变化。
互联网通讯协议HTTP协议,是一个无状态协议。这意味着,客户端和服务器之间的交互在请求之间是无状态的,全部的状态都保存在服务器端。所以,若是客户端想要操做服务器,必须经过某种手段,让服务器端发生"状态转化"(State Transfer)。而全部资源都共享在统一的表现层上(以便在客户端和服务器之间传输状态),这种转化是创建在表现层之上的,因此就是"表现层状态转化"。
若是服务器在请求之间的任什么时候间点重启,客户端不会获得通知。此外,无状态请求能够由任何可用服务器回答,这十分适合云计算之类的环境。客户端能够缓存数据以改进性能。
客户端用到的手段,只能是HTTP协议。具体来讲,在 HTTP/1.1 RFC 2616第 5.1.1 Method 一节定义了八大类 HTTP 方法,除了咱们经常使用的 GET 与 POST 以外,在 REST 中经常使用的还有 PUT 与 DELETE。此 GET, POST, PUT, DELETE 正好能够对应咱们 CRUD (Create, Read, Update, Delete) 四种数据操做。
HTTP Method 与 CURD 数据处理操做对应 | ||
HTTP方法 |
数据处理 | 说明 |
POST | Create | 新增一个没有id的资源 |
GET |
Read | 取得一个资源 |
PUT | Update | 更新一个资源。或新增一个含 id 资源(若是 id 不存在) |
DELETE | Delete | 删除一个资源 |
综合上面的解释,咱们总结一下什么是RESTful架构:
(1)每个URI表明一种资源;
(2)客户端和服务器之间,传递这种资源的某种表现层;
(3)客户端经过四个HTTP动词,对服务器端资源进行操做,实现"表现层状态转化"。
另外一个重要的 REST 原则是分层系统,这表示组件没法了解它与之交互的中间层之外的组件。经过将系统知识限制在单个层,能够限制整个系统的复杂性,促进了底层的独立性。
当 REST 架构的约束条件做为一个总体应用时,将生成一个能够扩展到大量客户端的应用程序。它还下降了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。
能够利用缓存Cache来提升响应速度
通信自己的无状态性可让不一样的服务器的处理一系列请求中的不一样请求,提升服务器的扩展性
浏览器便可做为客户端,简化软件需求
相对于其余叠加在HTTP协议之上的机制,REST的软件依赖性更小
不须要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
REST 描述了一个架构样式的互联系统(如 Web 应用程序)。REST 约束条件做为一个总体应用时,将生成一个简单、可扩展、有效、安全、可靠的架构。因为它简便、轻量级以及经过 HTTP 直接传输数据的特性,RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方an。用于 web 服务和动态 Web 应用程序的多层架构能够实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。Ajax 和 RESTful Web 服务本质上是互为补充的。开发人员能够轻松使用 Ajax 和 RESTful Web 服务一块儿建立丰富的界面。
参考
RESTful API 设计指南 做者: 阮一峰
六步实现Rest风格的API了解了什么是REST,咱们再看看RESTful的实现。最近,使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最经常使用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)经过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并做为响应发回客户端。客户端收到响应并打开信封。每一个对象都有本身独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务,URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。
因为轻量级以及经过 HTTP 直接传输数据的特性,Web 服务的 RESTful 方法已经成为最多见的替代方法。可使用各类语言(好比 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])实现客户端。RESTful Web 服务一般能够经过自动客户端或表明用户的应用程序访问。可是,这种服务的简便性让用户可以与之直接交互,使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。
在 REST 样式的 Web 服务中,每一个资源都有一个地址。资源自己都是方法调用的目标,方法列表对全部资源都是同样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEADER 和 OPTIONS。
在 RPC 样式的架构中,关注点在于方法,而在 REST 样式的架构中,关注点在于资源 —— 将使用标准方法检索并操做信息片断(使用表示的形式)。资源表示形式在表示形式中使用超连接互联。
Leonard Richardson 和 Sam Ruby 在他们的著做 RESTful Web Services 中引入了术语 REST-RPC 混合架构。REST-RPC 混合 Web 服务不使用信封包装方法、参数和数据,而是直接经过 HTTP 传输数据,这与 REST 样式的 Web 服务是相似的。可是它不使用标准的 HTTP 方法操做资源。它在 HTTP 请求的 URI 部分存储方法信息。好几个知名的 Web 服务,好比 Yahoo 的 Flickr API 和 del.icio.us API 都使用这种混合架构。
有两个 Java 框架能够帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet(见 参考资料)是轻量级的。它实现针对各类 RESTful 系统的资源、表示、链接器和媒体类型之类的概念,包括 Web 服务。在 Restlet 框架中,客户端和服务器都是组件。组件经过链接器互相通讯。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet,该类的子类是zhuan用类,好比 Application、Filter、Finder、Router 和 Route。这些子类可以一块儿处理验证、过滤、安全、数据转换以及将传入请求路由到相应资源等操做。Resource 类生成客户端的表示形式。
JSR-311是 Sun Microsystems 的规范,能够为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。
JSR-311 提供一组注释,相关类和接口均可以用来将 Java 对象做为 Web 资源展现。该规范假定 HTTP 是底层网络协议。它使用注释提供 URI 和相应资源类之间的清晰映射,以及 HTTP 方法与 Java 对象方法之间的映射。API 支持普遍的 HTTP 实体内容类型,包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能,以容许使用标准方法经过应用程序添加其余类型。
RESTful Web 服务和动态 Web 应用程序在许多方面都是相似的。有时它们提供相同或很是相似的数据和函数,尽管客户端的种类不一样。例如,在线电子商务分类网站为用户提供一个浏览器界面,用于搜索、查看和订购产品。若是还提供 Web 服务供公司、零售商甚至我的可以自动订购产品,它将很是有用。与大部分动态 Web 应用程序同样,Web 服务能够从多层架构的关注点分离中受益。业务逻辑和数据能够由自动客户端和 GUI 客户端共享。唯一的不一样点在于客户端的本质和中间层的表示层。此外,从数据访问中分离业务逻辑可实现数据库独立性,并为各类类型的数据存储提供插件能力。
图 1 展现了自动化客户端,包括 Java 和各类语言编写的脚本,这些语言包括 Python、Perl、Ruby、PHP 或命令行工具,好比 curl。在浏览器中运行且做为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列,由于它们都表明用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请求在头部包含方法信息,即 POST、GET、PUT 和 DELETE,这又将映射到 Resource Request Handler 中资源的相应操做。每一个请求都包含全部必需的信息,包括 Resource Request Handler 用来处理请求的凭据。
从 Web 服务客户端收到请求以后,Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 肯定全部概念性的实体,系统将这些实体做为资源公开,并为每一个资源分配一个唯一的 URI。可是,概念性的实体在该层是不存在的。它们存在于业务逻辑层。可使用 Jersey 或其余框架(好比 Restlet)实现 Resource Request Handler,它应该是轻量级的,将大量职责工做委托给业务层。
Ajax 和 RESTful Web 服务本质上是互为补充的。它们均可以利用大量 Web 技术和标准,好比 HTML、JavaScript、浏览器对象、XML/JSON 和 HTTP。固然也不须要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web 服务为 Ajax 提供了很是简单的 API 来处理服务器上资源之间的交互。
图 1 中的 Web 浏览器客户端做为 GUI 的前端,使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。Browser Requester Handler 可使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它从浏览器接受请求,从业务逻辑层请求服务,生成表示并对浏览器作出响应。表示供用户在浏览器中显示使用。表示不只包含内容,还包含显示的属性,好比 HTML 和 CSS。
业务规则能够集中到业务逻辑层,该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用,并能实现灵活和可扩展的架构。此外,因为未来可使用新的 REST 和 MVC 框架,实现它们变得更加容易,无需重写业务逻辑层。
数据访问层提供与数据存储层的交互,可使用 DAO 设计模式或者对象-关系映射解决方an(如 Hibernate、OJB 或 iBATIS)实现。做为替代方an,业务层和数据访问层中的组件能够实现为 EJB 组件,并取得 EJB 容器的支持,该容器能够为组件生命周期提供便利,管理持久性、事务和资源配置。可是,这须要一个听从 Java EE 的应用服务器(好比 JBoss),而且可能没法处理 Tomcat。该层的做用在于针对不一样的数据存储技术,从业务逻辑中分离数据访问代码。数据访问层还能够做为链接其余系统的集成点,能够成为其余 Web 服务的客户端。
数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统(包括遗留系统、事务处理系统和企业资源规划系统)。使用该架构,您能够开始看到 RESTful Web 服务的力量,它能够灵活地成为任何企业数据存储的统一 API,从而向以用户为中心的 Web 应用程序公开垂直数据,并自动化批量报告脚本。
RESTful架构有一些典型的设计误区。
最多见的一种设计错误,就是URI包含动词。由于"资源"表示一种实体,因此应该是名词,URI不该该有动词,动词应该放在HTTP协议中。
举例来讲,某个URI是/posts/show/1,其中show是动词,这个URI就设计错了,正确的写法应该是/posts/1,而后用GET方法表示show。
若是某些动做是HTTP动词表示不了的,你就应该把动做作成一种资源。好比网上汇款,从帐户1向帐户2汇款500元,错误的URI是:
POST /accounts/1/transfer/500/to/2
正确的写法是把动词transfer改为名词transaction,资源不能是动词,可是能够是一种服务:
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
另外一个设计误区,就是在URI中加入版本号:
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
由于不一样的版本,能够理解成同一种资源的不一样表现形式,因此应该采用同一个URI。版本号能够在HTTP请求头信息的Accept字段中进行区分(参见Versioning REST Services):
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0
客户端和服务器结构
链接协议具备无状态性
可以利用Cache机制增进性能
层次化的系统
随需代码 - Javascript (可选)
RESTful Web 服务(也称为 RESTful Web API)是一个使用HTTP并遵循REST原则的Web服务。
PUT 和 DELETE 方法是幂等方法。GET方法是安全方法 (不会对服务器端有修改,所以也是幂等的)。
不像基于SOAP的Web服务,RESTful Web服务并无的“正式”标准。 这是由于REST是一种架构,而SOAP只是一个协议。虽然REST不是一个标准,但在实现RESTful Web服务时可使用其余各类标准(好比HTTP,URL,XML,PNG等)。
(完)
理解RESTful架构 做者: 阮一峰
【推荐】