REST简介

REST或表示性状态转移是一种体系结构样式 ，或更简单地说，是一组约束。

我们将研究REST对Web应用施加的约束，但其中一些要点是：

• 统一接口：所有资源均由URI标识（请考虑：链接）
• 它依赖于无状态的客户端-服务器，可缓存的通信协议（请考虑：HTTP）。
• 通过一组标准方法与资源进行交互（请考虑：HTTP动词）

REST可以看作是RPC（远程过程调用）和Web服务协议（SOAP，WSDL等）之类的机制的轻量级替代方案，但它还远不止于此！ 毫不夸张地说，REST已用于指导现代Web体系结构的设计和开发。

REST一词由Roy Fielding于2000年在UC Irvine的博士论文中定义。

• 背景
• 什么是REST？
• HTTP
• 帽子
• 摘要
• 术语
• 资料来源，参考文献，书目

背景

万维网简史

早在1989年，蒂姆·伯纳斯·李（Tim Berners-Lee）首次提出了“ WorldWideWeb”项目。 Berners-Lee是瑞士大粒子物理实验室CERN的一名软件工程师。 许多科学家在欧洲核子研究组织（CERN）工作了一段时间，然后回到了自己在世界各地的实验室，因此他们需要能够共享和链接他们的研究文件。 为了促进这一点，Berners-Lee提出了三种将成为Web基础的技术：

• HTTP：超文本传输​​协议。 HTTP是用于通过Web交换信息的协议或一组正式规则。 它允许从整个Web检索链接的资源。
• HTML：超文本标记语言。 Web的发布格式，包括格式化文档以及链接到其他文档和资源的功能。
• URI：统一资源标识符。 Web上每种资源唯一的一种“地址”。

（我们在这里不打算深入研究HTML，而是将重点放在HTTP和一点URI上）

HTTP 1.0

HTTP的第一个文档版本是HTTP V0.9（1991），并且只有一个方法，即GET，它将向服务器发出请求，并且服务器将使用HTML页面进行响应。 这是一个好的开始，但是需要进行许多增强以支持Web的爆炸式普及。

因此，Berners-Lee与研究人员Roy Fielding等人合作开发了HTTP 1.0 。 HTTP 1.0将HTTP从琐碎的请求/响应应用程序转换为真正的消息传递协议。 它描述了HTTP的完整消息格式，并说明了如何将其用于客户端请求和服务器响应，并支持多种媒体类型。

不幸的是，随着Web使用的增加，HTTP 1.0的某些局限性越来越引起问题。 例如，针对每个资源请求建立到服务器的单独连接。 也缺少对缓存和代理的支持。

HTTP 1.1

跳到1994年。网络发展非常Swift。 那是一个令人兴奋的时刻。 万维网正成为流行语，并获得了大量的媒体报道。 诸如hotmail，yahoo，altavista之类的网站正在起飞。 Google甚至还不存在。

但是，建立Web的体系结构和技术开始在接缝处嘎吱作响。 因此，分别是MIT和UCI的研究人员的TBL，Fielding，以及来自Compaq，Xerox和Microsoft的其他许多领先的技术专家，都通过URI，HTTP上的IETF工作组共同指定和改进了WWW基础设施。和HTML。

通过这项工作， HTTP 1.1诞生了。

HTTP 1.1中引入的一些重大改进包括：

• 多主机名支持：允许一台Web服务器处理对许多不同虚拟主机的请求。
• 持久连接：允许客户端在单个TCP会话中发送多个文档请求。
• 部分资源选择：客户可以只请求一部分资源，而不是整个文档，从而减少了负载和所需的带宽
• 更好的缓存和代理支持
• 内容协商：允许客户端和服务器交换信息，以在多个资源可用时帮助选择最佳资源。
• 更好的安全性：定义身份验证方法，并且通常更加“安全意识”

HTTP 1.1的工作始于1994年，并于1997年正式发布。

今天使用什么版本的HTTP 1.1？ 还是25年后的1.1！ 考虑到技术变化的速度，这是一个了不起的成就。 您从事过多少个项目，它们经受了时间的考验？

得到教训

Fielding从一开始就涉足网络，并以用户和架构师的身份亲身经历了网络的快速发展。 他比大多数人更了解其成功的原因，因此，在HTTP1.1发行后，Fielding开始撰写他在HTTP和其他网络技术方面的工作经验（Fielding还参与了HTML的开发， URI，并且是Apache HTTP Server项目的共同创始人）。 他了解了Web的体系结构原理，并将其作为约束框架或他所说的体系结构样式来呈现。 具体而言，Fielding撰写了一篇博士论文，重点研究了现代Web体系结构设计的背后原理和关键体系结构原理。

菲尔丁的论文发表于2000年，名为《 体系结构样式和基于网络的软件体系结构设计》 。 我必须承认，我没有读过许多博士学位论文，但他的论文是其中最易读的。 它甚至包含Monty Python引号！

在介绍和定义术语REST之前，Fielding讨论了基于网络的应用程序体系结构和体系结构样式。 尽管在Fielding的论文中进行了介绍，但Fielding指出“ REST已用于指导现代Web体系结构的设计和开发”。 因此，尽管REST直到后来才出现，但它是HTTP背后的设计风格。 菲尔丁在他的论文中并没有“发明” REST，而是在与同事合作开发HTTP和URI时开发了REST，但是在他的论文中却创造了这个术语并定义了它。

菲尔丁试图通过解释其指导原则来回答为什么Web如此成功的平台的问题，以及在构建分布式系统时如何正确应用它们呢？

因此，要构建一个分布式Web应用程序吗？ 不确定要使用哪种架构？ 为什么不基于Web的体系结构呢！

在深入探讨REST是什么之前，请随时阅读最后的术语部分。

什么是REST？

REST是分布式超媒体系统的体系结构样式或一组约束。

约束条件

想象您正在设计高速公路。 您可能会强加诸如汽车之类的规则（禁止卡车，行人或自行车），所有交通必须以40至70 mph的速度行驶，并且不设交通信号灯（仅在匝道上下车）。 尽管这些规则限制了系统，但它们使系统整体运行更好。 在这种情况下，允许更多流量更自由，更快速地流动。

REST对Web应用程序或分布式超媒体系统施加了约束，以使这些应用程序能够按需扩展和执行。

菲尔丁建议的约束是什么？

1）客户端服务器

通过将用户界面问题与数据存储问题分开，我们提高了用户界面在多个平台上的可移植性，并通过简化服务器组件来提高可伸缩性。 分离还允许组件独立发展。

2）无状态

交流必须是无状态的。 从客户端到服务器的每个请求必须包含理解该请求所需的所有信息。 会话状态完全保留在客户端上。 可靠性得到改善，因为它简化了从部分故障中恢复的任务。 可伸缩性得到了改善，因为不必在请求之间存储状态，这使得服务器组件可以快速释放资源，并简化了实现。

3）快取

缓存约束要求将对请求的响应内的数据标记为可缓存或不可缓存。 如果响应是可缓存的，则授予客户端缓存以将响应数据重新用于以后的等效请求的权限。

4）统一接口

将REST架构样式与其他基于网络的样式区分开的主要特征是它强调组件之间的统一接口。 实施与提供的服务脱钩，从而鼓励了独立的可扩展性。

5）分层系统

分层的系统样式允许通过限制组件的行为来使体系结构由各层组成，从而使每个组件都无法“看到”与组件交互的直接层。

6）按需编码

REST约束集的最后增加来自按需编码样式。 REST允许通过下载和执行小程序或脚本形式的代码来扩展客户端功能。 通过减少预先实现的功能数量，简化了客户端。 部署后允许下载功能可改善系统扩展性。 但是，它也降低了可见性，因此仅是REST中的可选约束。

这些就是构成REST的约束。 接下来，HTTP。

HTTP

HTTP在Web体系结构中，特别是在REST中，扮演着非常特殊的角色。

但是请注意，REST不必使用HTTP。 还有其他一些应用程序级别的协议可能是与REST一起使用的候选协议： Gopher在Web的早期阶段就被广泛使用，尽管已被HTTP取代。 菲尔丁本人一直在研究一种名为waka的新的类似http的协议； Google还开发了一种称为SPDY的协议，其目的是减少网页加载延迟并提高网络安全性。

但是实际上，REST和HTTP是紧密相关的。 菲尔丁不仅介绍了REST，而且还是HTTP规范的主要作者之一，因此两者紧密联系也就不足为奇了。

我们将深入研究HTTP，并查看一些示例请求和响应以及常用的HTTP方法和响应代码。

示例请求

HTTP请求的示例：
GET /index.html HTTP / 1.1
主持人： www.example.com

它由以下组件组成：

• 方法：获取
• URI：/index.html
• 版本：HTTP / 1.1
• 标头：托管人： www.example.com
• 主体：在这种情况下为空

范例回应

版本/状态代码； 原因短语

HTTP/1.1 200 OK Version/Status code; Reason phrase
Date: Mon, 23 May 2005 22:38:34 GMT  HEADERS
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b"
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Accept-Ranges: bytes
Connection: close
 <html> BODY
   <head>
     <title>An Example Page</title>
   </head>
   <body>
     Hello World
   </body>
 </html>

在上面的请求示例中，动词是GET。 HTTP动词也称为方法，HTTP 1.1（ RFC 2616 ）支持8个动词。 首先，我们将看看4个最常用的动词：GET，PUT，DELETE和POST。 然后，我们将看看较少使用的：HEAD，OPTIONS，TRACE和CONNECT

但是，在深入研究这些方法之前，让我们看一下消息的某些特征或分组。 特别是安全方法和幂等性的概念。

HTTP方法

安全方法

安全方法是不修改资源的方法，它们仅用于检索。 （严格来说，某些情况可能会发生变化，例如日志，缓存等，但是所讨论的资源的表示形式不得更改）。
安全的方法有：HEAD，GET，OPTIONS和TRACE。 相比之下，诸如POST，PUT，DELETE和PATCH之类的非安全方法旨在在服务器上引起副作用。

幂等方法

幂等方法可以多次调用而不会产生不同的结果。 调用一次或一千次，结果将相同。 例如，乘以1是幂等运算。 赋值'a = 4;'也是如此

更正式地说，“方法还可以具有幂等性，因为（错误或过期问题除外）N> 0个相同请求的副作用与单个请求的副作用相同。” [7]

GET，HEAD，PUT和DELETE方法共享此属性。 同样，方法OPTIONS和TRACE不应有副作用，因此本质上是幂等的。

常用方法

现在，来看一下最常用的4个动词：GET，PUT，DELETE和POST

得到

检索由URI标识的资源。 最简单，最常用的方法！ 每次访问网页时都使用的那个。

放

将提供的实体存储在提供的URI下。 如果已经存在，请进行更新（并返回200 OK或204 No Content）。 如果未使用该URI创建（并返回“ 201 Created”响应）。

开机自检

请求接受该实体作为URI标识的资源的新下属。 例如

• 将表单中的数据提交到数据处理过程；
• 将消息发布到邮件列表或博客

用简单的英语创建资源。

删除

请求服务器删除URI标识的资源。

PUT与POST

好的，在继续讨论其他较少使用的HTTP动词之前，让我们看一下上面两个最容易混淆的常用动词：PUT和POST。

Office HTTP 1.1文档（RFC 2616）指出：

“ POST和PUT请求之间的根本区别体现在Request-URI的不同含义中。 POST请求中的URI标识将处理封闭实体的资源。 该资源可能是一个数据接受过程，某个其他协议的网关或一个接受注释的单独实体。 相比之下，PUT请求中的URI标识了请求中包含的实体-用户代理知道URI的含义，服务器不得尝试将请求应用于其他资源。”

但是，这有点令人！舌！

PUT和POST都可以用来创建或更新资源，但是这里有一些经验法则（有时是矛盾的！）：

• PUT用于更新； POST用于创建
• PUT等幂； POST不是；
• 谁创建资源的URL？
  • 当您知道要创建的事物的URL时，PUT用于创建。

• 还有一个最近的论点（例如，来自Thoughtworks的论点）说不要使用Put，而总是使用Post（并使用发布事件）。

简短的答案？ 没有简短的答案！ 用你最好的判断。

在此stackoverflow发布中查看一些有用的讨论。

不太常用的方法

其他四个较少使用的HTTP动词是：HEAD，OPTIONS，TRACE和CONNECT。

选项

请求有关服务器功能的信息，例如，请求可在该资源上使用的HTTP方法的列表。 看起来像这样：200 OK

允许：HEAD，GET，PUT，DELETE，OPTIONS

HTTP标准中有些晦涩的部分。 潜在有用，但几乎没有Web服务实际可用。

头

与GET相同，除了服务器在响应中不得返回消息正文。 用于获取有关请求所隐含的实体的元信息，而无需转移实体主体本身。

为什么使用？ 用于测试链接，例如有效性，可访问性。

跟踪

用于调用请求消息的远程应用层回送。 朴素的英语：回显收到的请求，以便客户端可以看到中间服务器所做的更改（如有）。 通常会禁用跟踪，因为这可能会带来安全风险。

连接

Connect与可以动态切换为隧道的代理一起使用。

将请求连接转换为透明的TCP / IP隧道 ，通常是为了通过未加密的HTTP代理促进SSL加密的通信（ HTTPS ）。

HTTP响应码

参见http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

码	含义	普通英语（从用户角度）
1xx	信息性； 表示临时响应，例如100	仅供参考，到目前为止还可以，客户应继续请求
2xx	成功的	都好
3xx	重新导向	有点感动
4xx	客户端错误	你搞砸了
5xx	服务器错误	我们搞砸了

为什么要使用REST和HTTP？

因为HTTP提供了REST所需的所有特征。

1. 客户端服务器

   Http是“客户端-服务器计算模型中的协议”，因此满足REST的第一个要求。 使用HTTP，客户端通常是Web浏览器，服务器通常是提供内容（例如Apache，IIS或Nginx）的软件。 然而，随着“物联网”的发展，事物变得不再那么传统。 客户可能是您的烤面包机！

2. 无状态

   HTTP是无状态协议。 不需要HTTP服务器在请求之间保留任何信息或状态。

   可以通过使用cookie和会话来避免这种情况，但是Fielding在其论文中明确指出，他强烈不同意cookie。

3. 快取

   HTTP通过三种基本机制支持缓存：新鲜度，验证和无效。

4. 统一界面

   使用接口将客户端/呼叫者与实现分离开来是软件上的常见概念。

   • 查明资源

     HTTP支持超链接。 任何感兴趣的东西都可以是资源，并且可以通过URI唯一地标识那些资源。

     您如何识别一本书？ example.com/books/1234

     您如何识别用户？ example.com/users/sabram

     所有资源均由统一的接口URI标识

   • 通过这些表示来操纵资源

     URI与HTTP方法结合可用于操纵资源。

   • 自我描述信息

     在HTTP中，消息可以使用媒体（MIME）类型，状态代码和标头来描述自身，例如，指示其可缓存性。

   • 超媒体作为应用程序状态的引擎（又名HATEOAS）

   以后再说！ 见下文。

   统一界面，用简单的英语。

   好的，这涵盖了Fielding在其关于统一接口的论文中不得不说的内容，但是用通俗的英语怎么说呢？

   我之前提到过，使用接口将客户端/调用者与实现分离开来是软件上的常见概念。 同样，在设计GUI时，理想情况下，您应该具有一个非常简单的用户界面，但是该界面仍然允许用户执行复杂的任务。 通常，一个理想的目标是为客户/用户提供所需的所有功能，同时隐藏实现的基础复杂性的简单接口是理想的目标，但很难实现。 但这正是Fielding使用REST实现的。 该接口只是一个链接（或更具体地说，是一个URI）！ 这是您可以想到的最简单的界面。

   结合其他HTTP功能（例如方法和媒体类型），您突然拥有了一种功能强大但看似简单且广为人知的传达意图的方法。

5. 分层系统

   分层系统背后的思想是，客户端不知道（或不在乎）客户端是连接到终端服务器还是连接到中间服务器。 此功能可以通过负载平衡和缓存等提高可伸缩性。层还可以实施安全策略。

   HTTP支持通过代理服务器和缓存进行分层。

6. 按需编码

   这实际上是REST中的可选约束。 例如，您可以请求资源，并使用一些JavaScript获取该资源。

帽子

客户知道该应用程序的一些简单的固定入口点，但除此之外没有其他知识。 相反，它们通过使用这些链接及其链接来转换（状态）。 换句话说，客户端根据服务器提供的选项来驱动状态转换。

如果您将Hypermedia视为简单的链接，那么“ Hypermedia作为应用程序状态的引擎”只是使用您发现的链接来导航（或转换状态）整个应用程序。

请记住，不必是用户单击链接。 它可以很容易地成为另一个启动状态转换的软件组件。

引用菲尔丁本人的话：

“代表性状态转移旨在唤起人们对精心设计的Web应用程序的行为的印象：

网页网络（虚拟状态机），用户通过选择链接（状态转换）来浏览应用程序，从而将下一页（代表应用程序的下一个状态）传输给用户并进行渲染他们的使用。”

摘要

什么是REST？

• 漂亮的网址？
• SOAP或RPC的替代品？

确实，它是捕获Web基础的基本原理的体系结构样式或一组约束。

REST的重点是简单性，并利用现有Web技术和标准（例如HTTP和URI）的功能

• 统一接口：所有资源均由URI标识
• HTTP方法：可以通过标准HTTP方法创建/访问/更新/删除所有资源
• 无状态：服务器上没有状态

术语

让我们定义一些与REST讨论相关的有用术语。

建筑

Wikipedia：软件体系结构是指软件系统的高层结构，创建此类结构的准则以及这些结构的文档。 软件系统的体系结构是一个隐喻，类似于建筑物的体系结构。

领域：软件体系结构是软件系统在其操作的某个阶段的运行时元素的抽象[1]。

Fowler：体系结构是对系统设计的共同理解，包括如何将系统划分为组件以及组件如何通过接口进行交互。 [3]

建筑风格

领域：建筑风格是一组命名的，协调的建筑约束，它限制了建筑元素的作用和特征[1]

建筑风格是建筑设计决策的命名集合，其（1）适用于给定的开发上下文；（2）约束特定于该上下文的特定系统的建筑设计决策；（3）在每个体系中都带来有益的品质。结果系统[4]

REST还是RESTful？

REST和RESTful术语有什么区别？ 从我所读的内容来看，并没有太大的区别。 我们知道REST是分布式软件的体系结构样式。 符合该建筑风格的服务。

符合REST约束的条件称为“ RESTful”。 或者换一种说法：REST是一个名词，RESTful是一个形容词。

超文本

纯文本：超文本是带有链接的文本。

维基百科 ：超文本是在计算机显示器或其他电子设备上显示的文本，带有指向读者可以立即访问的其他文本的引用（超链接），或者可以在多个详细级别逐步显示文本的地方。

罗伊·菲尔丁（Roy Fielding）：信息和控件的同时呈现，从而使信息成为提供能力，用户可以通过该能力获得选择并选择动作[幻灯片＃50]

超媒体

用简单的英语讲：交互式多媒体。 如果您在购物中心的摊位看到带有多媒体的视频，声音等。 如果您可以与之交互–单击链接，或使用按钮等控制内容，则它是超媒体。

维基百科 ：超媒体是超文本一词的扩展，是一种非线性的信息媒介，包括图形，音频，视频，纯文本和超链接。

Roy Fielding：超媒体是由嵌入在信息表示中或信息表示之上的应用程序控制信息来定义的。 [1]

资源资源

用简单的英语来说：资源可以是真实的，但是典型的例子是文件，网页，客户，帐户等。

维基百科 ：计算机系统中可用性有限的任何物理或虚拟组件。

罗伊·菲尔丁（Roy Fielding）：可以命名的任何信息都可以是资源：文档或图像，其他资源的集合，非虚拟对象（例如，人）。 换句话说，任何可能成为作者超文本引用目标的概念都必须符合资源的定义。 [1]

REST在实践中：资源是我们公开给Web的任何东西，从文档或视频剪辑到业务流程或设备。 从消费者的角度来看，资源是指在实现某个目标时消费者与之交互的任何事物。[6]

URI –统一资源标识符

Wikipedia ：用于标识资源名称的字符串

W3 ：统一资源标识符（URI，又称URL）是短字符串，用于标识Web中的资源：文档，图像，可下载文件，服务，电子邮箱和其他资源。

URI和URL有什么区别？

URI和URL之间的区别很细微，我认为不是很重要。 URI通过位置和/或名称标识资源。 URI不必指定特定表示的位置。 如果是的话，它也是一个URL。

统一资源定位符（URL）是统一资源标识符（URI）的子集，用于指定所标识资源的可用位置以及检索资源的机制。

因此，所有URL都是URI，但是所有URI都不是URL。 URI也可以是URN（通用资源名称）。

或者：URL和URN是URI的特殊形式。

在大多数情况下，我认为您可以认为URI和URL是同一回事。 我可能因为这样说而被炒鱿鱼，但这使事情变得更简单！

资料来源，参考文献，书目

1. 架构风格和基于网络的软件架构设计（Fielding，2000年）
2. 一点休息和放松（守场）
3. 谁需要建筑师？ （福勒）
4. 软件体系结构：基础，理论和实践； RN Taylor，N。Medvidović和EM Dashofy ，。 威利（Wiley），2009年。
5. 代表性状态转移（维基百科）
6. REST实践（Webber； Parastatidis； Robinson）
7. HTTP 1.1（RFC 2616）

翻译自: https://www.javacodegeeks.com/2014/11/an-introduction-to-rest.html