数据API 数据治理 会员 案例 开发者
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

Web如何工作第三部分:HTTP & REST – freeCodeCamp

本文由starlee 在众成翻译平台上翻译。

我们在第一部分讲了基本的Web架构,在第二部分讨论了Web应用程序结构。现在是时候卷起袖子处理第三部分了:细究HTTP和REST。

理解HTTP对于Web开发者人员至关重要,因为它促进了Web应用程序中的信息流动 —— 允许更好的用户交互和改进了站点性能。

什么是 HTTP?

在客户端-服务器模型中,客户端和服务器以“请求-响应”消息模式交换消息:客户端发送一个请求,服务器返回响应。

跟踪这些消息比听起来要复杂得多,因此客户端和服务器遵循一种公共的语言和规则集,这样他们就知道该怎么做了。这个语言或“协议”被叫做HTTP。

HTTP协议定义了语法(数据结构和编码)、语义(与语法相关的含义)和时间(速度和排序)。每一次在客户端和服务端的HTTP请求和响应被看做一个单一的HTTP事务。

HTTP 粗略描述

在深入了解细节之前,有一些关于HTTP的事情值得注意。

首先,HTTP是基于文本的,这意味着在客户端和服务端交换的信息是一些文本。每一条信息包含两个部分:头部和主体。

其次,HTPP是一个应用层协议,这意味着它只是一个标准化主机通信方式的抽象层。HTTP本身不能传输数据。它仍然依赖底层的TCP/IP协议来从一个机器得到另外一个机器的请求和响应。

(提醒一下,TCP/IP是一个两部分的系统,是互联网基础的“控制系统”功能。更多TCP/IP内容,查看第一部分

最后,你也许在你的浏览器地址栏看到过“HTTPS”协议,并且想知道HTTP和HTTP+“S”是否相同。简短的回答是有点,有轻微的差异。

一个简单的HTTP请求或响应是未加密的,并且容易受到各种类型的安全攻击。另一方面,HTTPS是一个更加安全的通信,它使用加密来保证安全。它代表HTTP/TLS/SSL。

SSL是一个安全协议,它给予客户端和服务端以一种安全的方式进行网络通信 —— 阻止监听和篡改 —— 当信息在网络中传播时。

客户端通常通过使用一个特殊的端口号:443 来表明是否需要TLS/SSL连接。一旦客户端和服务端同意使用TLS/SSL通信,它们通过执行被叫做“TLS握手协议”来协商一个有状态的通信。客户端和服务端之后会建立会话密钥,它们可以在彼此交互时使用这个密钥加密和解密信息。

许多像Google和Facebook的主要网站使用THTPS,毕竟它能保证你的密码、私人信息、信用卡信息在网络上安全。

HTTP 细致描述

有了这些基础知识,让我们深入了解HTTP的结构。

我们可以先通过访问 https://www.github.com 来与 Github 服务器进行通信。如果你使用的是安装了 Firebug 拓展程序的谷歌或者火狐浏览器,你可以通过“网络”选项卡来查看HTTP请求的详细信息。如果你打开了这个网站,然后访问 www.github.com 在地址栏输入它,你应该看到像这样的东西:

然后在左边的面板,点击第一个路径, “github.com”。你现在应该看到这个:

HTTP 请求头

HTTP 头部主要包含元数据(关于数据的数据)。元数据包含请求类型(GET vs POST vs PUT VS DELETE)、路径、状态码,内容类型、用户代理、cookie、post主体(有时),等等。

让我们深入了解使用 Github 最重要的部分,从“响应头”一节开始:

  • Request URL:https://github.com/

  • 我们请求的URL

  • Request Method:GET

  • 使用HTTP方法的类型。在我们的案列中,我们的浏览器说:“嘿,Github 的浏览器,带我到你的主页。”

  • Status Code:200 OK

  • 一种标准化的方式,服务器告诉客户端请求的结果。状态码200意味着服务器成功的找到了资源,并且把它发送给你。

  • Remote Address:192.30.252.129:443

  • 我们访问的 Github 网站的 IP 地址和端口号。注意,它是端口443(这意味着我们正在用 HTTPS 而不是 HTTP)。

  • Content-Encoding:gzip

  • 我们收到的返回资源的编码。在我们的案例中, Github 的服务器告诉我们,它发送返回的内容是压缩过的。Github可能会压缩文件,这样你就可以有更快的下载时间。

  • Content-Type:text/HTML; charset=utf-8

  • 指定响应主体的数据表现,包括类型和子类型。类型描述了数据类型,子类型指定这种数据类型的特定格式。在我们的案列中,我们将文本以 HTML 的形式发送回来。

  • 第二部分指定HTML文档的字符编码。这通常是UTF-8,就像上图的例子一样。

还有一堆消息头信息,客户端必须发送这些信息,以便服务端能够知道如何回应。看看下面的“请求头”部分:

  • User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36

  • 代表用户进行操作的软件。有时候一个网站需要知道它是如何被浏览的。所以浏览器发送这个用户代理字符串以便于服务器可以使用它来决定访问网站的内容。

  • Accept-Encoding:gzip, deflate, sdch

  • 指定浏览器愿意接受的内容编码。我们看到gzip被列出来了,这就是为什么Github的服务器能够以gzip格式的向我们发送信息。

  • Accept-Language:en-US,en;q=0.8

  • 描述我们想要的网页语言。在我们的案例中,“en” 代表英语。

  • Host:github.com

  • 自身说明 :)

  • Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay;_gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz=America%2FLos_Angeles

  • web服务器可以存储在用户机器上的一段文本,然后再进行检索。信息以名称-值对储存。例如,Github为我的请求储存的一个名称-值对是“dotcom_user=iam-peekay”,这告诉 Github 我的用户名是“iam-peekay”。

这些名称-值对是什么?

长话短说,我们留下了很多名称-值对,但是这些名称-值对是如何被创建的呢?

无论什么时候,你浏览一个网站,它会在你的电脑上找到一个网站提前设置的cookie文件。

因此如我我正在浏览 www.github.com, 我的浏览器将会寻找 Github 已经保存在我的硬盘中的cookie文件。如果他找到一个 cookie 文件,它将会在响应头布发送所有的名称-值对。

Github 的 web 服务器现在能够用很多不同的方法使用这个 cookie 数据。例如基于我储存的用户设定来呈现内容,计算我访问他们的网站的时间数量。

如果浏览器没有发现cookie文件 —— 要么是因为这个网站在之前从来没有被访问过,要么因为用户屏蔽或者删除了它 —— 浏览器不会发送任何cookie数据。

在这个案列,Github 的服务器创建了一个新的 ID,作为名称-值对,与它想要的任何其他的名称-值对一起,并且通过 HTTP 头部发送到我的计算机上,然后我的计算机将它们储存在硬盘里。

HTTP 主体

正如你上面所看的,服务器拥有与客户端通信所需要的大部分重要的元数据(关于数据的数据)。

现在到主体来。

不难猜到,主体是信息的主体。基于请求的类型,它可能是空的。

在我们的案例中,你可以看到 “Response” 选项卡的主体。因为我们发送了一个 GET 请求到 www.github.com,, 它的主体包含 www.github.com, 的 HTML 页面内容。

当然,这对显示页面是非常重要的。

附加练习

我希望这能让你更好的理解HTTP的结构。在实践中,当你浏览 www.github.com 时,你可以查看你的浏览器请求的所有其他的资源(图片、javascripts 文件、等等)。

有了这一点,让我们看一下一个客户端能够发起的各种HTTP的方式。

HTTP 方法

HTTP动词或方法,告诉服务器如何处理被URL标识的数据。URLs 综合被标记为特定的资源,当客户端使用一个URL与一个HTTP动词结合使用时,这将告诉服务器需要在哪个资源上执行操作。

URL的示例包括:

当客户端发出请求时,它将使用这些动词指示请求的类型。最重要的是 GET、POST、PUT 和 DELETE 。还有其他的方法,比如 HEAD 和 OPTIONS,但是它们比较少见,所以我们跳过这篇文章。

GET

GET 是最经常使用的方法。它用来从服务端读取给定 URL 的信息。

GET 请求是只读的,这意味着在服务端数据不予许被修改 —— 服务端应该简单检索数据不被改变。 用这种方法,GET 请求被认为是安全的操作,因为调用一次,或者调用20次,将会得到相同的结果。

此外,GET 请求是幂等的,这意味着提交大量的 GET 请求到相同的 URL 应该会产生与一个 GET 请求相同的效果,因为一个 GET 请求只是向服务端请求数据并没有实际改变任何服务端的数据。

如果资源被成功找到,GET 请求会响应一个 200(ok)状态码。如果资源没被找到,返回 404(未找到)。(因此,“404页面”是访问已关闭或错误类型的url时错误消息的术语)

Github 著名的星球大战主题的404页面

POST

POST 用于创建一个新资源,例如一个注册表单。当您想要创建一个从属资源(例如一个新用户)到另一个父资源(http://example.com/users),您可以使用POST。您的post到这个由URL标识的父资源,服务器处理新资源并将其与父节点关联。

POST 既不安全也不是幂等的。这是因为发送两个或更多相同的 POST 请求将可能引起两个相同的新资源被创建。

POST请求与状态代码201(创建)一起响应,并带有指向新创建资源的链接的位置标题。

PUT

PUT用于使用请求主体中的信息更新URL标识的资源。PUT 也能用于创建一根新的文件。PUT 请求不被认为是安全的操作,因为它在服务端修改状态。然而它是幂等的,因为大量相同的 PUT 请求去更新一个资源,应该和第一个有相同的效果。

如果资源成功更新,PUT 请求响应一个200(ok)状态码,如果资源没有发现,响应404(未发现)。

DELETE

DELETE 用于删除URL标识的资源。DELETE 请求是幂等的,因为你删除一个资源,他会被删除,即使你有很多个 DELETE 请求,结果都是相同的:一个文件被删除。

如果您在同一资源中多次发送一个删除请求,您可能会只得到一个404错误消息,因为一旦被删除,服务器将无法找到它。

如果成功删除删除请求会响应200(OK)状态码,如果资源已经被删除不能找到,返回404(未发现)。

如果处理失败和服务器错误,上述所有请求将返回一个500(内部服务器错误)。

究竟什么是 REST ?

在我们讲了一天的 ERST 之前,我有最后一个术语要讲。

您可能已经听说过“ RESTful 应用程序”这个术语。明白它的意思是重要的,因为如果你正在客户端和服务端使用 HTTP 通信, 遵循 REST 知道是有益的。(事实上,我们上面定义的 HTTP 动词代表了大部分 REST 内容)。

REST代表“具象状态转移”。这是设计应用程序的架构风格。

基本思想是用一个“无状态”、“客户端-服务端”、“可缓存”协议在机器间进行调用,通常情况下,这种协议是 HTTP。这只是一种奇特的说法,REST 给您提供了一组约束来设计应用程序。这些约束有助于使系统更高效、可伸缩、简单、可修改、可见、可移植和可靠。

完整的约束列表是冗长的,你可以在这里阅读更多关于它。为了这篇文章,我想双击最重要的两个:

  1. 统一接口: 这个约束告诉你怎样在客户端和服务端间以一种简化和分离体系结构的方式定义接口。它写到:

  2. 资源请求中必须是可辨识的(例如在URI中使用资源标识符)。资源(例如数据库数据)是定义资源表象的数据(例如JSON,HTML)。资源和资源表象是分离的 —— 客户端只能与资源表象进行交互。

  3. 客户端必须有足够的信息来使用资源的表象来操作服务端上的资源。

  4. 客客户端和服务端之间交换的每一条消息都需要具有自描述性,以及如何处理消息的信息。

  5. 客户端必须使用HTTP主体内容、HTTP请求头、查询参数和URL发送状态数据。服务器必须使用HTTP主体内容、响应代码和响应头发送状态数据

  6. 注意:上面描述的HTTP动词构成了这个“统一接口”约束的主要部分,因为它们代表了资源上的一致动作。

2. 无状态: 这个约束表示需要处理客户端请求的所有状态数据必须包含在请求本身(RUL,查询数据,HTTP 的主体或者 HTTP 头),服务器必须通过响应本身(HTTP头、状态码和HTTP响应体)将所有需要返回给客户端的状态数据发送给客户端。

旁注: 状态或者应用程序状态对于一个服务端的完成请求是必要的数据。

这意味着对于每一个请求,我们会来回的发送状态信息,这样,服务端就不用维护、更新和发送状态了。

拥有这样一个无状态的系统使应用程序更具可伸缩性,因为没有服务端需要担心在多次的请求范围内维持相同的会话状态。获取状态数据所需的所有信息都可以在请求和响应本身中获得。

结束语

啧! HTTP 远非那么简单。但正如您所看到的,它是客户端-服务端关系的一个关键组成部分。

使用RESTful应用程序至少需要对HTTP有基本的了解。有了这些内容,您就可以很好的在您的下一个编码项目中破译客户端-服务端通信的秘密了。

原文来自:众成翻译

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
Web如何工作第三部分:HTTP & REST – freeCodeCamp
发布:2017-09-22

本文由starlee 在众成翻译平台上翻译。

我们在第一部分讲了基本的Web架构,在第二部分讨论了Web应用程序结构。现在是时候卷起袖子处理第三部分了:细究HTTP和REST。

理解HTTP对于Web开发者人员至关重要,因为它促进了Web应用程序中的信息流动 —— 允许更好的用户交互和改进了站点性能。

什么是 HTTP?

在客户端-服务器模型中,客户端和服务器以“请求-响应”消息模式交换消息:客户端发送一个请求,服务器返回响应。

跟踪这些消息比听起来要复杂得多,因此客户端和服务器遵循一种公共的语言和规则集,这样他们就知道该怎么做了。这个语言或“协议”被叫做HTTP。

HTTP协议定义了语法(数据结构和编码)、语义(与语法相关的含义)和时间(速度和排序)。每一次在客户端和服务端的HTTP请求和响应被看做一个单一的HTTP事务。

HTTP 粗略描述

在深入了解细节之前,有一些关于HTTP的事情值得注意。

首先,HTTP是基于文本的,这意味着在客户端和服务端交换的信息是一些文本。每一条信息包含两个部分:头部和主体。

其次,HTPP是一个应用层协议,这意味着它只是一个标准化主机通信方式的抽象层。HTTP本身不能传输数据。它仍然依赖底层的TCP/IP协议来从一个机器得到另外一个机器的请求和响应。

(提醒一下,TCP/IP是一个两部分的系统,是互联网基础的“控制系统”功能。更多TCP/IP内容,查看第一部分

最后,你也许在你的浏览器地址栏看到过“HTTPS”协议,并且想知道HTTP和HTTP+“S”是否相同。简短的回答是有点,有轻微的差异。

一个简单的HTTP请求或响应是未加密的,并且容易受到各种类型的安全攻击。另一方面,HTTPS是一个更加安全的通信,它使用加密来保证安全。它代表HTTP/TLS/SSL。

SSL是一个安全协议,它给予客户端和服务端以一种安全的方式进行网络通信 —— 阻止监听和篡改 —— 当信息在网络中传播时。

客户端通常通过使用一个特殊的端口号:443 来表明是否需要TLS/SSL连接。一旦客户端和服务端同意使用TLS/SSL通信,它们通过执行被叫做“TLS握手协议”来协商一个有状态的通信。客户端和服务端之后会建立会话密钥,它们可以在彼此交互时使用这个密钥加密和解密信息。

许多像Google和Facebook的主要网站使用THTPS,毕竟它能保证你的密码、私人信息、信用卡信息在网络上安全。

HTTP 细致描述

有了这些基础知识,让我们深入了解HTTP的结构。

我们可以先通过访问 https://www.github.com 来与 Github 服务器进行通信。如果你使用的是安装了 Firebug 拓展程序的谷歌或者火狐浏览器,你可以通过“网络”选项卡来查看HTTP请求的详细信息。如果你打开了这个网站,然后访问 www.github.com 在地址栏输入它,你应该看到像这样的东西:

然后在左边的面板,点击第一个路径, “github.com”。你现在应该看到这个:

HTTP 请求头

HTTP 头部主要包含元数据(关于数据的数据)。元数据包含请求类型(GET vs POST vs PUT VS DELETE)、路径、状态码,内容类型、用户代理、cookie、post主体(有时),等等。

让我们深入了解使用 Github 最重要的部分,从“响应头”一节开始:

  • Request URL:https://github.com/

  • 我们请求的URL

  • Request Method:GET

  • 使用HTTP方法的类型。在我们的案列中,我们的浏览器说:“嘿,Github 的浏览器,带我到你的主页。”

  • Status Code:200 OK

  • 一种标准化的方式,服务器告诉客户端请求的结果。状态码200意味着服务器成功的找到了资源,并且把它发送给你。

  • Remote Address:192.30.252.129:443

  • 我们访问的 Github 网站的 IP 地址和端口号。注意,它是端口443(这意味着我们正在用 HTTPS 而不是 HTTP)。

  • Content-Encoding:gzip

  • 我们收到的返回资源的编码。在我们的案例中, Github 的服务器告诉我们,它发送返回的内容是压缩过的。Github可能会压缩文件,这样你就可以有更快的下载时间。

  • Content-Type:text/HTML; charset=utf-8

  • 指定响应主体的数据表现,包括类型和子类型。类型描述了数据类型,子类型指定这种数据类型的特定格式。在我们的案列中,我们将文本以 HTML 的形式发送回来。

  • 第二部分指定HTML文档的字符编码。这通常是UTF-8,就像上图的例子一样。

还有一堆消息头信息,客户端必须发送这些信息,以便服务端能够知道如何回应。看看下面的“请求头”部分:

  • User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36

  • 代表用户进行操作的软件。有时候一个网站需要知道它是如何被浏览的。所以浏览器发送这个用户代理字符串以便于服务器可以使用它来决定访问网站的内容。

  • Accept-Encoding:gzip, deflate, sdch

  • 指定浏览器愿意接受的内容编码。我们看到gzip被列出来了,这就是为什么Github的服务器能够以gzip格式的向我们发送信息。

  • Accept-Language:en-US,en;q=0.8

  • 描述我们想要的网页语言。在我们的案例中,“en” 代表英语。

  • Host:github.com

  • 自身说明 :)

  • Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay;_gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz=America%2FLos_Angeles

  • web服务器可以存储在用户机器上的一段文本,然后再进行检索。信息以名称-值对储存。例如,Github为我的请求储存的一个名称-值对是“dotcom_user=iam-peekay”,这告诉 Github 我的用户名是“iam-peekay”。

这些名称-值对是什么?

长话短说,我们留下了很多名称-值对,但是这些名称-值对是如何被创建的呢?

无论什么时候,你浏览一个网站,它会在你的电脑上找到一个网站提前设置的cookie文件。

因此如我我正在浏览 www.github.com, 我的浏览器将会寻找 Github 已经保存在我的硬盘中的cookie文件。如果他找到一个 cookie 文件,它将会在响应头布发送所有的名称-值对。

Github 的 web 服务器现在能够用很多不同的方法使用这个 cookie 数据。例如基于我储存的用户设定来呈现内容,计算我访问他们的网站的时间数量。

如果浏览器没有发现cookie文件 —— 要么是因为这个网站在之前从来没有被访问过,要么因为用户屏蔽或者删除了它 —— 浏览器不会发送任何cookie数据。

在这个案列,Github 的服务器创建了一个新的 ID,作为名称-值对,与它想要的任何其他的名称-值对一起,并且通过 HTTP 头部发送到我的计算机上,然后我的计算机将它们储存在硬盘里。

HTTP 主体

正如你上面所看的,服务器拥有与客户端通信所需要的大部分重要的元数据(关于数据的数据)。

现在到主体来。

不难猜到,主体是信息的主体。基于请求的类型,它可能是空的。

在我们的案例中,你可以看到 “Response” 选项卡的主体。因为我们发送了一个 GET 请求到 www.github.com,, 它的主体包含 www.github.com, 的 HTML 页面内容。

当然,这对显示页面是非常重要的。

附加练习

我希望这能让你更好的理解HTTP的结构。在实践中,当你浏览 www.github.com 时,你可以查看你的浏览器请求的所有其他的资源(图片、javascripts 文件、等等)。

有了这一点,让我们看一下一个客户端能够发起的各种HTTP的方式。

HTTP 方法

HTTP动词或方法,告诉服务器如何处理被URL标识的数据。URLs 综合被标记为特定的资源,当客户端使用一个URL与一个HTTP动词结合使用时,这将告诉服务器需要在哪个资源上执行操作。

URL的示例包括:

当客户端发出请求时,它将使用这些动词指示请求的类型。最重要的是 GET、POST、PUT 和 DELETE 。还有其他的方法,比如 HEAD 和 OPTIONS,但是它们比较少见,所以我们跳过这篇文章。

GET

GET 是最经常使用的方法。它用来从服务端读取给定 URL 的信息。

GET 请求是只读的,这意味着在服务端数据不予许被修改 —— 服务端应该简单检索数据不被改变。 用这种方法,GET 请求被认为是安全的操作,因为调用一次,或者调用20次,将会得到相同的结果。

此外,GET 请求是幂等的,这意味着提交大量的 GET 请求到相同的 URL 应该会产生与一个 GET 请求相同的效果,因为一个 GET 请求只是向服务端请求数据并没有实际改变任何服务端的数据。

如果资源被成功找到,GET 请求会响应一个 200(ok)状态码。如果资源没被找到,返回 404(未找到)。(因此,“404页面”是访问已关闭或错误类型的url时错误消息的术语)

Github 著名的星球大战主题的404页面

POST

POST 用于创建一个新资源,例如一个注册表单。当您想要创建一个从属资源(例如一个新用户)到另一个父资源(http://example.com/users),您可以使用POST。您的post到这个由URL标识的父资源,服务器处理新资源并将其与父节点关联。

POST 既不安全也不是幂等的。这是因为发送两个或更多相同的 POST 请求将可能引起两个相同的新资源被创建。

POST请求与状态代码201(创建)一起响应,并带有指向新创建资源的链接的位置标题。

PUT

PUT用于使用请求主体中的信息更新URL标识的资源。PUT 也能用于创建一根新的文件。PUT 请求不被认为是安全的操作,因为它在服务端修改状态。然而它是幂等的,因为大量相同的 PUT 请求去更新一个资源,应该和第一个有相同的效果。

如果资源成功更新,PUT 请求响应一个200(ok)状态码,如果资源没有发现,响应404(未发现)。

DELETE

DELETE 用于删除URL标识的资源。DELETE 请求是幂等的,因为你删除一个资源,他会被删除,即使你有很多个 DELETE 请求,结果都是相同的:一个文件被删除。

如果您在同一资源中多次发送一个删除请求,您可能会只得到一个404错误消息,因为一旦被删除,服务器将无法找到它。

如果成功删除删除请求会响应200(OK)状态码,如果资源已经被删除不能找到,返回404(未发现)。

如果处理失败和服务器错误,上述所有请求将返回一个500(内部服务器错误)。

究竟什么是 REST ?

在我们讲了一天的 ERST 之前,我有最后一个术语要讲。

您可能已经听说过“ RESTful 应用程序”这个术语。明白它的意思是重要的,因为如果你正在客户端和服务端使用 HTTP 通信, 遵循 REST 知道是有益的。(事实上,我们上面定义的 HTTP 动词代表了大部分 REST 内容)。

REST代表“具象状态转移”。这是设计应用程序的架构风格。

基本思想是用一个“无状态”、“客户端-服务端”、“可缓存”协议在机器间进行调用,通常情况下,这种协议是 HTTP。这只是一种奇特的说法,REST 给您提供了一组约束来设计应用程序。这些约束有助于使系统更高效、可伸缩、简单、可修改、可见、可移植和可靠。

完整的约束列表是冗长的,你可以在这里阅读更多关于它。为了这篇文章,我想双击最重要的两个:

  1. 统一接口: 这个约束告诉你怎样在客户端和服务端间以一种简化和分离体系结构的方式定义接口。它写到:

  2. 资源请求中必须是可辨识的(例如在URI中使用资源标识符)。资源(例如数据库数据)是定义资源表象的数据(例如JSON,HTML)。资源和资源表象是分离的 —— 客户端只能与资源表象进行交互。

  3. 客户端必须有足够的信息来使用资源的表象来操作服务端上的资源。

  4. 客客户端和服务端之间交换的每一条消息都需要具有自描述性,以及如何处理消息的信息。

  5. 客户端必须使用HTTP主体内容、HTTP请求头、查询参数和URL发送状态数据。服务器必须使用HTTP主体内容、响应代码和响应头发送状态数据

  6. 注意:上面描述的HTTP动词构成了这个“统一接口”约束的主要部分,因为它们代表了资源上的一致动作。

2. 无状态: 这个约束表示需要处理客户端请求的所有状态数据必须包含在请求本身(RUL,查询数据,HTTP 的主体或者 HTTP 头),服务器必须通过响应本身(HTTP头、状态码和HTTP响应体)将所有需要返回给客户端的状态数据发送给客户端。

旁注: 状态或者应用程序状态对于一个服务端的完成请求是必要的数据。

这意味着对于每一个请求,我们会来回的发送状态信息,这样,服务端就不用维护、更新和发送状态了。

拥有这样一个无状态的系统使应用程序更具可伸缩性,因为没有服务端需要担心在多次的请求范围内维持相同的会话状态。获取状态数据所需的所有信息都可以在请求和响应本身中获得。

结束语

啧! HTTP 远非那么简单。但正如您所看到的,它是客户端-服务端关系的一个关键组成部分。

使用RESTful应用程序至少需要对HTTP有基本的了解。有了这些内容,您就可以很好的在您的下一个编码项目中破译客户端-服务端通信的秘密了。

原文来自:众成翻译

电话 0512-88869195