转载:关于对REST的基本认识和理解

1.什么是 REST?

REST 是属于 WEB 自身的一种架构风格，是在 HTTP 1.1 规范下实现的。Representational State Transfer 全称翻译为表现层状态转化。Resource：资源。好比 newsfeed；Representational：表现形式，好比用JSON，富文本等；State Transfer：状态变化。经过HTTP 动做实现。

REST是全部Web应用都应该遵照的架构设计指导原则。固然，REST并非法律，违反了REST的指导原则，仍然可以实现应用的功能。可是违反了REST的指导原则，会付出不少代价，特别是对于大流量的网站而言。

 

2.REST架构风格最重要的架构约束有6个：

• 客户-服务器（Client-Server）

通讯只能由客户端单方面发起，表现为请求-响应的形式。

• 无状态（Stateless）

通讯的会话状态（Session State）应该所有由客户端负责维护。

• 缓存（Cache）

响应内容能够在通讯链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）

通讯链的组件之间经过统一的接口相互通讯，以提升交互的可见性。

• 分层系统（Layered System）

经过限制组件的行为（即，每一个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

• 按需代码（Code-On-Demand，可选）

支持经过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

 

3.要深刻理解REST，须要理解REST的五个关键词：

1. 资源（Resource）
2. 资源的表述（Representation）
3. 状态转移（State Transfer）
4. 统一接口（Uniform Interface）
5. 超文本驱动（Hypertext Driven）

6. 什么是资源？

   资源是一种看待服务器的方式，即，将服务器看做是由不少离散的资源组成。每一个资源是服务器上一个可命名的抽象概念。由于资源是一个抽象的概念，因此它不只仅能表明服务器文件系统中的一个文件、数据库中的一张表等等具体的东西，能够将资源设计的要多抽象有多抽象，只要想象力容许并且客户端应用开发者可以理解。与面向对象设计相似，资源是以名词为核心来组织的，首先关注的是名词。一个资源能够由一个或多个URI来标识。URI既是资源的名称，也是资源在Web上的地址。对某个资源感兴趣的客户端应用，能够经过资源的URI与其进行交互。

   什么是资源的表述？

   资源的表述是一段对于资源在某个特定时刻的状态的描述。能够在客户端-服务器端之间转移（交换）。资源的表述能够有多种格式，例如HTML/XML/JSON/纯文本/图片/视频/音频等等。资源的表述格式能够经过协商机制来肯定。请求-响应方向的表述一般使用不一样的格式。

   什么是状态转移？

   状态转移（state transfer）与状态机中的状态迁移（state transition）的含义是不一样的。状态转移说的是：在客户端和服务器端之间转移（transfer）表明资源状态的表述。经过转移和操做资源的表述，来间接实现操做资源的目的。

   什么是统一接口？

   REST要求，必须经过统一的接口来对资源执行各类操做。对于每一个资源只能执行一组有限的操做。以HTTP/1.1协议为例，HTTP/1.1协议定义了一个操做资源的统一接口，主要包括如下内容：

   • 7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

   • HTTP头信息（可自定义）

   • HTTP响应状态代码（可自定义）

   • 一套标准的内容协商机制

   • 一套标准的缓存机制

   • 一套标准的客户端身份认证机制

   REST还要求，对于资源执行的操做，其操做语义必须由HTTP消息体以前的部分彻底表达，不能将操做语义封装在HTTP消息体内部。这样作是为了提升交互的可见性，以便于通讯链的中间组件实现缓存、安全审计等等功能。

   什么是超文本驱动？

   “超文本驱动”又名“将超媒体做为应用状态的引擎”（Hypermedia As The Engine Of Application State，来自Fielding博士论文中的一句话，缩写为HATEOAS）。将Web应用看做是一个由不少状态（应用状态）组成的有限状态机。资源之间经过超连接相互关联，超连接既表明资源之间的关系，也表明可执行的状态迁移。在超媒体之中不只仅包含数据，还包含了状态迁移的语义。以超媒体做为引擎，驱动Web应用的状态迁移。经过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运行时经过解析超媒体发现的，而不是事先定义的。从面向服务的角度看，超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义，而不该该对因而否存在某个URI或URI的某种特殊构造方式做出假设。一切都有可能变化，只有超媒体的状态迁移语义可以长期保持稳定。

 

1. 从架构风格的抽象高度来看，常见的分布式应用架构风格有三种：

2. • 分布式对象（Distributed Objects，简称DO）

   架构实例有CORBA/RMI/EJB/DCOM/.NET Remoting等等

   • 远程过程调用（Remote Procedure Call，简称RPC）

   架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等

• 表述性状态转移（Representational State Transfer，简称REST）

3. 架构实例有HTTP/WebDAV

   DO和RPC这两种架构风格在企业应用中很是广泛，而REST则是Web应用的架构风格，它们之间有很是大的差异。

   REST与DO的差异在于：

   • REST支持抽象（即建模）的工具是资源，DO支持抽象的工具是对象。在不一样的编程语言中，对象的定义有很大差异，因此DO风格的架构一般都是与某种编程语言绑定的。跨语言交互即便能实现，实现起来也会很是复杂。而REST中的资源，则彻底中立于开发平台和编程语言，可使用任何编程语言来实现。

   • DO中没有统一接口的概念。不一样的API，接口设计风格能够彻底不一样。DO也不支持操做语义对于中间组件的可见性。

   • DO中没有使用超文本，响应的内容中只包含对象自己。REST使用了超文本，能够实现更大粒度的交互，交互的效率比DO更高。

   • REST支持数据流和管道，DO不支持数据流和管道。

   • DO风格一般会带来客户端与服务器端的紧耦合。在三种架构风格之中，DO风格的耦合度是最大的，而REST的风格耦合度是最小的。REST松耦合的源泉来自于统一接口+超文本驱动。

   REST与RPC的差异在于：

   • REST支持抽象的工具是资源，RPC支持抽象的工具是过程。REST风格的架构建模是以名词为核心的，RPC风格的架构建模是以动词为核心的。简单类比一下，REST是面向对象编程，RPC则是面向过程编程。

   • RPC中没有统一接口的概念。不一样的API，接口设计风格能够彻底不一样。RPC也不支持操做语义对于中间组件的可见性。

   • RPC中没有使用超文本，响应的内容中只包含消息自己。REST使用了超文本，能够实现更大粒度的交互，交互的效率比RPC更高。

   • REST支持数据流和管道，RPC不支持数据流和管道。

   • 由于使用了平台中立的消息，RPC风格的耦合度比DO风格要小一些，可是RPC风格也经常会带来客户端与服务器端的紧耦合。支持统一接口+超文本驱动的REST风格，能够达到最小的耦合度。

   比较了三种架构风格之间的差异以后，从面向实用的角度来看，REST架构风格能够为Web开发者带来三方面的利益：

   • 简单性

   采用REST架构风格，对于开发、测试、运维人员来讲，都会更简单。能够充分利用大量HTTP服务器端和客户端开发库、Web功能测试/性能测试工具、HTTP缓存、HTTP代理服务器、防火墙。这些开发库和基础设施早已成为了平常用品，不须要什么火箭科技（例如神奇昂贵的应用服务器、中间件）就能解决大多数可伸缩性方面的问题。

   • 可伸缩性

   充分利用好通讯链各个位置的HTTP缓存组件，能够带来更好的可伸缩性。其实不少时候，在Web前端作性能优化，产生的效果不亚于仅仅在服务器端作性能优化，可是HTTP协议层面的缓存经常被一些资深的架构师彻底忽略掉。

   • 松耦合

   统一接口+超文本驱动，带来了最大限度的松耦合。容许服务器端和客户端程序在很大范围内，相对独立地进化。对于设计面向企业内网的API来讲，松耦合并非一个很重要的设计关注点。可是对于设计面向互联网的API来讲，松耦合变成了一个必选项，不只在设计时应该关注，并且应该放在最优先位置。

4. 转载自：http://www.infoq.com/cn/articles/understanding-restful-style