web接口和rest的区别_Web的工作方式第三部分：HTTP和REST

web接口和rest的区别

by Preethi Kasireddy

通过Preethi Kasireddy

Web的工作方式第三部分：HTTP和REST (How the Web Works Part III: HTTP & REST)

We went over basic web architecture in part I, and we talked about web application structure in part II. Now it’s time to roll up our sleeves and tackle part III: a closer look at HTTP and REST.

我们去了基本的网络架构中的一部分，我的，我们在谈论的Web应用程序结构第二部分 。 现在是时候振作精神，着手解决第三部分：仔细研究HTTP和REST。

Understanding HTTP is crucial for web developers because it facilitates the flow of information in web applications — allowing better user interactions and improved site performance.

理解HTTP对Web开发人员至关重要，因为它有助于Web应用程序中的信息流-允许更好的用户交互和改善的网站性能。

什么是HTTP？ (What is HTTP?)

In the Client-Server model, clients and servers exchange messages in a “request–response” messaging pattern: the client sends a request and the server returns a response.

在客户端-服务器模型中，客户端和服务器以“请求-响应”消息传递模式交换消息：客户端发送请求，服务器返回响应。

Keeping track of those messages is trickier than it sounds, so the client and server adhere to a common language and set of rules so they know what to expect. This language, or “protocol,” is called HTTP.

跟踪这些消息比听起来要棘手，因此客户端和服务器遵循共同的语言和一组规则，以便他们知道会发生什么。 这种语言或“协议”称为HTTP。

The HTTP protocol defines the syntax (the data format and encoding), semantics (the meaning associated with the syntax) and timing (speed and sequencing). Each HTTP request and response exchanged between a client and server is considered a single HTTP transaction.

HTTP协议定义了语法(数据格式和编码)，语义(与语法相关的含义)和时序(速度和顺序)。 在客户端和服务器之间交换的每个HTTP请求和响应都被视为单个HTTP事务 。

HTTP：大招 (HTTP: The broad strokes)

There are a few things worth noting about HTTP before we dive into the details.

在我们深入研究细节之前，有一些关于HTTP的值得注意的事情。

First off, HTTP is text-based, meaning that the messages exchanged between the client and server are bits of text. Each message contains two parts: a header and a body.

首先，HTTP是基于文本的，这意味着客户端和服务器之间交换的消息是文本的一部分。 每个消息包含两部分：标题和正文。

Secondly, HTTP is an application layer protocol, meaning it’s just an abstraction layer that standardizes how hosts communicate. HTTP itself doesn’t transmit the data. It still depends on the underlying TCP/IP protocol to get the request and response from one machine to another.

其次，HTTP是一个应用程序层协议，这意味着它只是一个标准化层，用于标准化主机的通信方式。 HTTP本身不传输数据。 它仍然依赖于底层的TCP / IP协议来将请求和响应从一台计算机传递到另一台计算机。

(As a reminder, TCP/IP is a two-part system that functions as the Internet’s fundamental “control system”. For more on TCP/IP, check out Part I)

(提醒一下，TCP / IP是一个由两部分组成的系统，用作Internet的基本“控制系统”。有关TCP / IP的更多信息，请参阅第I部分 )

Lastly, you may have seen the protocol “HTTPS” in the address bar on your browser and wondered whether HTTP is the same thing as HTTP + “S”. The short answer is sorta, with a slight difference.

最后，您可能已经在浏览器的地址栏中看到了协议“ HTTPS”，并且想知道HTTP是否与HTTP +“ S”相同。 简短的答案是sorta，略有不同。

A plain HTTP request or response is not encrypted and is vulnerable to various types of security attacks. HTTPS, on the other hand, is a more secure communication that uses encryption to keep things safe. It stands for HTTP over TLS/SSL.

普通的HTTP请求或响应未加密，容易受到各种类型的安全攻击。 另一方面，HTTPS是一种更安全的通信，它使用加密来确保事物的安全。 它代表TLS / SSL上的HTTP。

SSL is a security protocol that allows the client and server to communicate across a network in a secure way — to prevent eavesdropping and tampering — while the message travels across the network.

SSL是一种安全协议，它允许客户端和服务器在网络上传播消息时以安全的方式在网络上进行通信-防止窃听和篡改。

The client typically indicates whether it needs a TLS/SSL connection by using a special port number: 443. Once the client and server agree to use TLS/SSL to communicate, they negotiate a stateful connection by doing what’s called a “TLS handshake.” The client and server then establish secret session keys that they can use to encrypt and decrypt messages as they talk to each other.

客户端通常使用特殊的端口号443来指示是否需要TLS / SSL连接。一旦客户端和服务器同意使用TLS / SSL进行通信，它们就会通过进行“ TLS握手”来协商有状态连接。 然后，客户端和服务器建立秘密会话密钥，当它们彼此交谈时，它们可用于加密和解密消息。

Many major websites like Google and Facebook use HTTPS — after all, it’s what keeps your passwords, personal information and credit card details safe on the wire.

像Google和Facebook这样的许多主要网站都使用HTTPS-毕竟，这是使您的密码，个人信息和信用卡详细信息保持在线安全的原因。

HTTP：妙招 (HTTP: The fine strokes)

With those basics out of the way, let’s dive a little deeper into the structure of HTTP.

在不了解这些基础知识的情况下，让我们更深入地研究HTTP的结构。

We can start by visiting https://www.github.com to communicate with a GitHub server. If you’re using Chrome or Firefox with the Firebug extension installed, you can investigate the details of HTTP requests by going to the “Network” tab. If you have this open, then visit www.github.com by typing it into your address bar and you should see something like this:

我们可以从访问https://www.github.com开始与GitHub服务器通信。 如果您使用安装了Firebug扩展程序的Chrome或Firefox，则可以转到“网络”标签来调查HTTP请求的详细信息。 如果您有打开的窗口 ，请在地址栏中输入www.github.com ，您应该会看到类似以下内容：

Then on the left panel, click on the first path, “github.com.” You should now see this:

然后在左侧面板上，单击第一个路径“ github.com”。 您现在应该看到以下内容：

HTTP请求头 (HTTP Request Header)

HTTP Headers typically contain metadata (data about data). The metadata includes request type (GET vs. POST vs. PUT vs. DELETE), path, status code, content-type, user-agent, cookie, post body (sometimes), and more.

HTTP标头通常包含元数据(有关数据的数据)。 元数据包括请求类型(GET，POST，PUT，DELETE)，路径，状态代码，内容类型，用户代理，Cookie，帖子主体(有时)等。

Let’s take a closer look at the most important parts of the header using the Github example, starting with the “response headers” section:

让我们使用Github示例仔细研究标题的最重要部分，从“响应标题”部分开始：

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

  要求网址：https：//github.com/

• The URL we requested
  我们要求的网址

• Request Method:GET

  请求方法：GET

• The type of HTTP method being used. In our case, our browser said: “Hey, Github’s server, GET me to your homepage.”
  使用的HTTP方法的类型。 在我们的例子中，我们的浏览器说：“嘿，Github的服务器，把我带到您的主页。”

• Status Code:200 OK

  状态码：200 OK

• A standardized way for the server to tell the client about the result of its request. Status code 200 means that the server successfully found the resource, and is sending it to you.
  服务器将其请求结果告知客户端的一种标准化方法。 状态码200表示服务器已成功找到该资源，并将其发送给您。

• Remote Address:192.30.252.129:443

  远程地址：192.30.252.129：443

• The IP address and port number of the GitHub website we visited. Note that it’s port # 443 (which means we’re using HTTPS instead of HTTP).
  我们访问的GitHub网站的IP地址和端口号。 请注意，它是端口号443(这意味着我们使用的是HTTPS而不是HTTP)。

• Content-Encoding:gzip

  内容编码：gzip

• The encoding of the resource we received back. In our case, Github’s server is telling us that the content it’s sending back is compressed. Github is probably compressing the file so that you can have faster download time.
  我们收到的资源的编码。 在我们的例子中，Github的服务器告诉我们它发送回的内容已压缩。 Github可能正在压缩文件，以便您可以更快地下载。

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

  内容类型：文本/ HTML； 字符集= utf-8

• Specifies the representation of the data in the response body, including the type and subtype. The type describes the type of data, while the subtype specifies a specific format for that type of data. In our case, we have text being sent back in the form of HTML
  指定响应主体中数据的表示形式，包括类型和子类型。 类型描述数据的类型，而子类型指定该数据类型的特定格式。 在我们的案例中，我们以HTML形式发送了文本
• The second part specifies the character encoding for the HTML document. This will most often be UTF-8, as is the case above.
  第二部分指定HTML文档的字符编码。 与上面的情况一样，它通常是UTF-8。

There’s also a bunch of header information, which the client had to send so that the server could know how to respond. Take a look under the “request headers” portion:

还有一堆标头信息，客户端必须发送这些信息，以便服务器知道如何响应。 看一下“请求标头”部分：

• 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

  用户代理：Mozilla / 5.0(Macintosh; Intel Mac OS X 10_10_5)AppleWebKit / 537.36(KHTML，如Gecko)Chrome / 47.0.2526.73 Safari / 537.36

• The software that is acting on behalf of a user. Sometimes a website needs to know how it is being viewed. So the browser sends this User-Agent string that the server can use to determine what is being used to access a website
  代表用户运行的软件。 有时，网站需要了解其浏览方式。 因此，浏览器发送此User-Agent字符串，服务器可使用该字符串来确定用于访问网站的内容

• Accept-Encoding:gzip, deflate, sdch

  接受编码：gzip，deflate，sdch

• Specifies what content encoding the browser is willing to accept. We can see that gzip is listed, and that’s why Github’s server was able to send us the content in gzip format.
  指定浏览器愿意接受的编码内容。 我们可以看到列出了gzip，这就是Github的服务器能够将gzip格式的内容发送给我们的原因。

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

  接受语言：en-US，en; q = 0.8

• Describes the language we want the webpage to be in. In our case, “en” stands for English.
  描述我们希望网页使用的语言。在我们的例子中，“ en”代表英语。

• Host:github.com

  主持人：github.com

• Self-explanatory :)
  不言自明的:)

• 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_

  Cookie：_octo = GH1.1.491617779.1446477115; logging_in =是; dotcom_user = iam-peekay; _gh_sess =某事假某事假某事假某事假某事假某事假某事假某事假某事假 user_session = FakesomethingFakesomeFakesomethingFakesomethingFake; _ga = 9389479283749823749; tz =美国％2FLos_Angeles_

• A piece of text that a web server can store on a user’s machine and later retrieve. The information is stored as name-value pairs. One of the name-value pairs that Github stored for my request, for example, is “dotcom_user=iam-peekay”, which informs Github that my userid is iam-peekay.
  Web服务器可以在用户的​​计算机上存储并稍后检索的一段文本。 该信息存储为名称-值对。 例如，Github为我的请求存储的名称/值对之一是“ dotcom_user = iam-peekay”，它告知Github我的用户名是iam-peekay。

tl; dr：所有这些名称/值对是怎么回事？ (tl;dr: what’s up with all these name-value pairs?)

Long story short, we’re left with a lot of name-value pairs. But how do these name-value pairs get created?

长话短说，我们剩下很多名称/值对。 但是如何创建这些名称/值对？

Anytime your browser visits a website, it’ll look on your computer for a cookie file set by the website earlier.

每当您的浏览器访问网站时，它都会在您的计算机上查找该网站之前设置的Cookie文件。

So if I’m visiting www.github.com, my browser will look for a cookie file that GitHub has saved on my hard disk. If it finds a cookie file, it’ll send all of the name-value pairs in the request header.

因此，如果我访问www.github.com，我的浏览器将查找GitHub已保存在我的硬盘上的cookie文件。 如果找到cookie文件，它将在请求标头中发送所有名称/值对。

GitHub’s web server can now use the cookie data in many different ways, such as rendering content based on my stored user preferences, counting the number of time I visited their site.

GitHub的Web服务器现在可以通过许多不同的方式使用Cookie数据，例如根据我存储的用户首选项呈现内容，计算我访问其网站的时间。

If the browser doesn’t find a cookie file — either because the site has never been visited before or the user blocked or deleted it — the browser doesn’t send any cookie data.

如果浏览器找不到cookie文件(由于以前从未访问过该网站，或者用户阻止或删除了该文件)，则浏览器不会发送任何cookie数据。

In this case GitHub’s server creates a new ID as a name-value pair, along with any other name-value pairs it wants, and sends it to my computer via the HTTP header — which my computer then stores on its hard disk.

在这种情况下，GitHub的服务器会创建一个新ID作为其名称/值对以及它想要的任何其他名称/值对，然后通过HTTP标头将其发送到我的计算机，然后我的计算机将其存储在其硬盘上。

HTTP主体 (HTTP Body)

As you saw above, the server holds most of the important “metadata” (data about data) that it needs to communicate with the client.

正如您在上面看到的，服务器拥有与客户端进行通信所需的大多数重要的“元数据”(有关数据的数据)。

Now onto the body.

现在到身体上。

The body, as you might guess, is the body of the message. Depending on the type of request, it can be empty.

您可能会猜到，主体就是消息的主体。 根据请求的类型，它可以为空。

In our case, you can see the body in the “Response” tab. Since we made a GET request to www.github.com, the body contains the HTML page content for www.github.com.

在本例中，您可以在“响应”选项卡中看到正文。 由于我们向www.github.com发出了GET请求，因此主体包含了www.github.comHTML页面内容。

…Which is, of course, important for displaying that page.

…当然，对于显示该页面很重要。

补充练习 (Additional exercises)

I hope that this leaves you with a better understanding of the structure of HTTP. For practice, you can take a look at all the other assets that are requested by your browser (images, JavaScript files, etc.) when you visit www.github.com.

我希望这能使您对HTTP的结构有更好的了解。 作为练习，当您访问www.github.com时，可以查看浏览器请求的所有其他资产(图像，JavaScript文件等)。

With that out of the way, let’s look at the various types of HTTP methods that a client can initiate.

顺便说一句，让我们看一下客户端可以启动的各种HTTP方法。

HTTP方法 (HTTP Methods)

HTTP verbs, or methods, tell the server what to do with the data identified by the URL. URLs always identify a specific resource. When a client uses a URL in combination with an HTTP verb, this tells the server what action needs to happen on which resource.

HTTP动词或方法告诉服务器如何处理URL标识的数据。 URL始终标识特定资源。 当客户端将URL与HTTP动词结合使用时，这将告诉服务器需要对哪种资源执行什么操作。

Examples of URLs include:

URL的示例包括：

• GET http://www.example.com/users (get all users)

  GET http://www.example.com/users (获取所有用户)

• POST http://www.example.com/users/a-unique-id (create a new user)

  POST http://www.example.com/users/a-unique-id (创建新用户)

• PUT http://www.example.com/comments/a-unique-id (update a comment)

  放置 http://www.example.com/comments/a-unique-id (更新评论)

• DELETE http://www.example.com/comments/a-unique-id (delete a comment)

  删除 http://www.example.com/comments/a-unique-id (删除评论)

When a client makes a request, it’ll indicate the type of request using one these verbs. The most important ones are GET, POST, PUT and DELETE. There are other methods, such as HEAD and OPTIONS, but they are rarer, so we’ll skip those for this post.

当客户提出请求时，它将使用这些动词之一来指示请求的类型。 最重要的是GET，POST，PUT和DELETE。 还有其他方法，例如HEAD和OPTIONS，但它们很少见，因此在本文中我们将跳过这些方法。

得到 (GET)

GET is the most commonly used method. It’s used to read information for a given URL from a server.

GET是最常用的方法。 它用于从服务器读取给定URL的信息。

GET requests are read-only, meaning that the data should never be modified on the server — the server should simply retrieve the data unchanged. In this way, GET requests are considered safe operations, because calling it once, or calling it 20 times, will have the same effect.

GET请求是只读的，这意味着永远不要在服务器上修改数据-服务器应该简单地获取未更改的数据。 这样，GET请求被认为是安全的操作，因为调用一次或调用20次将具有相同的效果。

Additionally, GET requests are idempotent. What this means is that submitting multiple GET requests to the same URL should cause the exact same effect as just one GET request since a GET request is just asking the server for data and not actually changing any data on the server.

此外，GET请求是幂等的 。 这意味着将多个GET请求提交到同一个URL应该会产生与仅一个GET请求完全相同的效果，因为GET请求只是向服务器请求数据，而实际上并未更改服务器上的任何数据。

GET requests respond with a status code 200 (OK) if the resource was successfully found, and 404 (NOT FOUND) if the resource was not found. (Hence the term “404 page” for error messages when visiting retired or mis-typed URLs.)

如果成功找到资源，则GET请求以状态码200(确定)响应，如果未找到资源，则请求状态码为404(未找到)。 (因此，在访问退休的或输入错误的URL时，会出现错误消息“ 404页面”一词。)

开机自检 (POST)

POST is used to create a new resource, such as a sign-up form. You use POST when you want to create a subordinate resource (e.g. a new user) to some other parent resource (http://example.com/users). Your post to this parent resource identified by the URL, and the server processes the new resource and associates it with the parent.

POST用于创建新资源，例如注册表单。 当您要创建某个其他父资源(http://example.com/users)的下级资源(例如新用户)时，可以使用POST。 您在URL所标识的此父资源上的帖子，服务器将处理新资源并将其与父资源相关联。

POST is neither safe nor idempotent. This is because making two or more identical POST requests will likely cause two new identical resources to be created.

POST既不安全也不幂等。 这是因为发出两个或多个相同的POST请求可能会导致创建两个新的相同资源。

POST requests respond with a status code 201 (CREATED) along with a location header with the link to the newly created resource.

POST请求以状态码201(已创建)以及带有新创建资源链接的位置标头响应。

放 (PUT)

PUT is used to update the resource identified by the URL using the information in the request body. PUT can also be used to create a new resource. PUT requests are not considered safe operations because they modify state on the server. However, it is idempotent because multiple identical PUT requests to update a resource should have the same effect as the first one.

PUT用于使用请求正文中的信息更新URL标识的资源。 PUT也可以用于创建新资源。 PUT请求不被视为安全操作，因为它们会修改服务器上的状态。 但是，这是幂等的，因为多个相同的PUT请求更新资源应具有与第一个相同的效果。

PUT requests respond with a status code of 200 (OK) if the resource was successfully updated, and 404 (NOT FOUND) if the resource was not found.

如果资源已成功更新，则PUT请求以状态码200(确定)进行响应，如果未找到资源，则状态码为404(未找到)。

删除 (DELETE)

DELETE is used to delete the resource identified by the URL. DELETE requests are idempotent because if you DELETE a resource, it’s deleted and even if you make multiple identical DELETE requests, the result is the same: a deleted resource.

DELETE用于删除URL标识的资源。 DELETE请求是幂等的，因为如果您删除一个资源，它就会被删除，即使您发出多个相同的DELETE请求，结果也是一样的：一个删除的资源。

You’ll likely just get a 404 error message if you send a DELETE request more than once for the same resource, because the server won’t be able to find it once it’s been deleted.

如果您对同一资源多次发送DELETE请求，您可能只会收到404错误消息，因为一旦删除该服务器，服务器将无法找到它。

DELETE requests respond with a 200 (OK) status code if successfully deleted or 404 (NOT FOUND) if the resource to be deleted couldn’t be found.

如果成功删除，DELETE请求将以200(OK)状态码响应；如果找不到要删除的资源，则以404(NOT FOUND)响应。

All of the above requests return a 500 (INTERNAL SERVER ERROR) if the processing fails and the server errors out.

如果处理失败且服务器出错，则上述所有请求均返回500(内部服务器错误)。

REST到底是什么？ (What is REST after all?)

I have one last term to cover before we call it a day: REST.

在我们称之为“一天”之前，我要讲的最后一个术语是：REST。

You may have heard the term “RESTful application” before. It’s important to understand what this means because if you’re using HTTP to communicate between the client and server, it’s beneficial to follow the REST guidelines. (In fact, the HTTP verbs we defined above represent a majority of what REST is.)

您可能以前曾经听说过“ RESTful应用程序”一词。 理解这意味着什么很重要，因为如果您使用HTTP在客户端和服务器之间进行通信，那么遵循REST准则将是有益的。 (实际上，我们上面定义的HTTP动词代表了REST的大部分。)

REST stands for “Representational State Transfer.” It’s an architecture style for designing applications.

REST代表“代表性状态转移”。 这是用于设计应用程序的体系结构样式。

The basic idea is that you use a “stateless”, “client-server”, “cacheable” protocol to make calls between machines — and most often, this protocol is HTTP. This is just a fancy way of saying that REST gives you a set of constraints to design an application with. These constraints help make the system more performant, scalable, simple, modifiable, visible, portable, and reliable.

基本思想是，您使用“无状态”，“客户端-服务器”，“可缓存”协议在计算机之间进行调用-通常，该协议是HTTP。 这只是说说REST为您设计应用程序提供了一组约束的一种很好的说法。 这些限制有助于使系统性能更高，可伸缩性，简单，可修改，可见，可移植且可靠。

The full list of constraints is lengthy and you can read more about it here. For the sake of this post, I’d like to double-click on the two most important ones:

约束的完整列表很长，您可以在此处了解更多信息。 为了这篇文章，我想双击两个最重要的：

1. Uniform interface: This constraint tells you how to define the interface between the client and server in a way that simplifies and decouples the architecture. It says that:

   统一接口 ：此约束告诉您如何以简化和分离架构的方式定义客户端和服务器之间的接口。 它说：

• Resources must be identifiable in a request (e.g. by using resource identifiers in the URI). A resource (e.g. data in a database) is the data that defines the resource representation (e.g. JSON, HTML). Resources and resource representations are separate things — the client only interacts with the resource representation.
  资源在请求中必须是可识别的(例如，通过使用URI中的资源标识符)。 资源(例如数据库中的数据)是定义资源表示形式(例如JSON，HTML)的数据。 资源和资源表示是分开的东西-客户端仅与资源表示进行交互。
• The client must have enough information to manipulate resources on the server using the representation of the resource.
  客户端必须具有足够的信息，才能使用资源表示形式来操纵服务器上的资源。
• Every message exchanged between the client and server needs to be self-descriptive, with information on how to process the message.
  客户端和服务器之间交换的每条消息都必须具有自我描述性，并带有有关如何处理该消息的信息。
• Clients must send state data using HTTP body content, HTTP request headers, query parameters and the URL. Servers must send state data using HTTP body content, response codes, and response headers.
  客户端必须使用HTTP正文内容，HTTP请求标头，查询参数和URL发送状态数据。 服务器必须使用HTTP正文内容，响应代码和响应标头发送状态数据。
• NOTE: The HTTP verbs we described above make up a major portion of this “uniform interface” constraint, because they represent the uniform actions that happen on resources.
  注意：我们上面描述的HTTP动词构成了此“统一接口”约束的主要部分，因为它们表示发生在资源上的统一动作。

2. Stateless: This constraint says that all the state data needed to handle a client request must be contained within the request itself (URL, query parameters, HTTP body, or HTTP headers) and the server must send all the state data necessary back to the client through the response itself (HTTP headers, status code, and HTTP response body).

2.无状态 ：此约束表明，处理客户端请求所需的所有状态数据必须包含在请求本身内(URL，查询参数，HTTP主体或HTTP标头)，并且服务器必须将所有必要的状态数据发送回客户端通过响应本身(HTTP标头，状态代码和HTTP响应正文)。

Side note: State — or application state — is the data necessary for a server to fulfill a request.

旁注 ：状态(或应用程序状态)是服务器满足请求所需的数据。

What this means is that the for every request, we resend the state information back and forth, so that the server doesn’t have to maintain, update and send the state.

这意味着对于每个请求，我们都来回发送状态信息，这样服务器就不必维护，更新和发送状态。

Having such a stateless system makes applications a whole lot more scalable, because no server has to worry about maintaining the same session state over the span of multiple requests. Everything needed to get the state data is available in the request and response itself.

拥有这样的无状态系统使应用程序具有更大的可伸缩性，因为无需服务器担心在多个请求的范围内维护相同的会话状态。 请求和响应本身中提供了获取状态数据所需的所有信息。

结束语 (Closing remarks)

Phew! HTTP is far from simple. But as you can see, it’s a critical component of the client-server relationship.

！ HTTP远非简单。 但是正如您所看到的，它是客户端-服务器关系的关键组成部分。

Making RESTful applications require at least a basic understanding of HTTP . With this content under your belt, you’re well on your way to deciphering the mysteries of client-server communication in your next coding project.

制作RESTful应用程序至少需要对HTTP有基本的了解。 掌握了这些内容之后，您就可以很好地理解下一个编码项目中客户-服务器通信的奥秘了。

翻译自: https://www.freecodecamp.org/news/how-the-web-works-part-iii-http-rest-e61bc50fa0a/

web接口和rest的区别