by Sanchit Gera
通过Sanchit Gera
RESTful服务的第一部分：简而言之的HTTP (RESTful Services Part I : HTTP in a Nutshell)
The web has, from it’s inception, been structured around the idea of resources. In it’s early days, the web was merely a platform for sharing simple text/HTML based files, documents, images etc. In this sense, the web can be thought of as a collection of resources and is often referred to as being resource-oriented.
网络从一开始就围绕资源的概念而构建。 在早期，Web只是一个用于共享基于简单文本/ HTML的文件，文档，图像等的平台。从这个意义上讲，Web可以看作是资源的集合，通常被称为面向资源的。
The web has since evolved into a much more complex network of interconnected applications, brimming with rich content. Applications themselves have grown in complexity, packing increasing amounts of functionality within themselves.
此后，网络已发展成为一个相互连接的应用程序的更为复杂的网络，内容丰富。 应用程序本身已经变得越来越复杂，在其内部封装了越来越多的功能。
Services provide a means for exposing this functionality to clients. Generally, large applications may want to provide programmatic access to their platform to other developers and may do so by making use of services.
服务提供了向客户端公开此功能的方法。 通常，大型应用程序可能希望向其他开发人员提供对其平台的编程访问，并且可能会利用服务来这样做。
Alternatively, services may be used to decompose an application into different logical units, interacting amongst themselves to produce some end result. In this case, a service acts as a consumer of other services.
或者，服务可用于将应用程序分解为不同的逻辑单元，它们之间进行交互以产生最终结果。 在这种情况下，服务充当其他服务的使用者。
With services forming a critical component to web applications, developers naturally try and ensure that they are designed in a way that is scalable, performant and work with as little overhead as possible — both technical and otherwise.
由于服务是Web应用程序的重要组成部分，因此开发人员自然会尝试并确保以可伸缩性，高性能和最少的开销(无论是技术开销还是其他开销)进行设计。
Enter REST! REST, short for REpresentational State Transfer, is an architectural style that aims to leverage all the same constructs that have allowed to the Web to grow over the last couple of decades. It uses these as guiding principles for designing web services.
输入REST！ REST(代表状态转移)是一种体系结构样式，旨在利用过去二十年来允许Web增长的所有相同构造。 它使用这些作为设计Web服务的指导原则。
Since all communication on the Web happens over HTTP, REST is intricately tied to it and uses a lot of the same ideas. As such, an understanding of REST requires an understanding the underlying concepts of HTTP. This is the subject of the remainder of this post. :)
由于Web上的所有通信都是通过HTTP进行的，因此REST与之紧密相连，并且使用了许多相同的思想。 因此，了解REST需要了解HTTP的基本概念。 这是本文其余部分的主题。 :)
简而言之HTTP (HTTP in a Nutshell)
Most web applications are built around a client-server model. A client could be something as simple as a web browser displaying plain old HTML, a mobile application fetching and creating data or even other web services.
大多数Web应用程序都是围绕客户端-服务器模型构建的。 客户端可能像显示简单的旧HTML的Web浏览器，获取并创建数据的移动应用程序甚至其他Web服务一样简单。
Similarly, servers could be implemented in a variety of ways, using different technology stacks, languages, and serving different types of data.
同样，可以使用各种技术，使用不同的技术堆栈，语言并提供不同类型的数据来实现服务器。
In order to accommodate this diversity, clients and servers must agree upon a set of conventions — a protocol — that dictates all communication between them. This protocol allows a web server to receive the information — requests — sent by an arbitrary client, process them, and respond appropriately.
协议- -即使然它们之间的所有通信。为了适应这种多样性，客户端和服务器必须在一组约定的认同。 该协议允许Web服务器接收任意客户端发送的信息( 请求) ，对其进行处理并进行适当响应。
Modern day web applications use the Hypertext Transfer Protocol, commonly abbreviated to HTTP, in order to exchange information.
现代Web应用程序使用超文本传输协议，通常缩写为HTTP，以交换信息。
Essentially, this provides a structured format for exchange of information over the web. As we shall see, HTTP lays down a broad set of guidelines in order to describe the type of data being exchanged — along with it’s format, validity, and other attributes.
本质上，这提供了一种用于通过网络交换信息的结构化格式。 正如我们将看到的，HTTP制定了一套广泛的准则，以描述正在交换的数据的类型-以及其格式，有效性和其他属性。
In the past, applications have typically relied on HTTP solely as a transmission mechanism. Clients and servers exchange data using HTTP. Other conventions must then be developed in order to make sense of that data. One example of such a paradigm is SOAP, one of the most common opponents of REST.
过去，应用程序通常仅依赖HTTP作为传输机制。 客户端和服务器使用 HTTP交换数据。 然后必须制定其他约定以便理解该数据。 SOAP是这种范例的一个例子，它是REST最常见的反对者之一。
The wonderful thing about HTTP, however, is that it already has the constructs needed in order to specify the action and the resource being acted upon (client request), as well as the outcome of those actions (server response), which prevents for additional overhead to transfer information. Let’s take a look at some of them!
但是，关于HTTP的奇妙之处在于，它已经具有用于指定操作和要操作的资源( 客户端请求 )以及这些操作的结果( 服务器响应)所需的结构，以防止其他操作。传输信息的开销。 让我们看看其中的一些！
1.网址 (1. URLs)
The URL are a one of the most important and useful concepts of the Web. It is also probably the concept most users are already familiar with, even if only in passing. URL is short for Uniform Resource Locator and is used to identify the address of a resource on the Web.
URL是Web最重要和最有用的概念之一。 即使只是通过，它也可能是大多数用户已经熟悉的概念。 URL是统一资源定位符的缩写，用于标识Web上资源的地址。
A URL typically consists of the following components :
URL通常包含以下组件：
Protocol: This is the protocol that the request is served over. This is most often just HTTP (or its secure version, HTTPS). Other protocols such as SMTP and FTP exist and may be used instead, but we will limit ourselves to HTTP in this discussion.
协议 ： 这是为请求提供服务的协议。 这通常只是HTTP(或其安全版本HTTPS)。 存在诸如SMTP和FTP之类的其他协议，但可以替代使用，但是在本讨论中，我们将限于HTTP。
Domain: This is the host name of the server the resource is being requested from. The domain may be equivalently replaced by an IP address, which is usually done under the hood by a DNS.
域 ： 这是从中请求资源的服务器的主机名。 该域可以等效地由IP地址代替，而IP地址通常是由DNS在后台完成的。
Path: This is the location of the resource on the server. This may be correspond to the location of the resource within the file system (i.e. /search/files/myFile.txt) although this practice is rarely used nowadays. It is more common for web services to nest paths based on relationship between resources (i.e. myBlog/blog/comments) where blog and comments represent two distinct resources. This is explored further in the second part of this series.
路径 ： 这是资源在服务器上的位置。 这可能与资源在文件系统中的位置(即/search/files/myFile.txt)相对应，尽管这种做法如今很少使用。 对于Web服务，基于资源(即myBlog / blog / comments)之间的关系来嵌套路径更为常见，其中博客和评论代表两种截然不同的资源。 本系列的第二部分将对此进行进一步探讨。
Parameters: This is additional data, passed in the form of key-value pairs, that may be used by the server to identify the resource, or filter a list of resources.
参数 ： 这是附加数据，以键值对的形式传递，服务器可以使用它们来标识资源或过滤资源列表。
Fragment: A fragment refers to a location within the resource being returned and is typically applied to documents. This may be thought of as a bookmark within the document returned and instructs the browser to locate the content at the bookmarked point and display it. For example, for HTML documents the browser directly scrolls to the element identified by the anchor. Fragments are also referred to as anchors.
片段 ： 片段是指一个位置内被返回的资源，并且通常应用于文档。 可以将其视为返回文档中的书签，并指示浏览器将内容定位在加书签的位置并显示它。 例如，对于HTML文档，浏览器直接滚动到锚点标识的元素。 片段也称为锚。
2. HTTP方法 (2. HTTP Methods)
HTTP defines a handful of methods, also called “verbs”, that a client may use in order to describe the type of request being made. This is best understood in the context of resources discussed previously.
HTTP定义了少数几种方法，也称为“动词”，客户端可以使用这些方法来描述所发出请求的类型 。 在前面讨论的资源中可以最好地理解这一点。
Each request can be modeled as doing a specific action on a resource. For example, a client may request to create, delete, update or simply read from a resource. In HTTP this corresponds to making POST, DELETE, PUT or GET requests respectively. POST and PUT requests accept payloads corresponding to the data being created or updated. We will explore the these methods in detail when we get to talking about REST in the next part.
可以将每个请求建模为对资源执行特定操作。 例如，客户端可以请求创建，删除，更新或简单地从资源读取。 在HTTP中，这分别对应于发出POST，DELETE，PUT或GET请求。 POST和PUT请求接受与正在创建或更新的数据相对应的有效负载。 在下一部分中讨论REST时，我们将详细探讨这些方法。
Two additional methods, which are used much less frequently, are the OPTIONS and HEAD methods.
OPTIONS和HEAD方法是另外两种不常用的方法。
Simply, the purpose of an OPTIONS request is to give the client information about what other methods may be used to interact with the resource in question.
简而言之，OPTIONS请求的目的是向客户端提供有关可以使用哪些其他方法与相关资源进行交互的信息。
The HEAD request, on the other hand, is a little more useful. A HEAD request mimics a GET request, except that it omits the body of the response. Essentially, the client receives a response identical to what it would have received for a GET request, with the same meta data, but without the response body. This is useful as it provides a quick way to check the response headers and existence of a resource.
另一方面，HEAD请求要有用得多。 HEAD请求模仿GET请求，只是它省略了响应主体。 本质上，客户端收到的响应与它对于GET请求所收到的响应相同，具有相同的元数据，但没有响应主体。 这很有用，因为它提供了一种检查响应头和资源是否存在的快速方法。
One important distinction laid down by HTTP is whether a method is safe or unsafe. A method is said to be safe if it doesn’t modify a resource. In other words, the request may be thought of as “read-only.” For example, making a GET (or HEAD) request for a resource from a server should not modify it in any way. All other methods are by default unsafe.
HTTP规定的一个重要区别是方法是安全还是不安全。 如果不修改资源，则该方法被认为是安全的。 换句话说，该请求可以被认为是“只读的”。 例如，从服务器对资源进行GET(或HEAD)请求不应以任何方式对其进行修改。 默认情况下，所有其他方法都不安全。
Lastly, there is the concept of idempotence. An HTTP method is said to be idempotent if repeated invocations of a request lead to the same outcome. As long as the parameters of the request remain unchanged, the request could be made any number of times and the resource would still be left in the same state as if the request were made only once. This fits well with the notion of resource-oriented thinking.
最后，是幂等的概念。 如果重复调用请求导致相同的结果，则认为HTTP方法是幂等的。 只要请求的参数保持不变，就可以进行多次请求，并且资源仍将保持相同的状态，就像仅进行一次请求一样。 这与以资源为导向的思想非常吻合。
GET, OPTIONS and HEAD are all naturally idempotent methods, as they are read-only operations. Additionally the PUT and DELETE methods are also characterized as idempotent. This is because updating any resource with the same set of parameters over and over again leads to the same end result.
GET，OPTIONS和HEAD都是自然的幂等方法，因为它们是只读操作。 另外，PUT和DELETE方法也被表征为幂等。 这是因为一次又一次地更新具有相同参数集的任何资源会导致相同的最终结果。
It may be slightly unintuitive for some to see why DELETE is also idempotent. Consider what happens to the system when multiple DELETE requests are made simultaneously. The first DELETE requests results in, well, the deletion of the resource. Making more DELETE requests at this point does not modify the state that the system is in. The system continues to remain in the same state that it were in after the first DELETE executed.
对于某些人来说，为什么DELETE也是幂等的可能有点不直观。 考虑同时进行多个DELETE请求时系统会发生什么情况。 第一个DELETE请求导致资源的删除。 此时发出更多的DELETE请求不会修改系统所处的状态。系统继续保持与执行第一个DELETE之后所处的状态相同。
To summarize…
总结一下……
3.状态码 (3. Status Codes)
Status codes are a useful HTTP construct that provide information to the consumer about the outcome of a request and how to interpret it. For example, if I were to make a request to retrieve a file from a web server, I would expect to see a response with the status code describing whether or not my request was completed successfully. If not, the status code would give me a further clue as to why my request failed.
状态码是一种有用的HTTP构造，可向消费者提供有关请求结果以及如何解释请求的信息。 例如，如果我要请求从Web服务器检索文件，则希望看到带有状态代码的响应，该响应描述了我的请求是否成功完成。 如果不是这样，状态代码将为我提供进一步的线索，说明我的请求失败的原因。
HTTP defines several status codes, each pertaining to a specific scenario. Some of the common series of codes you might encounter are listed here:
HTTP定义了几个状态代码，每个状态代码都与特定的场景有关。 下面列出了您可能会遇到的一些常见代码系列：
2xx: Status codes falling in the 2xx series imply that the request completed successfully and without errors. Code 200 is the typical example.
2xx： 2xx系列中的状态代码表示请求已成功完成且没有错误。 代码200是典型示例。
3xx: A code in the 3xx series implies redirection. This means that the server redirected to another location on receiving the request.
3xx： 3xx系列中的代码表示重定向。 这意味着服务器在接收到请求后重定向到另一个位置。
4xx: A 4xx error, i.e. 400, 403, 404 etc. are used when there is an error in the request made. This could be caused by a variety of reasons, such as unauthorized access to a resource, trying to work with a resource that doesn’t actually exist, invalid parameters and so on.
4xx：当请求中存在错误时，将使用4xx错误，即400、403、404等。 这可能是由多种原因引起的，例如对资源的未经授权的访问，试图使用实际上不存在的资源，无效的参数等等。
5xx: Lastly, a 5xx response is used when there is an error on the server side. This means that the server is aware of the error and is incapable of processing the request. Typically, the response is accompanied by a brief description of what the cause of the error might be.
5xx：最后，当服务器端发生错误时，将使用5xx响应。 这意味着服务器知道该错误，并且无法处理该请求。 通常，响应中会附有错误原因的简要说明。
4. HTTP标头 (4. HTTP Headers)
Headers are an essential part of HTTP communication. They serve to provide additional information for handling requests and responses. Note that the headers do not relate to the identification of the resource that is being acted upon. They typically appear as key value pairs and provide a host of information such as the cache policy for the response, the acceptable response types enforced by the client, the preferred language of response, encoding, etc.
标头是HTTP通信的重要组成部分。 它们用于提供其他信息来处理请求和响应。 请注意，标头与正在作用的资源的标识无关。 它们通常显示为键值对，并提供大量信息，例如响应的缓存策略，客户端强制执行的可接受响应类型，响应的首选语言，编码等。
Credentials for authentication and authorization — such as access tokens — are also commonly passed using the Authorization header.
身份验证和授权的凭证(例如访问令牌)通常也使用授权标头传递。
Similarly, the server may also make use of response headers to set cookies on the client and analogously retrieve them with the same mechanism.
类似地，服务器还可以利用响应头在客户端上设置cookie，并以相同的机制类似地检索它们。
A note on HTTPS: To avoid confusion, it is also important to understand what HTTPS is and how it differs from regular HTTP. Both HTTP and HTTPS use the same underlying mechanisms for transferring information, although HTTPS is (far) more secure. Data transferred over HTTPS is fully encrypted. This is an important consideration when the information in question is confidential, such as financial data or a user’s personal information.
关于HTTPS的注释：为避免混淆，了解什么是HTTPS及其与常规HTTP的区别也很重要。 HTTP和HTTPS都使用相同的底层机制来传输信息，尽管HTTPS更加安全。 通过HTTPS传输的数据已完全加密。 当所讨论的信息是机密信息(例如财务数据或用户的个人信息)时，这是一个重要的考虑因素。
In the next part of this post, I discuss the constraints put in place by REST on top of HTTP, and how it leverages the resource based nature of the Web to design simple and scalable web services. Find it here!
在本文的下一部分中，我将讨论REST在HTTP之上施加的约束，以及它如何利用Web的基于资源的本质来设计简单且可伸缩的Web服务。 在这里找到它！
And finally, in the third and last part of this series, you will learn about the The Richardson Maturity Model, a way to quantifiably measure how RESTful a service is, or isn’t. Check it out! :-)
最后，在本系列的第三部分和最后一部分中，您将了解The Richardson Maturity Model，这是一种量化衡量服务是否有RESTful的方法。 看看吧 ！ :-)
Other recommended reading:
其他推荐阅读：
翻译自: https://www.freecodecamp.org/news/restful-services-part-i-http-in-a-nutshell-aab3bfedd131/
837
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
