REST API理论

第一个模块结束时，你创建了一个HTTP请求，发送了它，并得到了一个响应。

我们在未来还会做很多次。我们将向第三方服务器发送请求。我们将制作应用程序，使其本身接受此类请求并返回一个响应。我们将创建复杂的逻辑来处理请求。

因此，最好是彻底研究与这些请求有关的一切，详细分析它们。这样，你就不能只是把请求复制到某个地方并重复它，而是真正弄清楚这一切是如何运作的。

这就是我们在第二个模块中要做的。开始吧!

一般理论

让我们从理论开始。

如果你在第一个模块中做了功课，研究了文档，你应该注意到API这个缩写。实际上，如果开发者想了解与网络上的一些服务或应用程序的交互，首先应该研究的就是API文档。

API

API - 应用程序编程接口。这是对客户端和服务器之间相互通信方式的描述。我们打开API文档，从那里了解如何从服务器上获得必要的数据。

我们总是希望这种互动是简单的、可理解的。这对开发者（在设计一个新的服务时不需要重新发明轮子）和用户（如果一个服务的工作原理与以前熟悉的服务相同，那么它就更容易学习）来说都简化了任务。在这里，值得记住一个新的术语--REST。

REST

REST--Representational State Transfer的首字母缩写。它听起来可能不是很清楚，但简单地说，REST是一种客户端和服务器之间的交互方式（信息交换）。

这不是一些僵化的规则和要求。REST并不强迫使用任何特定的编程语言，也不以严格的准则束缚双手。REST被称为一种架构风格，它定义了一个系统架构必须遵守的6个原则。

因此，考虑到REST原则而开发的API被称为REST API，而应用程序本身被称为RESTful。

我们将创建这样的RESTful应用程序，所以值得马上讨论它们所要遵守的原则。

RESTful原则

客户端-服务器模式。该原则定义了客户端和服务器的分离，以及他们需求的区分。客户端不必担心数据是如何存储的，最主要的是数据要根据要求发布。反过来，服务器也不关心客户将如何处理这些数据，如何进一步处理和显示这些数据。这使得他们可以相互独立发展，并提高了系统的可扩展性。

无状态性。这个原则意味着服务器不应该根据以前对这个客户的经验 "想出 "响应。任何请求都是以包含其处理的所有必要信息的方式提出的，而不考虑以前的请求。

缓存。为了尽量减少传输的数据，有一个缓存机制。例如，如果在某些页面上显示一个标志，那么每次都从服务器上请求它是没有意义的。它并不经常变化，只需获取一次并将其保存在客户端的计算机上，放在缓存中即可。但如果我们需要获得汽车当前速度的信息，那么缓存就没有任何帮助了。这个原则决定了由服务器传输的数据应该被指定为可缓存或不可缓存。

统一的接口。该原则定义了客户-服务器交互的单一格式。所有请求的结构必须是相同的。数据必须以相同的形式发送，无论谁来请求它。

分层系统。客户端和服务器不一定直接交流。数据传输可以通过几个中间节点。在这种情况下，系统的设计使客户和服务器都不知道他们是在与最终的应用程序还是中间节点进行交互。这允许你平衡服务器上的负载，增加可扩展性。

按需编码（可选）。唯一不是强制性的原则。根据它，客户端可以通过从服务器下载可执行代码（例如，脚本）来扩展其功能。在这种情况下，代码应该只在需求时执行。